Flipped J1939 Destination and Source Addresses

[COwen314]

I'm having an issue correctly reading J1939 CAN infomation with any Signal Input sessions.  The issue carries over to the XNET Bus monitor, as shown below in a simple loop-back test:

Signal values 2.00 and 4.00 are written to the bus (“BeginSig” and “HaltSig”). Bus monitor shows that the correct frame, “toLowerAddress_fromHigherAddress” is written to the bus (see top right, PGN: 0xE801 [destination:0x01], Source Address: 0x02). The signals appear to be interpreted incorrectly, though, as the bus monitor indicates that “StartSig” and “EndSig” from the frame “toHigherAddress_fromLowerAddress” have received the values written as "BeginSig" and "HaltSig".

Another piece of information: “toHigherAddress_fromLowerAddress” and “toLowerAddress_fromHigherAddress” are very similar; their PGNs are 0x18E80201 and 0x18E80102 respectively (flipped destination and source addresses).

I'm using XNET 15.5 with an NI-9860. Any help would be greatly appreciated.

[KathrynTheGreat]

Hi COwen314,

When I've seen behavior like this in the past, it's been a matter of making sure that your XNET Database file is set up properly. The Bus Monitor doesn't necessarily interpret the bits in the order you would like, so you need to create a Database that specifies how you want the system to parse the incoming data. 

This page has more information about creating and working with Database files.

[JefeL]

The behavior does not appear to be isolated to the BM and is reproducable in the LabVIEW API as well. I'm able to reproduce this strange behavior despite adding an input session and code to reserve node addresses. 

I will run it by the developers to see if we can get some additional insight into what could be going on.

[JefeL]

For destination specific messages the destination address is not considered part of the PGN. With the DP bit there are only 240 x 2 destination specific addresses available. Accordingly, both frame IDs 0x18E80201 and 0x18E80102 have the same PGN component which is 0xE800. 

Having two frames in the database with the same destination specific PGN violates the J1939 standard. XNET currently treats both frames as the same PGN and updates the signals accordingly which appears to be what we are seeing here.

[COwen314]

Ok, although the problem persists even when a database containing a single frame is used:

The signal value here only changes when a frame with the arbitration ID 0x18E80201 is transmitted, despite the fact that the signal resides in a frame with the arbitration ID 0x18E80102.

[JefeL]

It appears to be a bug within the bus monitor. I am able to reproduce this behavior with the XNET 15.5 and 16.0 bus monitor. There are extensive updates to the Bus Monitor in the next release of XNET and the issue appears to be fixed.

The attached test VI demontrates the expected behavior with the XNET API. Since they are treated as the same message, changing the value of the output signal will update signals from both frames.

[COwen314]

Jefe,

This works for point to point communications, but I am looking to collect all messages on the bus (regardless of destination address).  XNET documentation for the SAE J1939:Node Address property states that "A session with a null (254) or global address (255) receives all messages sent on the bus," yet I can't get a node with a null address to properly read in all messages, and XNET seems to fail to claim the global (0xFF) address. Potentially this is a problem with the hardware on my end, but I tried to keep everything in software the same as your code. Can you post the address claiming code that you are using? For now, I switched the address claiming VI in your code with an NI example VI on my computer.

[JefeL]

The address claiming code in my test VI was pulled from the J1939 shipping examples and can be found in:

C:\<National Instruments Root Dir>\LabVIEW 2015\examples\nixnet\examples.llb

[COwen314]

Ok, that's the example that I'm using. That said, I'm still having the issues stated in my previous post. Any advice?

[JefeL]

A J1939 XNET session will start with a null address by default and or it can be explicitly claimed. Transmitting sessions without an explicitly assigned address will not have the Source Address component of their frame ID updated, i.e. the SA used will be the same as defined in the database.

I have not been able to claim a global address yet and I will consult with the developers to find out why. 

My developers indicate the case of two identical PGNs on the network (i.e 0xE800) is special and isn't supported in the J1939 standard. Is this a real world use case in which your test ECU(s) are expected to send these messages? If so we would like to work with you to identify more details to incoorperate improvements in the driver. If we change one of the frames in the test database to use a different PGN (i.e. 0xE700) the test VIs behave as expected.

In the mean time, we can use the null address to receive all messages on the bus (with the exception of identical PGNs). There is also the option of using a stream input session to read everything on the bus and then filter out the unwanted data manually.