The screenshot above shows the home screen of a sugar beet harvester. The home screen receives roughly 50 CAN messages per second and displays the contents of the CAN messages numerically or graphically.
Every number on the home screen is extracted from a CAN message. The axle positions in the harvester schematic in the upper right quadrant are extracted from CAN messages as well.
CAN messages come in two varieties: peer-to-peer messages and broadcast messages. Peer-to-peer messages are used to write and read the properties of remote ECUs (electronic control units). All the numbers on the right-hand side of the home screen are properties from remote ECUs. The five main ECUs of the harvester have 1800 properties.
ECUs use broadcast messages to publish parameter values like vehicle speed, engine speed and diesel consumption. Broadcast messages work similar to Qt signals. The five main ECUs define 350 broadcast messages or signals. The ECUs emit 9 signals 50-100 times per second, 79 signals 20-50 times, 199 signals 2-5 times, and the rest less than 2 times.
If you added up these frequencies, you would have nearly 2700 signal emissions per second. Fortunately, this is a theoretical number, because not all signals are sent at the same time. The terminal sees 1100 CAN messages per second and 1700 at peak times.
If 1100 CAN messages hit the HMI per second, the HMI would at least start to stutter if not freeze. The main goal of the CAN middleware – the layer between QtCanBus and the QML HMI – is to reduce the number of CAN messages forwarded to the HMI. The HMI works smoothly up to 300 CAN messages per second.
In my talk A Deep Dive into Qt CAN Bus, I show you how to reduce the number of CAN messages from over 1100 to less than 300, how to avoid write buffer overflows when sending 100 or 200 messages without a pause, and how to generate most code from files specifying the CAN messages. Here are the slides from my talk.
You find the video of my talk here. Stay tuned for a series of blog post.