Support for J1939 Transport Protocol

[Krid]

Hello,

I’m trying to receive a J1939 PGN with variable data length (DM1). I created a new XNET database and added a Cluster, whose application protocol I set to J1939. I wasn’t sure how to define variable length Messages in the database, but according to this https://forums.ni.com/t5/Automotive-and-Embedded-Networks/Variable-Legnth-J1939-Message-Handling/td-... thread, I just set the frame length to what I expect is the maximum (22 Bytes in this case).

I added a new CAN port to the system definition and imported my DM1-Message as “receive single point”. As long as the DM1 is sent as a single frame, that frame is received correctly. However, once the message length exceeds 8 bytes, the sender uses the transport protocol to transmit the message and the message is no longer received. Why not? Since XNET has built-in support for J1939 my expectation is that it automatically handles the transport protocol in the background.

I also tried to get it working by using the J1939 custom device. But the behavior is the same: The message is only received when the data length is <= 8 bytes.

Both the XNET documentation and the J1939 custom device documentation claim that they handle the J1939 transport protocol. Why is it not working? We are using VeriStand 2016 with XNET 16.0.

Thanks & Regards
Dirk

[jackstokley]

Hi Dirk,

Below is some information on using J1939 from the NI website, have you seen these before?

http://zone.ni.com/reference/en-XX/help/372841M-01/nixnet/j1939basics/

http://zone.ni.com/reference/en-XX/help/372841M-01/nixnet/mixingj1939andcanmessages/

These, along with many other resources were found with the following google search:

https://www.google.co.uk/search?q=J1939+XNET+16.0&oq=J1939+XNET+16.0&aqs=chrome..69i57.8895j0j7&sour...

I'd recommend having a look through yourself to see if any of the pages are more applicable to your application.

Thanks,

Jack

[Krid]

I've been in contact with NI support regarding this issue and they have confirmed that J1939 TP support is broken in XNET 16 and 17. It only seems to work with 17.5. It doesn't handle the priority of the frames correctly. It only works when using the lowest priority (7).

Regards

Dirk