Tackling CAN FD with LabVIEW
12 May 2020 by Dawid Wozny
Introduction
A year ago we had a project to completely rebuild an existing test rig to accommodate a change in the Unit Under Test (UUT). It was a pretty big task, but here I will only focus on communication. The existing rig was communicating with the UUT over traditional High Speed (HS) CAN. The requirement was to move from HS CAN to CAN FD.
The idea behind CAN FD is to increase the throughput of the CAN bus. In order to achieve this the maximum baudrate and frame size have been increased, among other optimisations. It wouldn’t be a challenge for us if that was the only change, but CAN FD also introduces some changes to the protocol. One of these changes is being able handle multiple Protocol Data Units (PDU) in one frame and also the PDUs may or may not be present in every single frame – dynamic PDUs. None of these features were present a year ago in NI XNET and to my knowledge are still not natively supported (as of May 2020).
CAN Frames
Let’s take a step back and have a look at a traditional CAN frame. Without going into too much detail about specific bits within the frame it can be simplified to ID and Payload
The important fact is a traditional CAN frame has only one PDU. I am not sure if in traditional CAN it was actually called a PDU, I guess it was just the frame’s payload but for the sake of comparison with CAN FD let’s assume it was just one PDU. There are some other facts about traditional CAN, like some values could be split across multiple sequential frames and signal could be multiplexed, but it is still different to handling multiple PDUs.
Ok, so traditional CAN has one PDU, how does it look with CAN FD? Well it can have multiple PDUs and not all of them need to be present every single time. A CAN FD frame, depending on PDUs timing, may look like this:
The frame above can handle three PDUs but not all of them need to be present in every single transmitted frame – it depends on PDUs timing. This is another change, in traditional CAN only frame timing was considered, CAN FD allows for specific PDUs being sent in one frame to have different timing.
Our Solution
What’s the big deal then? Well, as I mentioned the CAN FD features are not supported by NI XNET, so it cannot be directly encoded easily. One way of approaching it would be to find every PDU within a CAN FD frame and then encode each one manually - write everything from scratch. This would be really tedious and not a very maintainable solution. It would require detailed knowledge about the signal encoding like start\end bit, endianness, scaling etc. - something that is already handled by NI XNET, but only for frames with one PDU.
Our approach was to implement a PDU extraction function, which takes an incoming CAN FD frame and extracts the PDUs. A pseudo frame is then created for each PDU received, a single PDU per frame, to make the frame compatible with NI XNET encoding. The received PDUs are then combined with the PDUs that weren’t included in the received CAN FD frame, which are stored in memory. We then have a set of frames that match the DBC file that we can use with NI XNET to determine the value of each signal e.g. Torque = 10Nm. The steps for sending and receiving frames are broken down below:
- Receiving
- Frame received – check if it is required by the system (hardcoded or taken from configuration file)
- Parse PDUs -> create array
- Find header
- Get PDU based on length in header
- Store it in array
- Go to the next header until there is no more payload
- Combine PDUs received with PDUs from memory
- Encode signals using NI XNET as if they are frames with only one PDU
- Transmission
- Encode all the signals into frames using NI XNET
- Check timing of each PDU so that CAN FD frame is assembled with the right PDUs
- When the PDUs are due to be sent, assemble them into a frame
- Send Frame
Final thoughts
It would be difficult to cover the algorithm in much more detail without losing the bigger picture so I thought I would cover some of the assumptions\corner cases here. There are couple of things worth mentioning:
- Everything we have done was for encoding and decoding the current value of the signal not waveform
- It is normal that a frame has only a subset of PDUs. Arrival of frame could contain only a few PDUs and if the other PDUs last values were not stored temporarily it would be difficult to report current state of all the signals.
- Implemented system has been done on RT PXI which allowed for deterministic software timing when transmitting frames
Back to Blog listings