LabVIEW
Migrating from NI-Can to xnet - Application of CAN communication
Solved!
I work with automotive devices that communicate through CAN using a custom protocol. previously using NI can it was quote-unquote simple to send and receive messages (initialize connection, send message, receive message, repeat,..., finally close connection). knowledge of how the frames were structured was only needed when building/parsing the message
How do I do back and forth CAN communication including handshakes and dynamic frame capture (device will inform how many frames will be generated)
Currently How I am attempting to use it
getting
and seeing
the {01,91} can be interpreted as time out from the unit
note that no response is captured even though two responses were present on the CAN bus
Background
A transmission will have a size indicator (1byte = number of message bytes), a command (1 byte), sub command (1 byte optional), data (0-5) bytes
A response will have a size indicator (1byte = number of message bytes),an error byte (1 byte) a command (1 byte), sub command (1 byte optional), data (0-4) bytes
if either needs to have data greater than 5/4 a multi-frame message can be used which prepends the size with a multi-frame byte (1 nibble) and expands size (3 nibble)
and the rest of the message frames are: multi-frame index (1 bytes, counter) and data (7 bytes)
before sending the remaining frames It expects a flow frame to acknowledge more frames (flow byte 0x30, number of frames between flow frames, delay between frames
Setup
Device connected to a db9 Y-Cable one end connected to a Kvaser Leaf Light HS, the other end connected to a NI-XNET USB-8502 both devices connected to my computer via USB, Device is on and powered
XNET config attached
Example of a successful communication using Kvaser as a observation:
frame 1 TX {1byte, getVersionInfo}
frame 2 RX {Multi-frame start, 18 bytes, OK, getVersionInfo, D[0], D[1], D[2], D[3]}
frame 3 TX {Flow, Send all, Send Immediate}
frame 4 RX {Multi-frame index 1, D[4], D[5], D[6], D[7], D[8], D[9], D[10]}
frame 5 RX {Multi-frame index 2, D[11], D[12], D[13], D[14], D[15]}
The error message is correct, it seems you have two frame definitions of the same frame (ID) for RX as well as for TX.
What you are transmitting here is IsoTP, which in your case reads as follows:
You send a message of 1 byte length, content 0x82 -> 01 82
The device returns 0x10 12 xx xx xx... The initial 1 means that this is the first frame of a multi-message frame, the content is 0x012 = 18 bytes long, xx xx xx ... are the first bytes of the message.
You send a data control frame 0x30 00 00 , which basically tells the device to send all followup frames immediately.
The device sends
0x 21 xx xx xx
0x 22 xx xx xx
...
The 2 means that these are the followup-frames of the multi-frame-message, the nibble after is a frame counter.
Note: Only the xx are the message bytes, and only those are counted by the 0x012.
So, this code could be a starting point. Note that there's only one frame session for sending and reading.
It reads the first frame received, checks if it's the first of a multi-frame-message, and extracts the length (0x12=18). 6 message bytes are inside this frame, and with max. 7 bytes per followup frame, two more frames are to be expected.
Please note: This is IsoTP, which is how messages, especially longer messages that do not fit into a singe frame, are transmitted. It does not care about the content of the message, just length and flow control.
The other answer mentions UDS, which describes the possible content of messages One rule is that the response message begins with the sent command, where 0x40 is added to the first byte. So, 0x10 12 C2 would be expected, because 0x82+0x40=0xC2. Since you get something different, this is no UDS.
However, UDS is THE standard in automotive, and IsoTP is THE standard transport protocol, so people mix the terms all the time.
@Sebastian.Weber wrote:
The error message is correct, it seems you have two frame definitions of the same frame (ID) for RX as well as for TX.
What you are transmitting here is IsoTP, which in your case reads as follows:
You send a message of 1 byte length, content 0x82 -> 01 82
The device returns 0x10 12 xx xx xx... The initial 1 means that this is the first frame of a multi-message frame, the content is 0x012 = 18 bytes long, xx xx xx ... are the first bytes of the message.
You send a data control frame 0x30 00 00 , which basically tells the device to send all followup frames immediately.
The device sends
0x 21 xx xx xx
0x 22 xx xx xx
...
The 2 means that these are the followup-frames of the multi-frame-message, the nibble after is a frame counter.
Note: Only the xx are the message bytes, and only those are counted by the 0x012.
So, this code could be a starting point. Note that there's only one frame session for sending and reading.
It reads the first frame received, checks if it's the first of a multi-frame-message, and extracts the length (0x12=18). 6 message bytes are inside this frame, and with max. 7 bytes per followup frame, two more frames are to be expected.
Please note: This is IsoTP, which is how messages, especially longer messages that do not fit into a singe frame, are transmitted. It does not care about the content of the message, just length and flow control.
The other answer mentions UDS, which describes the possible content of messages One rule is that the response message begins with the sent command, where 0x40 is added to the first byte. So, 0x10 12 C2 would be expected, because 0x82+0x40=0xC2. Since you get something different, this is no UDS.
However, UDS is THE standard in automotive, and IsoTP is THE standard transport protocol, so people mix the terms all the time.
Thanks Sebastian.
I didn't look too deep into the CAN data, to verify the protocol in detail.
But you gave a good explanation.
Your example with the Frame In and Out is what I would have done. ( If only I had XNET installed)
Could you attach the vi for reference?
Edit: Defiantly an issue with the Database, Deleted the other frames and It successfully received the timeout message but now I am running into an issue where by the time it sends the flow control the communication has timed out (~50ms)
I believe one issue I am having is I made the XNet Database by hand (attached in Original Post) what database are you pulling from for the TX / RX.
Device settings operates on 250kBaud sends on (arbitration id) 2024 receives on 2016, I have only worked with fixed frame CAN
Update - Part of the issue is the definitions namely the Xnet Database > Frames> Transmit time.
Dropping the value of TX from 100ms (default) to 1ms lets me get the full message (9 out of 10 times)
Setting the value of Rx to 50 ms (to match the timeout)
Stalling the the first write till after starting the read made it more consistent (stall data flow 5ms) it can run continuously for an extended period (5 minutes) without timeout
The bottom half is just checking message integrity based on the Protocol definition
