For this whole blog, all the context of it has been over CAN 2.0, usually restricted to high speed. Most of what was discussed could also be used in terms of single wire CAN, low speed, and medium speed as well. But one thing I've avoided talking about up to this point is CAN-FD. CAN-FD is different from the normal CAN 2.0 spec in several ways and I didn't want to go into detail about CAN-FD, until there was ground work on all the other intricacies of CAN. So if you don't know anything about CAN starting here is probably a bad idea. Go back and read Parts 1, 2 and 3 and maybe part 5 too.
But CAN-FD is different. It does have a normal baud rate like normal CAN 2.0. For this example lets say it is also 1M baud which is the fastest standard CAN speed used. But with CAN-FD, during the time that the payload is being transferred, we can temporarily increase the data rate to something much higher. That way we can transfer much more data, in the same amount of time. So CAN-FD will have a second baud rate, for the rate at which the payload should be sent. This might be something like 8M. Now the bus normally communicates at the 1M slower speed, but once the payload is being sent, the rate increases to 8 times as fast as it was, then slows back down. Since this is the single largest portion of the transmission this can help out significantly in over all data rates.
What is CAN-FD (Rate Change)
CAN-FD stands for CAN Flexible Data Rates. All non CAN networks have a baud rate. This is the maximum bus transfer rate in bits per second. This does not take into account various overheads, bit packing, CRC (not related to the payload as discussed in parts 9 and 10), and other stuff. I say this because the real world transfer rate of payload data of a 500K Baud bus, is much less then 500K bits. But regardless of the actual rate, that rates used on all devices need to be the same for all of them on the same bus. If my bus is a 500K Baud, then all devices need to communicate at that 500K Baud rate. Otherwise data will not be received or sent properly. All devices use this 500K baud rate, and if it changes then all devices need to change at the same time. Changing the rate on a bus is extremely rare in my opinion so you don't really need to worry about that. Just that all devices are the correct rate.But CAN-FD is different. It does have a normal baud rate like normal CAN 2.0. For this example lets say it is also 1M baud which is the fastest standard CAN speed used. But with CAN-FD, during the time that the payload is being transferred, we can temporarily increase the data rate to something much higher. That way we can transfer much more data, in the same amount of time. So CAN-FD will have a second baud rate, for the rate at which the payload should be sent. This might be something like 8M. Now the bus normally communicates at the 1M slower speed, but once the payload is being sent, the rate increases to 8 times as fast as it was, then slows back down. Since this is the single largest portion of the transmission this can help out significantly in over all data rates.
Just like with normal CAN, all devices on the bus must match the same baud rates. This means if we are configuring CAN-FD to had 1M for normal transmission, and 8M for payload, then all CAN-FD devices must use the same two baud rates. This does have a nice benefit that normal non CAN-FD devices can be on the same bus reading and writing at 1M. In practice there maybe additional re-transmits needed which will be automatically done. But since CAN is so robust it should work just fine.
One of the benefits of CAN-FD is the ability to mix CAN-FD and non CAN-FD devices on the same bus. Obviously a 1M non CAN-FD device can only read non CAN-FD frames. Since CAN-FD transceivers are newer and more expensive, it might be a good idea to only use CAN-FD on the devices on the bus that actually use them. In many cases the transmission rates of normal CAN 2.0 is fast enough for most sensor data.
What is CAN-FD (Payload Change)
Another change to CAN-FD is the payload length. In all CAN discussions up to this point the payload of a CAN frame (Part 2) has always had a length of 8 bytes of payload down to 0 in one byte steps. This meant that all signals in the DBC database must be restricted to 64 bits of data. In practice a signals is often much less than that, and due to the double precision formatting. LabVIEW can only interact with signals of 52 or less bits, due to how the floating point double is stored in memory.
But CAN-FD increases this limit. For legacy reasons you can still have a payload from 0 up to 8 bytes in size. But now you can also have payload lengths of 12, 16, 20, 24, 32, 48, and 64 bytes. This could be used to transfer much more data for something like dumping the contents of memory, updating or flashing a device, or potentially streaming of audio/video. Of course since CAN is non-deterministic, and due to priority the frames, audio and video probably aren't ideal uses here but it has been used for that in some cases.
Another common use for larger payloads, is just to combine data that was previously sent with multiple frames, but can now be sent with 8 times fewer. Previously you may have had 8 IDs each sending 8 bytes of data data from a single device at different priority levels. Now you can send all of that in the same single frame. And with the increased data rate this means it happens faster.
If you are programming an ECU you likely have lots of data that needs to dump. Previously I've mentioned the ISO-15765 (Part 8) protocol and how it can be used to send or receive large amounts of data, by using multiple frames with a single ID. ISO-15765 and UDS is just a standard protocol on top of CAN and so it can be a feature of CAN-FD as well. The obvious benefit here is that the overhead of 1 bytes per frame is much less impactful when you have a payload size of 64 bytes, as apposed to 8 as with CAN 2.0. So if you are flashing an ECU over CAN-FD you will be able to transfer much more quickly due to less overhead, faster transmission rates, and a larger payload size.
Practical Changes (Sample Point)
There are more settings when configuring the bus, than just the baud rate. In most cases you can just specify the baud rate and be good to go. But another setting that is less often needed in normal CAN is the sample point. You may see the sample point have various other names like bit timing and bit settings. What this essentially means, is at what point in the transmission, does the transceiver take the reading and determine if it is a 0 or a 1? In most cases this doesn't have to be an exact number it can just be close. And typically this is around 87.5%. This percentage represents how far into the value change, that the reading is taken. Reading this too early and the value may not have changed yet, and reading too late might mean reading reflections on the bus giving incorrect values.
When you open an NI-XNet session you can set the baud rate, which is a single U64 value. This value can be bit packed containing more information than just the rate. Using the Custom Baudrate tool you can determine what the custom baud rate is for the various rate and sample point settings.
If you are developing in LabVIEW and using XNet, you can use this handy calculator which generates the custom baud rate needed to configure a rate and sample point.
CAN-FD Hardware Support
So what about all of our CAN 2.0 tools? Are they useless in CAN-FD applications? Well not quite. But many older CAN hardware won't have CAN-FD functionality. In Part 1 I talked about the various CAN hardware mentioning pricing and functionality. Most low cost CAN hardware is going to be CAN 2.0 only. Any NI XNet hardware that is capable of high speed CAN, is also capable of CAN-FD. The XNet API has had some support for CAN-FD since at least 2014. For Vector the newer VN16xx series of hardware is capable of CAN-FD. And from Intrepid the newer hardware line has a mixture of CAN 2.0, LIN, and CAN-FD features. But due to the tighter integration in LabVIEW and better support XNet is my preferred hardware in CAN-FD applications.
CAN-FD Software Support
As I mentioned the NI-XNet API has CAN-FD functionality built in. However many 3rd party software tools don't have CAN-FD functionality. Vector hasn't released any software update to use CAN-FD hardware in LabVIEW, and only wrappers of their drivers are available online. Vector's software packages like CANalyzer have been updated for CAN-FD. Similarly updates from Intrepid are primarily for their own software tools and not the LabVIEW drivers. Many of the software tools I've posted online haven't been updated to support CAN-FD yet either but at least mine are open source and can be modified. When I get time I hope to update the whole software package line to use CAN-FD.
Part 15
In Part 15 of the CAN Blog series we will cover LIN, and the similarities and differences it has to CAN. This will cover the basics of wiring master/slave relationships, as well as database and scaling options as they pertain to LabVIEW and XNet.