1. Overview of CANopen Protocol
CANopen is a high-level communication protocol based on the CAN (Controller Area Network) bus, maintained and standardized by the CiA (CAN in Automation) international user and manufacturer organization. Its core goal is to define a network layer and application layer specification for embedded systems to ensure that devices produced by different manufacturers can achieve seamless interconnection and interoperability on the same CAN bus.
Core Advantages
The most significant advantage of CANopen is its device interoperability. As long as devices from different manufacturers comply with the CANopen standard, they can work together in the same network without a lot of custom development, which greatly simplifies system integration and reduces development costs and time.
Application areas
The CANopen protocol is widely used in the following areas due to its high reliability, real-time performance, flexibility and standardization:
• Motion control: precise control of motors, drives, etc.
• Industrial automation: PLC, sensors, actuators, HMI, etc.
• Robotics: multi-axis robot control
• Medical equipment: diagnostic and treatment equipment
• Building automation: HVAC systems, lighting control
• Rail transit: train control systems
• Marine electronics: navigation and control systems
2. CANopen Core Concepts
2.1 Object Dictionary (OD)
The object dictionary is the core of the CANopen device and can be likened to the "brain" or "configuration file" of the device. It is a standardized and structured parameter storage area that contains all configurable parameters, status information, diagnostic data, and communication settings of the device.
Core Function
•Parameter configuration: allows external devices (such as NMT master stations) to modify the operating parameters of the device through the network
•Status reading: provides a unified access interface for the current status and measurement values of the device
•Function definition: defines the functions and capabilities supported by the device
Structured storage
Each entry in the object dictionary is identified by a unique 16-bit index and an optional 8-bit sub-index:
• Index: Similar to the main address, it is used to identify a main function or parameter group
• Sub-index: Similar to the secondary address, it is used to identify a specific sub-parameter or array element in the main parameter group
• Example: 0x1000:00 indicates the device type, 0x1017:00 indicates the heartbeat cycle
Content classification
• Standard defined entries: The protocol reserves a specific index range for common functions, such as 0x1000 to 0x1FFF, which is usually used for communication parameters and general device information
• Application profile defined entries: Standardized object dictionary entries are defined for specific device types (such as CiA 401 general I/O, CiA 402 motion control)
Manufacturer customized extension entries: Manufacturers can add unique functions and parameters within the custom range reserved by the protocol (usually 0x2000 to 0x5FFF)
Access method
Entries in the object dictionary are usually read and written via the SDO (Service Data Object) protocol. SDO provides a reliable, request/response communication mechanism that is well suited for non-real-time parameter configuration and diagnostics.
2.2 Communication Objects
The CANopen protocol defines several different types of communication objects (COBs), each of which has its own specific functions and communication models, and its type and priority are determined by its COB-ID.
•NMT (Network Management): Network management is the "brain" of the CANopen network, responsible for controlling the operating status of all devices in the network (start, stop, reset, etc.), using a master-slave mode, usually with an NMT master station managing all slave stations, and NMT messages have the highest priority.
•Heartbeat: The heartbeat mechanism is used to periodically report the current NMT status of the device, allowing other devices in the network (especially the NMT master station) to monitor the online status and health of the device.
•SDO (Service Data Object): Service data objects are used to transmit non-real-time but reliable configuration, diagnostic and parameter data, using a request/response service model to ensure the integrity and correctness of data transmission.
•PDO (Process Data Object): Process data objects are used to transmit real-time, high-priority, small-batch (usually 1-8 bytes) process data. They use broadcast/multicast communication mode and do not perform handshake confirmation to achieve fast and efficient data exchange.
•SYNC (Synchronous Object): Synchronous objects are periodic broadcast messages used to coordinate the periodic actions of multiple devices in the network to ensure that multiple devices perform tasks synchronously.
•EMCY (Emergency Object): Emergency objects are used to report faults or errors that occur inside a device. They are sent immediately when a device detects an internal error. They have high priority and allow related nodes to respond to abnormalities in a timely manner.
2.3 Node ID
Node-ID is a unique identifier for each device in a CANopen network:
• Uniqueness: In a CANopen network, each device (slave) must be assigned a unique 7-bit Node-ID ranging from 1 to 127
• NMT broadcast address: Node-ID 0 is a special value used for the NMT master to send broadcast commands
• Configuration method:
◦ Hardware configuration: Directly set on the device through DIP switches, jumper caps, etc.
◦ Software configuration: Configured through SDO when the device starts
◦ LSS (Layer Setting Services): The underlying service defined by the CANopen standard allows the master to dynamically allocate and configure Node-ID
2.4 COB-ID（Communication Object Identifier）
COB-ID is an 11-bit CAN frame ID used to identify the CAN frame type and priority in the CANopen protocol, following the priority rules of the CAN standard: the smaller the value, the higher the priority.
Composition
COB-ID usually consists of two parts:
• Function Code: Identifies the type of CANopen message (such as NMT, SDO, PDO, Heartbeat, etc.)
• Node-ID: Identifies the source device or target device of the message
Determine the message type and priority
• Message type: The function code determines which communication object the CANopen message is
• Priority: A lower COB-ID value means a higher CAN bus priority, which is critical for real-time communication
Example
• 0x000: NMT command, the highest priority COB-ID in CANopen
• 0x080: SYNC synchronization message, second only to NMT
• 0x180 + Node-ID: TPDO1, such as TPDO1 COB-ID 0x10 of Node-ID 0x190
• 0x200 + Node-ID: RPDO1, such as the master sends 0x000 to Node-ID 0x10 RPDO1, COB-ID is 0x210
•0x580 + Node-ID: SDO Rx (Server -> Client), such as the SDO response COB-ID of Node-ID 0x10 is 0x590
•0x600 + Node-ID: SDO Tx (Client -> Server), such as the master sends an SDO request to Node-ID 0x10, COB-ID is 0x610
•0x700 + Node-ID: Heartbeat message, such as the heartbeat COB-ID of Node-ID 0x10 is 0x710
3. NMT (Network Management)
NMT is the control center of the CANopen network, responsible for managing the life cycle and operating status of all devices in the network. NMT usually adopts the master-slave mode, and one NMT master station is responsible for managing multiple NMT slave stations.
3.1 NMT state machine
Each CANopen device follows the defined NMT state machine. The device has different behaviors and communication capabilities in different states. The NMT master station controls the state transition of the slave station by sending NMT commands.
Initialization
• Description: After the device is powered on or receives a reset command, it first enters this internal state to perform self-test, hardware initialization, firmware loading, etc.
• Behavior: After completing initialization, the device will send a Bootup message (COB-ID 0x700 + Node-ID, data [0x00]) to inform the network that it has started, and then automatically enter the Pre-operational state
Pre-operational
• Description: The default state entered after the device is started, with limited functions, mainly used for network configuration and diagnosis
• Behavior: The device can respond to NMT commands and SDO requests/responses, but PDO communication is prohibited, allowing the master to safely configure PDO mapping, communication parameters, etc.
Operational
• Description: The normal working state of the device, all functions are activated
• Behavior: The device supports all communication objects, can send and receive process data normally, and execute predetermined application tasks. The master usually sends a Start Node command to switch the device from Pre-operational to this state
Stopped (Stop)
•Description: Safe state, usually triggered by the master sending the Stop Node command
•Behavior: The device stops all application execution and all PDO communications, still responds to NMT commands and sends Heartbeat messages, but does not send or receive PDO data, often used for emergency stop, maintenance or safe disconnection of equipment
3.2 NMT Command Examples
NMT commands are issued by the NMT master station, COB-ID is fixed to 0x000, and the data includes the command code and target Node-ID.
Scenario
The master wants to make Node-ID 0x10 enter the Operational state
CAN frame
•COB-ID: 0x000 (fixed COB-ID for NMT command, highest priority)
•Data: [0x01, 0x10]
◦0x01 is the NMT command code, indicating "Start Node"
◦0x10 is the target Node-ID, indicating that the command is only for the device with Node-ID 0x10
Other common NMT command codes
•0x02: Stop Node
•0x80: Enter Pre-operational
•0x81: Reset Node (reset the node, including the application layer and the communication layer)
•0x82: Reset Communication (reset only the communication layer)
Broadcast Command
If the target Node-ID of the NMT command is 0x00, it means that the command is a broadcast command and all slaves in the network will execute the command (for example: [0x01, 0x00] will start all nodes).
4. Heartbeat
The heartbeat mechanism is a periodic message used in CANopen to monitor the online status of the device and the NMT status.
4.1 Producer Mechanism (Heartbeat Producer)
Each CANopen device (producer) will periodically broadcast its current NMT status:
•COB-ID: 0x700 + Node-ID
◦This is the COB-ID of the NMT error control message range, 0x700 is the function code, and Node-ID specifies the device that sends the heartbeat
◦Example: The heartbeat COB-ID of Node-ID 0x10 is 0x710
•Data content: Periodically send 1 byte of NMT status
◦This byte indicates the current NMT status code of the sending device, for example:
▪0x00: Bootup (start/reset), sent once after the device is powered on or reset
▪0x04: Stopped
▪0x05: Operational
▪0x7F: Pre-operational
•Periodic transmission: The producer will send the NMT status code according to the 0x1017:00 (Heartbeat Production Time) The heartbeat is sent at the configured time interval. If this value is 0, the device does not send heartbeats.
Example
When Node-ID 0x10 is in Operational state, it will periodically send frames as follows:
•COB-ID: 0x710
•Data: [0x05] (indicates Operational state)
4.2 Consumer Mechanism (Heartbeat Consumer) 
The NMT master or other nodes (consumers) that need to monitor the device status will listen to and process the heartbeat messages.
Monitor the online status of the device and maintain the timeout timer
• The consumer will maintain an independent timeout timer for each Node-ID to be monitored. The timeout time is usually configured in the object dictionary 0x100D:00 (Heartbeat Consumer Time) and associated with 0x100C:00 (Heartbeat Consumer Node ID)
• Reset the timer when receiving a heartbeat: Whenever the consumer receives a heartbeat frame from the monitored device, it immediately resets the timeout timer corresponding to the device, indicating that the device is still online and working normally
• Report a fault when the timer is over: If the timer of a device is not reset within the set timeout, the consumer determines that the device is offline, faulty, or communication is interrupted, triggering a fault report
When the Bootup status (0x00) is received, the device is prompted to reset
• Special meaning: When the consumer receives a heartbeat frame, its data byte is 0x00, and the COB-ID meets 0x700 + Node-ID, it indicates that the Node-ID The corresponding device has just performed a reset operation (power-on, software reset, or watchdog reset)
•Detailed prompts and processing:
◦Instant identification: The consumer immediately recognizes that this is a device reset event, not a simple state change or failure
◦Detailed log and user notification: "Device [Node-ID] reported the Bootup state! This means that the device has just completed the reset and the system will retry to establish full communication and configuration with the device"
◦Subsequent process: The NMT master station usually restarts the configuration process for the device based on this Bootup message
◦Reset count: Advanced systems may maintain a reset counter for each device and increment this count each time a Bootup message is received
5. SDO (Service Data Object)
SDO provides a reliable, service-oriented communication mechanism for accessing and modifying object dictionary entries in a CANopen network, following the client-server model, where the SDO client (usually an NMT master) requests services from the SDO server (CANopen slave).
5.1 Transmission Type
SDO transmission is divided into three main types according to the size of the data:
Expedited (fast transmission)
• Features: used to transmit simple read and write requests with a data volume of less than or equal to 4 bytes
• Mechanism: The entire read and write operation completes the request and response within a single CAN frame, without additional segmentation or confirmation, which is very efficient
• Application: read a single parameter, set a Boolean value or a small integer value
Segmented (segmented transmission)
• Features: used to transmit data with a volume greater than 4 bytes, but usually less than tens to hundreds of bytes
• Mechanism: The data is divided into multiple segments for transmission, and the receiver needs to send a confirmation frame (handshake mechanism) after each segment is transmitted to ensure reliable data transmission
• Application: read/write long strings, large arrays, and long parameters
Block (Block transfer)
• Features: used to transfer large batches of data (such as firmware updates, configuration tables)
• Mechanism: data is divided into blocks, each block contains multiple data segments, and the receiver sends a confirmation frame only after the sender has sent all the data in a block, reducing the number of handshakes and improving efficiency
• Support CRC check: Block transfer usually supports optional CRC check to ensure data integrity
• Application: firmware download, batch parameter upload/download
5.2 Communication Example (Expedited Read) 
Scenario
The master (Node-ID 0x0A, acting as SDO client) wants to read the value of 0x1000:00 (device type) in the object dictionary of the device with Node-ID 0x10 (acting as SDO server).
Request frame (Master → Slave)
•COB-ID: 0x60A (0x600 + Client Node-ID 0x0A)
◦0x600 is the base address of SDO Tx (client to server)
•Data: [0x40, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00]
◦0x40: SDO command byte, indicating an expedited read request
◦0x00, 0x10: Index 0x1000 (little endian)
◦0x00: Sub-index 0x00
◦0x00, 0x00, 0x00, 0x00: The response will contain the read value
Response frame (Slave → Master)
•COB-ID: 0x590 (0x580 + Server Node-ID 0x10)
◦0x580 is the base address of SDO Rx (sent from server to client)
•Data: [0x4B, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00]
◦0x4B: SDO command byte, indicating an expedited read response
◦0x00, 0x10: Index 0x1000 (index of echo request)
◦0x00: Sub-index 0x00 (sub-index of echo request)
◦0x00, 0x00, 0x00, 0x00: actual value of 0x1000:00 read
SDO Abort message
If the SDO request fails (e.g. index/sub-index does not exist, insufficient permissions), the server will send an SDO Abort message with a command byte of 0x80 and contains an Abort Code.
6. PDO (Process Data Object) 
PDO is designed for real-time, high-priority data transmission and is typically used for fast exchange of process variables such as sensor data, motor position, and controller output. It does not provide a confirmation mechanism in order to achieve maximum efficiency.
6.1 Mapping Mechanism
The flexibility of PDO is reflected in its mapping mechanism. Each PDO can map one or more entries in the object dictionary.
TPDO (Transmit PDO) Mapping (0x1A00-0x1A03)
•Function: Defines which variables (as well as the order and data type) in the device's internal object dictionary will be packaged into a TPDO frame and sent periodically
•Configuration: The NMT master configures the slave's TPDO mapping parameters through SDO, for example, setting 0x1A00:01 to 0x30010120 means that the first mapping entry of TPDO1 is a 32-bit variable with OD index 0x3001 and sub-index 0x01
RPDO (Receive PDO) Mapping (0x1600-0x1603)
•Function: Defines how the data in a RPDO frame is parsed and written to the corresponding variables in the device's object dictionary when the device receives it
•Configuration: The NMT master configures the slave's RPDO mapping parameters through SDO, for example, setting 0x1600:01 to 0x30000120 means that the data received by RPDO1 will be written to the 32-bit variable with OD index 0x3000 and subindex 0x01
PDO transmission trigger type
•Synchronous: Send/receive after receiving a SYNC message
•Asynchronous: Send when the mapped variable value changes, reaches a certain threshold, or the cycle time expires
•Cyclic: Send automatically at a preset time interval (independent of SYNC)
Remote Request (TPDO): Send when an empty frame corresponding to the PDO COB-ID is received
6.2 TPDO Example
Scenario
TPDO1 of Node-ID 0x10 (as TPDO producer) maps 0x3001:01 in its object dictionary (assuming it is a 32-bit input value, such as a sensor measurement value). When this value changes or a timer is triggered, the device needs to send this value.
CAN frame
•COB-ID: 0x190 (0x180 + 0x10)
◦0x180 is the base address of TPDO1
•Data: [0x78, 0x56, 0x34, 0x12]
◦Assume that the current value of 0x3001:01 is 0x12345678
◦CANopen usually uses little-endian to transmit multi-byte data, with the low-order byte 0x78 in front and the high-order byte 0x12 in the back
◦After the receiver parses this PDO frame, it will update the internal corresponding mapped 0x3001:01 variable to 0x12345678
6.3 RPDO Example
Scenario
The master (as RPDO producer) writes to RPDO1 of Node-ID 0x10 (as RPDO consumer) 0x3000:01 (assuming a 32-bit output value, such as a motor speed setpoint).
Slave RPDO mapping configuration
0x1600:01 in the object dictionary of Node-ID 0x10 has been configured to map to 0x3000:01.
CAN frame (sent by the master)
•COB-ID: 0x210 (0x200 + 0x10)
◦0x200 is the base address of RPDO1
•Data: [0xAA, 0xAA, 0x00, 0x00]
◦The master wants to set the value of 0x3000:01 to 0x0000AAAA
◦Because it is little endian, the data bytes are 0xAA, 0xAA, 0x00, 0x00
After Node-ID 0x10 receives this frame, the value of its internal object dictionary 0x3000:01 will be updated to 0x0000AAAA, and the device's application layer will control the output according to the new value
VII. CiA 401 Application Profile (Generic I/O Specification)
In addition to the core communication protocol, CANopen also defines a large number of application profiles to standardize the object dictionary entries and PDO mappings for specific types of devices, enhancing interoperability between similar products from different manufacturers. CiA 401 is one of the most common application profiles and defines the interface of generic I/O modules.
7.1 Standardized Object Dictionary
Core Purpose
CiA 401 provides a unified, plug-and-play communication interface for digital input/output (DIO) and analog input/output (AIO) devices, allowing users to access the I/O functions of the device in a standardized way without having to understand the internal details of the device.
Key index range
CiA 401 defines the following key index ranges in the object dictionary to represent different types of I/O:
•0x6000-0x60FF: Digital Input, used to read the state of a digital input pin or channel
•0x6200-0x62FF: Digital Output, used to control the state of a digital output pin or channel
•0x6400-0x64FF: Analog Input, used to read the measured value of an analog input channel (such as voltage, current)
•0x6700-0x67FF: Analog Output, used to set the value of an analog output channel
7.2 Application example: Digital input module
Assume that there is a digital input module (Node-ID 0x10) that complies with the CiA 401 specification.
OD entries
•0x6000:01: indicates the current state of the first digital input channel of the module (1 = ON, 0 = OFF)
•0x6000:02: indicates the state of the second digital input channel
•The values of these entries are updated as the actual physical input changes
PDO configuration
The NMT master (controller) configures the module's TPDO1 via SDO to map the above digital input entries:
•The master sets the module's 0x1A00:00 (the number of mapped entries for TPDO1) to 1, and sets 0x1A00:01 to 0x60000108 (indicates mapping 0x6000:01, 8-bit data)
•The master also configures the transmission type of TPDO1 (such as cyclic transmission or event-driven), ensuring that the module automatically sends TPDO frames containing the input states periodically or when the input states change
Advantages
Through PDO The master station can obtain the status of all digital inputs in real time and efficiently without frequently sending SDO requests to poll each input status, which reduces the bus load and improves the response speed.