XNET CAN Frame Trouble - Extended ID and Remote Frame

[JohnG3k]

After much debugging, I have finally got my CAN XNET proof of concept VI working. But to do so, I have found that the 'extended?' bool and 'echo?' bool do not function as labeled or as documented.

I am using a USB-8502 with Port 1 and Port 2 connected to each other. After failing to get my application working, I opened up a 'NI-XNET Bus Monitor' window for each port, and was able to communicate between them without issue. Back to my code, after a lengthy debugging process I was able to narrow the problem to the transmit VI I created, and more specifically the settings of those two bools mentioned above. The problem in a nutshell is that data was not being received. The frames were, but no data (as seen in Bus Monitor). We use an extended ID, so naturally I had 'extended?' selected. But if I unselected it, suddenly I got data! Also discovered that the identifier that was shown in the Bus Monitor was truncated to 11 bits, unless I had the 'echo?' selected. 

Looking at the Bus Monitor setup, the settings are very similar to the CAN frame:

I notice there are also two bools here, but with different labels. So I theorized that these are the same two bools that appear in the frame, but labeled differently. And indeed after much testing, I have been able to replicate the same behavior in my application when I set the bools such that the can frame 'echo?' is set to be the same as 'Extended ID' and the can frame 'extended?' is set the same as 'Remote Frame'.

Has anyone else experienced this?

Can anyone tell me what the 'Remote Frame' setting does? 

I was puzzled further as our application that uses cRIO, uses these same settings ('extended?' set TRUE), but yet is able to transmit data. So I am theorizing that the 'Remote Frame' bool, just sets the RTR bit in the actual can frame, and the Bus Monitor just ignores the data and doesn't display it when this bit is set (where the device we are communicating to ignores the RTR bit and accepts the data). Can anyone confirm if this?

[BowenM]

Interesting problem, and not one I've seen before. Unfortunately I don't have XNET installed right now, but I'd be curious to know what is going on.

I believe there is a way to pull raw frame data in both directions. You should be able to use that to look at the IDE and RTR bits from the header to see what exactly those booleans in the "XNET CAN frame" cluster toggle... and to see if they're toggled the same on your incoming frames.

[JohnG3k]

Thanks BowenM

Unfortunately I can't find anyway to looks at the raw frame. There is a 'Frame Raw' instance of 'XNET Read.vi', but this isn't raw frames, it is processed data presented as a U8 array (instead of cluster), and only has the frame ID and payload from the actual frame (as well as a bunch of other information). I've also found a XNET python driver, and the nixnet.types.RawFrame method has exactly the same information that is contained in the byte array from the XNET Read.vi (timestamp, identifier, type, flags, info, payload). So if that didn't have the actual CAN frame, I'm guessing it is not available.

If you do know of a way of getting the actual raw frame, it would be great to hear about it.