Why CANopen Is More Than a Set of CAN IDs
After learning CAN, it is easy to see CANopen as “some fixed message IDs on CAN”. That is only the surface.
CAN handles arbitration, frame transfer, and error handling on a shared bus. CANopen solves a higher-level problem: how an industrial device exposes parameters, exchanges cyclic process data, is configured, enters operation, reports faults, and tells tools what objects it supports.
A better first model is:
CAN: frames, IDs, arbitration, ACK, error handling
CANopen: device model, object dictionary, process data, parameter access, state machine, errors
CANopen does not replace CAN. It adds an application-layer order above CAN frames and arbitration.
Object Dictionary Is the Core
The most important CANopen concept is the Object Dictionary.
It is a unified indexed space for parameters, state, control values, and communication configuration:
index + subindex -> object value
It may contain:
- device type
- error register
- device name and version
- communication parameters
- PDO mapping
- controlword and statusword
- speed, position, current, IO state
- vendor-specific objects
The object dictionary gives devices a common access model. Tools do not need a new private command set for every vendor. They access objects by index and subindex.
This is the difference from raw CAN. Raw CAN gives you an ID and bytes. CANopen tries to place those values into a device model.
PDO Is Process Data, SDO Is Parameter Access
The two most common CANopen communication types are PDO and SDO.
PDO, Process Data Object, carries process data. It fits short, cyclic, time-sensitive data:
- input state
- output control
- position
- speed
- current
- IO bitmap
PDO usually does not carry index/subindex in every frame. It depends on preconfigured mapping:
PDO frame bytes -> object dictionary entries
This is efficient, but both sides must know the PDO mapping.
SDO, Service Data Object, accesses specific object dictionary entries. It fits configuration, debugging, parameter reads, and low-frequency access:
read object 0x1018 sub 1
write object 0x1600 sub 1
A rough rule:
PDO: fast process data exchange
SDO: object-addressed parameter access
For debugging, this boundary matters. If PDO data is wrong, inspect PDO mapping, trigger mode, and device state. If SDO fails, inspect object existence, access rights, data length, and abort code.
NMT Defines Device State
A CANopen device does not start full process-data exchange immediately after power-up. NMT, Network Management, controls node state.
Common states:
- Initialization
- Pre-operational
- Operational
- Stopped
Roughly:
Pre-operational: configuration is possible, normal PDO exchange may not run
Operational: normal PDO communication runs
Stopped: most communication stops except necessary management
So “the node is visible on the bus” does not mean “the device can be controlled”. In Pre-operational, SDO may work while PDO does not behave as expected.
Heartbeat Shows Whether a Node Is Alive
CANopen commonly uses heartbeat for online monitoring.
A node periodically sends its state:
node id -> heartbeat frame -> current NMT state
The master or other nodes use heartbeat to detect online state, state changes, and timeout.
This is not application success. Heartbeat only says the node periodically reported state. It does not prove a control command completed.
For intermittent drops, inspect:
- whether heartbeat really stopped
- whether heartbeat producer time is too short
- whether bus load causes delay
- whether the node rebooted
- whether NMT state keeps changing
EMCY Reports Urgent Faults
EMCY, Emergency Object, reports device faults quickly.
Typical fields include:
- error code
- error register
- manufacturer-specific error field
It fits overcurrent, overvoltage, encoder fault, communication fault, drive alarm, and similar conditions.
EMCY is not a logging system or a full diagnostic protocol. Its value is that a device can actively report a high-priority fault so the control system can protect or alarm quickly.
EDS and DCF Let Tools Understand Devices
CANopen commonly uses EDS and DCF.
EDS, Electronic Data Sheet, describes supported objects, default values, access rights, data types, and communication abilities.
DCF, Device Configuration File, is a device description with concrete configuration.
Without EDS/DCF, engineers can still configure objects from manuals, but tools, master configuration, and field maintenance become much harder.
This is one reason CANopen is more engineered than a private CAN protocol. It defines not only runtime frames, but also how tools discover and configure devices.
COB-ID and Node ID
CANopen has default CAN ID allocation rules. Many communication-object IDs are built from a function code plus node id.
For example, PDO, SDO, and heartbeat for different nodes fall into different ID ranges.
This creates a default topology quickly:
node id 1 -> default PDO/SDO/heartbeat IDs
node id 2 -> another default PDO/SDO/heartbeat set
But default rules do not remove configuration. PDO COB-ID, mapping objects, transmission type, event timer, and synchronization can all be adjusted.
When seeing a CAN ID in a trace, first decide whether it is a CANopen default communication object or a vendor-specific frame.
Boundary With UDS and CAN TP
CANopen, UDS, and CAN TP can all run on CAN, but they solve different problems:
CAN TP: long-message segmentation, flow control, reassembly
UDS: diagnostic sessions, services, access control, flashing
CANopen: industrial device object model, process data, parameter access, node management
CANopen is strong in industrial control device models. UDS is strong in vehicle diagnostic service models. CAN TP is a transport helper and does not define device objects or business services.
Mixing them leads to bad debugging. If PDO does not update, do not start with UDS session state. If SDO aborts, do not start with CAN TP segmentation.
Field Debugging Order
Debug CANopen by layers:
- Check CAN physical and basic communication: baud rate, termination, error frames, bus off.
- Check node id: conflict and master configuration.
- Check NMT state: whether the node reaches Operational.
- Check heartbeat: stable period and state changes.
- Check PDO: COB-ID, mapping, transmission type, event timer, SYNC relation.
- Check SDO: object existence, access rights, data length, abort code.
- Check EMCY: whether error codes indicate device faults.
- Check EDS/DCF: whether tool configuration matches the actual object dictionary.
Three Final Judgments
First, CANopen is centered on the object dictionary and device model, not on fixed CAN IDs.
Second, PDO and SDO must be separated: PDO is for real-time process data, SDO is for object-addressed parameter access.
Third, field problems involve CAN basics, NMT state, heartbeat, PDO mapping, SDO aborts, and EMCY. Looking only at CAN IDs shows bytes but not device state.