CANopen basics — CiA 301 / 302 / 402 and how to develop CANopen devices
CANopen is an industrial network standard that adds a common data model, the object dictionary (OD), on top of the CAN physical and data-link layers. Its main advantage is that devices from different manufacturers can be configured, monitored, and controlled in the same way. This guide explains the structure you need to understand first when making a device CANopen-capable.
Contents
The object dictionary is at the center
A CANopen device exposes all of its parameters, process values, and states as a table addressed by a 16-bit index and an 8-bit sub-index. This is the OD.
Communication, configuration, and diagnostics all come down to “which OD entry is read or written.” Once you grasp this, the roles of the communication services below fall into place.
Three communication services (PDO, SDO, NMT)
PDO (Process Data Object) sends process data cyclically or on events. You map in advance which OD entry goes into which byte of the CAN frame, and at run time only the data is sent. Up to 8 bytes, unconfirmed. Control loops use PDOs.
SDO (Service Data Object) reads and writes any OD entry with confirmation. Data longer than 8 bytes can be transferred in segments. It is used for configuration and diagnostics, but because each exchange needs a round trip, it is not suited to cyclic data acquisition.
NMT (Network Management) moves nodes between states (Initializing / Pre-operational / Operational / Stopped). PDOs do not flow until a node is Operational — the cause of many bring-up problems.
The main CiA specifications
CiA 301: the communication profile. The OD structure, PDO/SDO/NMT, heartbeat, emergency messages, SYNC — all the CANopen fundamentals are here.
CiA 302: additional functions. It specifies the NMT master, network boot-up (configuration distributed by a configuration manager), master redundancy with Flying Master (302-2), program download over CANopen (302-3), and multi-level networks (302-7).
CiA 402: the device profile for motion control. It standardizes the state machine and operating modes of servo drives, steppers, and inverters.
CiA 304: safety-related communication (SRDO). CiA 309: interfaces to other networks such as TCP/IP.
How much of this your device needs depends on whether it only has to work as a slave, whether you implement a master, whether it is motion control or general-purpose I/O, and whether it carries safety functions.
How EDS, XDD, and DCF relate
An EDS (Electronic Data Sheet) describes what a device can do. The XML form is the XDD. The device manufacturer provides it.
A DCF (Device Configuration File) records how the device was actually configured on a given network. A configuration tool reads the EDS, fills in the settings, and writes out a DCF.
If you proceed without understanding how these three relate, you run into hard-to-isolate problems such as “it works with my desk tool but not when started through the configuration manager.”
What to decide first in device development
(1) Master or slave (or both)? (2) Which device profile — general-purpose I/O or CiA 402? (3) How many PDOs and at what update rate? (4) Which extras — SRDO, MPDO, bootloader, Flying Master, etc.? (5) Bit rate and node-ID assignment — fixed or LSS? (6) How will you provide the EDS?
Once these are settled, you can also decide how to implement: port a stack from source, fit a CANopen-capable module, or add an external gateway.
Troubleshooting order at bring-up
When real hardware will not communicate, check in this order:
Matching bit rate and node ID → does NMT bring the node to Pre-operational → can the OD be read with SDO → is the PDO mapping as expected → heartbeat / node-guarding settings → SYNC period.
Suspecting downstream items while the problem is upstream wastes time. Keep to the order.
Frequently asked questions
- How does CANopen differ from CAN?
- CAN defines how frames are sent, not what they mean. CANopen is a higher layer that adds a common data model — the object dictionary — and the PDO/SDO/NMT communication services. The value of “handling different manufacturers' devices the same way” comes only from this higher layer.
- How can we make an existing device CANopen-capable?
- There are three ways: port a stack from source to your own MCU, fit a module or chip with CANopen built in, or add an external gateway. The best choice depends on development effort, BOM cost, production volume, and how easily the specification can change later.
- Can we consult you about adoption?
- Yes. Tell us the device profile, number of PDOs, add-ons you need, target MCU, and expected quantity, and we will reply with a proposed configuration and a rough estimate. We also take on stack porting and bring-up.
Related product categories and solutions
- Middleware / protocol stacks (product category)
- Automotive and industrial network devices / gateways (product category)
- Compilers, IDEs, and build environments (product category)
- Industrial network (CANopen) device development (solution)
- Real-time control on Windows / industrial automation (solution)
Other technical guides
- How to choose an embedded RTOS
- SAE J1939 basics — CAN for commercial, construction, and agricultural vehicles
- UDS / DoIP vehicle diagnostics basics
- Embedded debugging and trace basics
- Designing production programming — cycle time, gang programming, and IP protection
- Automotive Ethernet basics — 100/1000BASE-T1, time sync, and measurement
- LIN basics — ISO 17987, LDF, and conformance testing
- What is functional safety? — an introduction to ISO 26262 / IEC 61508
Look up the terms
Discuss your setup
If you organize your requirements along the lines of this guide, we can reply early with a proposed configuration and a rough estimate. Partial questions are welcome too.