Flipped J1939 Destination and Source Addresses

[COwen314]

Yes, this is a real world use case for an transmission EOL test system being developed by Eaton.  Eaton uses J1939 extensively on their commercial vehicles and equipment, and uses databases like this on a regular basis.

Eaton engineers have suggested that some PGNs have special handling under J1939 specs – for example, EF00 is a Prop A (proprietary) message under J1939, where it is up to the developer to use as they need.  The PGN uses the SA and DA to determine who it is from (SA) and who it is going to (DA).

So 0x18EF0309 is from x09 to x03, and the developer can define as needed the payload data.  0x18EF0903 is from x03 to x09, and the developer can define that as needed, even different from the other EF messages.  Is that supported?  Same PGN, different definitions.  Eaton does this commonly.

We should mention that Eaton has historically used primarily Vector CAN tools.  This particular test stand involved Eaton moving away from Vector tools (at DMC’s recommendation) to give NI XNET tools a shot.  We would really like to provide Eaton with a strong/prompt resolution to these issues, as this would help make the case that NI tools are a truly good fit to utilize more broadly with future J1939 based systems/products Eaton develops.

[JefeL]

I will forward the use case information on the developers and see if they have any feedback.

In our case, since we want to make sure we receive every frame with this specific PGN we can try using a queued input session. It uses the ToHigher frame but since it is treated as the same as the ToLower frame we will capture both in the queue if the node addresses are set to null.

The transmitting address is set to null to prevent XNET from overwriting the SA field in the frame ID. The receiving address is set to null to prevent the frames from being filtered by the DA field.

[COwen314]

Thanks Jeff. This is OK, although when using frame input sessions one loses the ability to parse frames into signals though, right?

Another aspect of J1939 that's very relevant to Eaton is variable length message handling. I figured that this is a separate topic, and opened a separate thread here: http://forums.ni.com/t5/Automotive-and-Embedded-Networks/Variable-Legnth-J1939-Message-Handling/td-p...

I figured it might be good to mention here, so that the developers could potentially talk about these topics at the same time.

[JefeL]

Hi COwen,

XNET does offer the ability to convert a received frame to a signal and I have modified the previous example to include a signal conversion. The conversion sessions work much like a single point session in that they share a single frame object in memory and converting multiple frames will overwrite the exiting data in the frame object. For most normal frames this works pretty well but it can lead to some unexpected results when multiplexed frames are introduced.

[COwen314]

Jeff,

Sorry about the relatively long hiatus. Thanks for letting me know about conversion sessions, they've been helpful. I need to log the signal values (along with their timestamps) pulled from CAN frames using a large database that contains frames with repeated PGNs. Would you recommend the following approach?

• Programatically create a queued frame input session for each set of frames with a shared PGN
• Use the signals from all of these frames to create a conversion session to handle signal parsing
• For all frames with a unique PGN, use their signals to create an XY signal input session

[JefeL]

Hi COwen314

Your suggested approach should work with XNET 16.1 which has now been released. There have been many J1939 specific improvements made in this release in addition to several bus monitor features being added.

My experiments with 16.1 show that creating a queued input session with a null address will read all of the frames for that destination specific PGN i.e both ToHigher and ToLower. Claiming an address for the receiving session will show only those frames that have the appropriate destination address.

My experiments with 15.5 and 16.0 do not show this same behavior. Claiming a node address for a receiving session will show only the frames with a matching DA just as above. When a null address is used it will not receive all of the frames for the destination specific PGN, i.e both ToHigher and ToLower, but will instead show only one frame. The frame that is received in my experiments was ToLower even though the session was created with the ToHigher frame. After several experiments it remains unclear why the ToLower frame would be the only frame received but it is likely unexpected behavior that has been fixed in 16.1.

I used the same VI in my experiments that I posted earlier and will attach it again for reference.