J1939 Add-on Feedback

[Daniel_E]

Hey,

There is no plan to support VeriStand 2010.  I apologize for the inconvenience.

[Dexter.2Rays]

Is there a plan to address the following issues anytime soon?

One instance of the custom device requires sole ownership of one NI-XNET CAN port

You cannot select the same arbitration ID for generation and acquisition within the same instance of the add-on

[AGCOJason]

Hello,

My understanding is that one instance per CAN port is related to a limitation in VeriStand.  From what I heard at NI Week, I don't think this is still a limitation with VeriStand 2014 so the issue may be resolved with VS 2014 and J1939 Custom Device for VS 2014.

I can't speak to your second issue.  I have not tried to use the same ID for send and receive in my systems.

[StephenB]

XNET 14.0 added support to open multiple sessions per physical port, so if you have that installed it should work. However I don't know if Dan has tested it with the J1939 add-on

[Dexter.2Rays]

Thanks Jason and Stephen,

I'll try to rebuild the J1939 Custom Device with LV/VS 2014.

[Daniel_E]

Hey,

I will post a 2014 version tomorrow.  I need to test it to make sure there aren't any problems before I post it.  The port limitation is resolved with XNET 14.0.  However, the acquisition/generation of the same ARB ID is not supported.  Please let me know what your use case is for this.

Thanks!

[Daniel_E]

The latest version is posted.  Please let me know if you have any issues.  I have everything working on my end but I want to make sure it works for you as well.

Thanks!

[AGCOJason]

Hello,

We were working on an T4F engine simulation and ran across something.  In the J1939 spec, bytes that are not associated with a signal are supposed to be set to FF.  When we use our Vector dbc with CANalyzer all bytes that are undefined are getting set to FF, however when we use the same database with the J1939 Custom Device, these bytes are getting set (or being left) to 0.  If we run the J1939 Custom Device and then generate one message via CANalyzer, the undefined bytes will be set to and stay at FF.

We are still running the 2013 Version, if this behavior has changed let me know.

Thanks

Jason

[Daniel_E]

Hey Jason,

This is something I have been looking at adding as an option.  Currently, I just set the correct message size and let the XNET driver take care of the unused bytes.  I have looked into changing the default fill byte but haven't found it in the XNET driver.  If I can figure that out, I will make it an option and post the change.  However, that won't be until Feb as I am on other projects until the end of Jan.

[AGCOJason]

This is more informational for anyone who ends up looking.  I recently started working on a new HIL project with VS 2015 and newest version of XNET.  I made the change to 2015 because of native support for J1939 in the 2015 version of XNET.  After setting up the project and migrating all of the channel mappings from using the J1939 Add-on (as we had used in our 2014 project), I found that any incoming message that was not sent to ALL (broadcast message) would not populate signal data.  Talking with NI support, it appears that NI Bus Monitor and VeriStand fail to correctly handle destination node addresses and as such will not populate any signal in a J1939 message that is going to a specific node.  The XNET team indicates that they will be working to fix Bus Monitor, but VeriStand may not get native J1939 support for a while.  Official suggestion is to use this add-on (either with older version of VeriStand or recompiled for VS 2015).