J1939 Add-on Feedback

[Daniel_E]

Thanks for the info!  As an FYI, I am currently updating the J1939 Addon to support XNET 15.0.  This will cause a split in J1939 addon.  It will be pre XNET 15.0 support and XNET 15.0 support and later. 

[Daniel_E]

As an update, I tried to update to XNET 15.0 but I found some issues with doing so. These have been reported. When they are fixed, I will update to native support.  Until then, I poseted a VeriStand 15 version that should work the way the addon always has.  You can use it with XNET 15.0 but it just won't use the native J1939 support.  From the online documentation of the addon:

NI XNET 15.0+ Notes

NI released native support for J1939 with the NI XNET 15.0 driver release.  While NI VeriStand does work with NI XNET 15.0 for CAN, LIN, and Flexray, it does not yet natively support the J1939 feature.  Because of this, users will still need this addon to do J1939.  To use this Addon with XNET 15.0, make sure you set the Application Type of your database to None but keep the frame settings.  If you set it to J1939, it could cause errors with this Addon.  Versions before XNET 15.0 will work without issue.

[swbpnole]

How does one build this project for the PharLap target if it has no Configuration source distribution and no Custom Device*.xml file?

[swbpnole]

OK, so I just right-clicked on the Build Spec under the PharLap Target in LabVIEW and built the Engine source distribution. Added the J1939 Custom Device in VeriSTAND under "Custom Devices", Configured it, setup the VS screen file, then attempted to deploy it. I got an error. The message is the attached file.

[swbpnole]

Daniel,

I have successfully gotten the project to work in VS with the help of Christine from Application Engineering. Now, I would like to extend this project to add some necessary custom logic. I would like the device to automatically send out specific responses to specific incoming messages. Any ideas as to how and where in the project to add such logic? I will continue to investigate on my end...

[Daniel_E]

Hey,

The addon should respond to requests automatically.  That said, I assume you are talking about receiving a message other than a request and acting on it.  The way we usually handle that is by implementing the logic in a model.  You then link the J1939 data channels (both inputs and outputs) to the model through System Mappings.  Your model looks for value changes on the J1939 data and responds accordingly.  This way, you have a modular system that keeps the J1939 addon generi and has all your custom logic in a model.

I hope this helps.

[swbpnole]

Daniel,

Thanks for reply. Let us say I got that route. What would I need to have in the model on from the LabVIEW side to make the System Mappings work? My experience with LabVIEW/VeriSTAND is less than a year.

Also,

1. some of our custom message require a source and destination address. Does this J1939 Addon have a way to specify destination addresses?
2. As far as getting CAN data, does VS pass all data from the CAN frame into the custom device? I would prefer if both the CAN ID and payload were given.

[Daniel_E]

Here are some links:

http://www.ni.com/tutorial/11135/en/

http://www.ni.com/tutorial/12785/en/

That should be a good starting point.  The biggest thing to know is that a model is supposed to run in 1 VeriStand loop.  So, if you set the VeriStand loop (PCL) to 1 kHz, the model should ideally finish in 1 ms.  So, this means you can't have things like continuously running while loops, etc.  Now, technically, we can decimate models to allow for more execution time but the high level concept is you need to create your logic to run quickly and stop.  VeriStand is responsible for executing the model (imagine VeriStand as a big while loop and your model is a subVI in that loop).

I hope that helps!

[Daniel_E]

I apoligize as I missed your two other questions.

1. The J1939 addon has an API for creating CAN messages and it does support using a source and destination address.

2. The J1939 addon would have all the information you want (ID and payload) but a model would only get data.

Based on this, you could modify the J1939 addon as you originally thought to get all this information the way you want.  The picture below is where the data gets scaled.  Notice it has the Arb ID will it as well.  If it were me, I would create a queue that sent the scaled data and Arb ID to a new loop that was my custom logic

Then you send the response directly to Process Outgoing queue.  NOTE: the data you send will need to be RAW(Byte array).  The below picture shows the queue to use.  Also, notice the J1939 API that has the source and destination fields.

I hope that helps!

[swbpnole]

Daniel,

Thank you for reply. Now, I would like to ask you, what is the difference in terms of responsiveness of a custom device vs a model. Let us say we have a J1939 "model" and a J1939 custom device, both as equal as possible code/VI wise. What would be the difference response wise?