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.

Schema: Canbus, CanbusInputFrameDescription, CanbusOutputFrameDescription
and CanbusEntityHandler in config/Config.proto; the canbusEntities/
folder holds the predefined CAN Presets.

CAN bus definition¶

Before adding any CAN IO you must have a CAN bus defined, with:

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.