Working with the CAN Bus
Several IO types exchange data over CAN. This page covers the shared concepts they depend on; the per-IO pages cover the specifics.
CAN bus definition
Before adding any CAN IO you must have a CAN bus defined, with:
| Setting | Meaning |
|---|---|
| CAN ID / bus | Which physical CAN channel. |
| Baud rate | Bus speed (e.g. 500 kbit/s). |
| CAN FD | Enable FD and set the FD data baud rate, if used. |
| Termination | Enable the on-board 120 Ω terminator when the controller is an end node. |
Two ways to use CAN
1. Raw frame signals
Decode/encode individual CANbus signals directly from raw CAN frames by hand. Use these when you have a DBC or know the byte layout: - CAN Bus Input — extract a signal from an incoming frame (message ID, endianness/bitfield, length, offset, scaling, timeout behaviour). - CAN Bus Output — pack a signal into an outgoing frame.
2. CAN Presets
CAN Presets are predefined device profiles (dashes, ECUs, shifters, keypads,
paddles…) that live in canbusEntities/. A preset publishes/consumes a set of
named CAN objects and handles all the byte decoding/encoding for you. When you
add a preset it automatically creates the matching object IO — you reference
or drive those rather than hand-decoding bytes:
- CAN Object Input — a preset-created input
carrying a named object's value (not configured by hand).
- CAN Object Output — a named object the preset
sends, driven by a source value.
Choosing between them
- Use raw frame signals for arbitrary/custom devices where you know the layout.
- Use CAN Presets for supported devices — less error-prone, no manual byte math.
Timeouts (inputs)
CAN inputs define what to report if a frame stops arriving (TimeoutMode):
UsePrevious, UseDefault, or UseFault. Set a timeout for any safety-relevant
signal so a dropped frame is detected rather than silently held.