P-09 — CAN / CANopen

Embedded fieldbus with bit-level priority arbitration.

Estimated 14 minutes.

Born for cars, adopted by machines

Bosch invented CAN in 1986 for in-vehicle networks: cheap, robust, multi-master, no central controller. The same properties — short messages, deterministic priority, two-wire differential — made it perfect for embedded industrial gear. CANopen is the application layer that turned raw CAN frames into a real device protocol.

Two layers, one cable

Think of it as a stack: CAN (the physical + data-link layer — frames, arbitration, CRC) and CANopen (the application layer — node IDs, object dictionary, PDO/SDO services, NMT state machine). Every CANopen device speaks plain CAN underneath.

How arbitration actually works

No collisions, no token, no master. Every node that wants to talk starts transmitting at the same time. Bit by bit, a "0" (dominant) wins over a "1" (recessive). A node sending "1" while it sees "0" on the bus immediately stops — losing without retransmitting later. Lowest CAN ID = highest priority.

Watch arbitration bit by bit

Three nodes try to talk at once. Step one bit at a time and see who drops out.

Who wins?

Three nodes start transmitting. Their CAN IDs are 0x301, 0x180 and 0x281. Which frame goes through first?

  • 0x301 — highest number, most important
  • 0x180 — lowest number, highest priority
  • 0x281 — middle priority, compromise winner
  • Random — collision, all three retry

COB-ID = function code + node ID

CANopen splits the 11-bit CAN identifier into two parts: a 4-bit function code (NMT, SYNC, PDO1, SDO tx…) and a 7-bit node ID (1–127). One number tells you both WHAT the message is and WHO sent it. That is why CANopen needs no separate "type" field.

Decode any COB-ID

Click each preset to see how the 11 bits split into function code + node ID.

The object dictionary

Every CANopen device exposes a 16-bit-indexed dictionary of objects (0x0000–0xFFFF), each with optional sub-indices. Standard ranges are reserved (e.g. 0x1000–0x1FFF = communication, 0x6000–0x9FFF = device profile). It is the "RAM map" of the device, browsable over the bus.

Browse a real dictionary

A CiA 402 motor drive's OD. Tap entries to inspect them.

PDO vs SDO

CANopen has two ways to move data. PDOs (Process Data Objects) are pre-mapped, fast, fire-and-forget — one CAN frame carries up to 8 bytes of process data. SDOs (Service Data Objects) are confirmed, slower, used to read/write any OD entry on demand. Configuration is SDO. Real-time control is PDO.

Compare them side by side

Pick the right service

You need to update a motor's torque setpoint at 1 kHz from the controller. Which CANopen service?

  • SDO write to 0x6071 every cycle
  • Map 0x6071 into an RPDO once, then send the RPDO every cycle
  • NMT broadcast
  • Heartbeat

Build a CAN frame

Edit the COB-ID and data bytes. Watch the on-the-wire breakdown update live.

Final challenge

A CAN bus carries cyclic frames at IDs 0x180, 0x200 and 0x300, plus an emergency stop wired to ID 0x080. The bus is heavily loaded. What guarantees the e-stop frame will be transmitted before any cyclic data, even mid-load?

  • A higher baud rate
  • CAN priority arbitration — lower ID 0x080 always wins the bus
  • A separate physical wire for the e-stop
  • A QoS field in the CAN header

What you learned

  • CAN: two-wire, multi-master, lossless bit-level priority arbitration.
  • Lowest CAN ID wins — dominant 0 overrides recessive 1.
  • CANopen splits 11-bit IDs into function code (4) + node ID (7) = COB-ID.
  • Object dictionary indexes every parameter and process variable in the device.
  • PDOs = fast cyclic process data. SDOs = on-demand confirmed configuration.

CAN / CANopen complete

  • You can predict who wins a CAN bus arbitration round.
  • You can decode a COB-ID into function + node.
  • You know when to use PDOs vs SDOs.