CANopen Core Protocol: A Comprehensive Guide for Electronic Engineers
As one of the most widely used fieldbuses in industrial settings, CANopen has become the preferred communication protocol for motor control, robotics, and automated production lines due to its flexible configuration, reliable real-time performance, and broad device compatibility. This article breaks down the core protocol framework of CANopen in plain language, helping you quickly grasp its working principles and key technical points.
I. NMT: The "Network Manager" of CANopen
NMT (Network Management) acts as the "command center" of the CANopen network, responsible for device state switching, online management, and heartbeat monitoring to ensure stable network operation.
- Slave Device State Switching Commands
The NMT master controls the slave’s operating state via specific commands, transmitted as a combination of function code + Node ID:
01 + Node-ID: START → Slave enters the operational state;
02 + Node-ID: STOP → Slave pauses work;
80 + Node-ID: PRE-OPERATIONAL → Slave enters the configuration state;
81 + Node-ID: Reset Application Layer → Resets slave application parameters (communication parameters are retained);
82 + Node-ID: Reset Node Communication → Resets slave communication parameters.
- Node Online & Heartbeat Mechanism
Node Online: After startup, the slave actively sends a 700h + Node-ID message (data field: 1 byte 00) to notify the master: "I am ready".
Heartbeat Message: The slave periodically sends a 700h + Node-ID message, with a 1-byte data field indicating its current state:
04: Stopped state;
05: Operational state;
7F: Pre-operational state.
Master Heartbeat: The master broadcasts its online status via a 73F message (no Node ID), letting all slaves know "The manager is online".
II. SDO: The "Parameter Configurator" of CANopen
SDO (Service Data Object) serves as the "parameter read/write tool" for CANopen, used for non-real-time configuration operations (e.g., modifying motor acceleration parameters). It adopts a request-response model, like a "one-to-one conversation" between the master and slave.
- SDO Message ID Rules
Master → Slave (Request): 600h + Node-ID;
Slave → Master (Response): 580h + Node-ID.
- SDO Parameter Reading: Master "Asks", Slave "Answers"
Master Request Message (e.g., reading the "maximum motor speed" parameter):
COB_ID
DLC
Data[0]
Data[1-2]
Data[3]
Data[4-7]
0x600+NodeID
8
0x40 (Fixed)
Object Index (e.g., 2000h)
Sub-index (e.g., 00h)
0x00 Padding
Slave Response Message (returns the parameter value):
COB_ID
DLC
Data[0]
Data[1-2]
Data[3]
Data[4-7]
0x580+NodeID
8
Command Code (varies by data length)
Object Index
Sub-index
Returned Data (max 4 bytes)
Key rules for response command codes:
1-byte data → 0x4F; 2-byte → 0x4B; 3-byte → 0x47; 4-byte → 0x43 (Pattern: Decrease by 4 for each additional byte);
Read failure → 0x80 (e.g., parameter does not exist).
III. PDO: The "Real-Time Courier" of CANopen
PDO (Process Data Object) is the real-time data transmission carrier of CANopen, designed to quickly transfer time-sensitive information such as sensor data and motor control commands. It has two types:
TPDO: Slave → Master (e.g., sensor uploading temperature data);
RPDO: Master → Slave (e.g., master sending motor speed commands).
- PDO Channel ID Rules
CANopen supports up to 4 PDO channels, each with a dedicated ID:
PDO Type
TPDO (Slave → Master)
RPDO (Master → Slave)
PDO1
180h+NodeID
200h+NodeID
PDO2
280h+NodeID
300h+NodeID
PDO3
380h+NodeID
400h+NodeID
PDO4
480h+NodeID
500h+NodeID
- PDO Trigger Mechanisms: When to Transmit Data?
PDO transmission timing is determined by the "transmission type". Common triggers include:
Synchronous Trigger: The master sends a sync message (fixed ID 080), and all slaves transmit TPDOs simultaneously;
Remote Frame Trigger: The master sends an RTR frame, and the slave returns a TPDO immediately;
Event Trigger: The slave actively sends a TPDO when data changes exceed a threshold (e.g., temperature rises from 25°C to 30°C);
Periodic Trigger: The slave sends a TPDO at fixed intervals (e.g., every 10ms).
IV. OD: The "Database" of CANopen
The Object Dictionary (OD) is the "encyclopedia of parameters" for CANopen devices. All configurable parameters (e.g., motor speed, communication baud rate) are stored here, uniquely identified by a 16-bit index + 8-bit sub-index.
The 4 main partitions of OD (like classified shelves in a library):
1000h–1FFFh: Communication Object Area → Stores configuration parameters for PDO, SDO, NMT, etc.;
2000h–5FFFh: Manufacturer-Specific Area → Vendor-defined parameters (e.g., exclusive control parameters for a brand of motor);
6000h–9FFFh: Standardized Device Area → Industry-general parameters (e.g., motor position/speed control parameters, compliant with CiA 402);
A000h–FFFFh: Reserved Area → Unused for now, reserved for future expansion.
V. Special Messages: CANopen’s "Special Messengers"
In addition to NMT, SDO, and PDO, CANopen has 3 types of "special task" messages:
Emergency Message: The Highest-Priority "Alarm"
When a slave encounters a critical fault (e.g., motor overload, sensor disconnection), it immediately sends an 080h+NodeID message. With the highest priority (smaller ID = higher priority), it ensures the master receives fault information in real time.Sync Message: Making Devices "March in Step"
The master periodically sends a fixed ID=080 sync message for multi-device collaboration (e.g., multi-axis motion control of robots). All slaves execute actions or transmit data simultaneously upon receiving the sync message.Timestamp Message: The Network’s "Unified Clock"
The master broadcasts a fixed ID=100 timestamp message to synchronize all slaves to the same time, facilitating log recording and event tracing (e.g., recording device states at a specific moment).
VI. CANopen Communication Flow: A Complete Story from Startup to Operation
Finally, let’s use a simple scenario to outline the entire CANopen communication process:
Device Online: After power-on, the slave sends a 700+NodeID (00) message to notify the master: "I am ready";
State Configuration: The master sends an 80+NodeID command, and the slave enters the "pre-operational state" (configurable);
Parameter Configuration: The master reads/writes the slave’s OD via SDO (600+NodeID), e.g., configuring PDO transmission cycles and mapped parameters;
Start Operation: The master sends an 01+NodeID command, and the slave enters the "operational state";
Real-Time Communication: The master sends a sync message (ID=080) to trigger the slave to send TPDOs (e.g., sensor data), while the master sends control commands (e.g., motor speed) via RPDO (200+NodeID);
Fault Monitoring: The slave sends an emergency message (080h+NodeID) when faulty. The master monitors the slave’s state in real time via heartbeat messages (700+NodeID), and判定设备离线 if the heartbeat times out.
Final Words
The core protocol of CANopen may seem complex, but you can quickly grasp its essence by focusing on the logic: NMT manages states, SDO manages configuration, PDO manages real-time data, and OD manages parameters. For electronics enthusiasts and engineers, mastering CANopen not only improves the development efficiency of device communication but also lays a solid foundation for industrial automation projects.
If this article helps you, feel free to like and save it! If you have questions or supplements, please leave a comment below. I will continue to share practical CANopen cases (e.g., implementing CANopen communication with STM32) in the future—stay tuned!