I. Overview of the 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 objective is to define network - layer and application - layer specifications for embedded systems, ensuring seamless interconnection and interoperability of devices produced by different manufacturers on the same CAN bus.
Core Advantages
The most prominent advantage of CANopen lies in the interoperability of devices. As long as devices from different manufacturers comply with the CANopen standard, they can work together in the same network without extensive custom development, greatly simplifying system integration and reducing development costs and time.
Application Areas
Due to its high reliability, real - time performance, flexibility, and standardization features, the CANopen protocol is widely used in the following areas:
Motion control: Precise control of motors, drives, etc.
Industrial automation: PLCs, sensors, actuators, HMIs, etc.
Robotics: Multi - axis robot control
Medical equipment: Diagnostic and treatment devices
Building automation: HVAC systems, lighting control
Rail transit: Train control systems
Marine electronic equipment: Navigation and control systems
II. Core Concepts of CANopen
2.1 Object Dictionary (OD)
The object dictionary is the core of a CANopen device, which can be likened to the device's "brain" or "configuration file". 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 Functions
Parameter configuration: Allows external devices (such as the NMT master station) to modify the operating parameters of the device via the network.
Status reading: Provides a unified access interface for the device's current status and measured values.
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 (Index) and an optional 8 - bit sub - index (Sub - index):
Index: Similar to a main address, used to identify a major function or parameter group.
Sub - index: Similar to a secondary address, used to identify specific sub - parameters or array elements within the main parameter group.
Example: 0x1000:00 represents the device type, and 0x1017:00 represents the heartbeat period.
Content Classification
Standard - defined entries: The protocol reserves specific index ranges for general functions. For example, 0x1000 to 0x1FFF is typically used for communication parameters and general device information.
Application profile - defined entries: For specific device types (such as CiA 401 general I/O and CiA 402 motion control), standardized object dictionary entries are defined.
Manufacturer - customized extended 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, which is very suitable for non - real - time parameter configuration and diagnosis.
2.2 Communication Objects
The CANopen protocol defines several different types of communication objects (COBs). Each object has its specific function and communication model, 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 states (start, stop, reset, etc.) of all devices in the network. It adopts the master - slave mode, and usually, one NMT master station manages all slave stations. 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 device's online status and health.
SDO (Service Data Object): Service data objects are used to transmit non - real - time but reliable configuration, diagnostic, and parameter data. They adopt the 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 adopt the broadcast/multicast communication model without handshake confirmation, achieving fast and efficient data exchange.
SYNC (Synchronous Object): The synchronous object is a periodic broadcast message used to coordinate the periodic actions of multiple devices in the network, ensuring that multiple devices perform tasks synchronously.
EMCY (Emergency Object): Emergency event objects are used to report faults or errors that occur inside the device. When the device detects an internal error, it sends the message immediately. It has a high priority, allowing relevant nodes to respond and handle exceptions in a timely manner.
2.3 Node - ID
Node - ID is the unique identifier of each device in a CANopen network:
Uniqueness: In a CANopen network, each device (slave station) 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 by the NMT master station to send broadcast commands.
Configuration Methods
Hardware configuration: Set directly on the device via DIP switches, jumper caps, etc.
Software configuration: Configured via SDO when the device starts up.
LSS (Layer Setting Services): A low - layer service defined by the CANopen standard that allows the master station to dynamically assign and configure Node - IDs.
2.4 COB - ID (Communication Object Identifier)
The COB - ID is an 11 - bit CAN frame ID used in the CANopen protocol to identify the type and priority of a CAN frame, following the priority rules of the CAN standard: the smaller the value, the higher the priority.
Composition
The 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 or target device of the message.
Determining Message Type and Priority
Message type: The function code determines what type of communication object the CANopen message is.
Priority: A lower COB - ID value means a higher CAN bus priority, which is crucial for real - time communication.
Examples
0x000: NMT command, the COB - ID with the highest priority in CANopen.
0x080: SYNC synchronous message, with a priority second only to NMT.
0x180 + Node - ID: TPDO1. For example, the TPDO1 COB - ID of Node - ID 0x10 is 0x190.
0x200 + Node - ID: RPDO1. For example, when the master station sends RPDO1 to Node - ID 0x10, the COB - ID is 0x210.
0x580 + Node - ID: SDO Rx (Server -> Client). For example, the SDO response COB - ID of Node - ID 0x10 is 0x590.
0x600 + Node - ID: SDO Tx (Client -> Server). For example, when the master station sends an SDO request to Node - ID 0x10, the COB - ID is 0x610.
0x700 + Node - ID: Heartbeat message. For example, the heartbeat COB - ID of Node - ID 0x10 is 0x710.
III. NMT (Network Management)
NMT is the control center of the CANopen network, responsible for managing the lifecycle and operating states of all devices in the network. NMT usually adopts the master - slave mode, with one NMT master station managing multiple NMT slave stations.
3.1 NMT State Machine
Each CANopen device follows a predefined NMT state machine. The device has different behaviors and communication capabilities in different states, and the NMT master station controls the state transitions of the slave stations 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 - checks, hardware initialization, firmware loading, etc.
Behavior: After completing the initialization, the device sends a Bootup message (COB - ID 0x700 + Node - ID, data [0x00]) to inform the network that it has started, and then automatically enters the Pre - operational state.
Pre - operational
Description: The default state after the device starts up, with limited functionality, 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 station to safely configure PDO mappings, communication parameters, etc.
Operational
Description: The normal working state of the device, where all functions are activated.
Behavior: The device supports all communication objects, can send and receive process data normally, and execute predefined application tasks. The master station usually sends a Start Node command to switch the device from the Pre - operational state to this state.
Stopped
Description: A safe state, usually triggered by the master station sending a Stop Node command.
Behavior: The device stops all application execution and all PDO communication. It still responds to NMT commands and sends Heartbeat messages, but does not send or receive PDO data. It is often used for emergency stops, maintenance, or safe disconnection of the device.
3.2 NMT Command Examples
NMT commands are issued by the NMT master station. The COB - ID is fixed at 0x000, and the data includes the command code and the target Node - ID.
Scenario
The master station wants to make Node - ID 0x10 enter the Operational state.
CAN Frame
COB - ID: 0x000 (The fixed COB - ID for NMT commands, with the highest priority)
Data: [0x01, 0x10]
0x01 is the NMT command code, indicating "Start Node" (start the node).
0x10 is the target Node - ID, indicating that this command is only for the device with Node - ID 0x10.
Other Common NMT Command Codes
0x02: Stop Node (stop the node)
0x80: Enter Pre - operational (enter the pre - operational state)
0x81: Reset Node (reset the node, including the application layer and the communication layer)
0x82: Reset Communication (only reset the communication layer)
Broadcast Commands
If the target Node - ID of an NMT command is 0x00, it means that the command is a broadcast command, and all slave stations in the network will execute this command (for example, [0x01, 0x00] will start all nodes).
IV. Heartbeat
The heartbeat mechanism is a periodic message in CANopen used to monitor the online status and NMT status of devices.
4.1 Producer Mechanism (Heartbeat Producer)
Each CANopen device (producer) periodically broadcasts its current NMT status:
COB - ID: 0x700 + Node - ID
This is the COB - ID in the NMT error control message range. 0x700 is the function code, and the Node - ID specifies the device sending the heartbeat.
Example: The heartbeat COB - ID of Node - ID 0x10 is 0x710.
Data Content: Periodically sends a 1 - byte NMT status.
0x00: Bootup (start/reset), sent once after the device is powered on or reset.
0x04: Stopped
0x05: Operational
0x7F: Pre - operational
This byte represents the current NMT status code of the sending device. For example:
Periodic Sending: The producer sends heartbeats at the time interval configured in the object dictionary entry 0x1017:00 (Heartbeat Production Time). If this value is 0, the device does not send heartbeats.
Example
When Node - ID 0x10 is in the Operational state, it periodically sends a frame:
COB - ID: 0x710
Data: [0x05] (indicating the Operational state)
4.2 Consumer Mechanism (Heartbeat Consumer)
The NMT master station or other nodes that need to monitor the device status (consumers) listen for and process heartbeat messages.
Monitoring Device Online Status and Maintaining Timeout Timers
The consumer maintains an independent timeout timer for each Node - ID that needs to be monitored. The timeout time is usually configured in the object dictionary entry 0x100D:00 (Heartbeat Consumer Time) and is associated with 0x100C:00 (Heartbeat Consumer Node ID).
Reset the timer when receiving a heartbeat: Whenever the consumer receives a heartbeat frame from a monitored device, it immediately resets the timeout timer corresponding to that device, indicating that the device is still online and working normally.
Report a fault if it times out: If the timer of a certain device fails to be reset within the set timeout time, the consumer determines that the device is offline, faulty, or has a communication interruption and triggers a fault report.
When Receiving the Bootup Status (0x00), Prompt the Device Reset
Special meaning: When the consumer receives a heartbeat frame with a data byte of 0x00 and a COB - ID that matches 0x700 + Node - ID, it indicates that the device corresponding to that Node - ID has just performed a reset operation (power - on, software reset, or watchdog reset).
Detailed prompts and processing:
Immediate identification: The consumer immediately identifies this as a device reset event, rather than a simple status change or fault.
Detailed log and user notification: "Device [Node - ID] reported the Bootup (start) status! This means that the device has just completed a reset, and the system will attempt to re - 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 counting: Advanced systems may maintain a reset counter for each device and increment this counter each time a Bootup message is received.
V. 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. The SDO client (usually the NMT master station) requests services from the SDO server (CANopen slave station).
5.1 Transmission Types
SDO transmissions are divided into three main types according to the data volume:
Expedited (Fast Transmission)
Features: Used for simple read/write requests with a data volume of less than or equal to 4 bytes.
Mechanism: The entire read/write operation is completed in a single CAN frame for the request and response, without additional segmentation or confirmation, which is very efficient.
Application: Reading a single parameter, setting a boolean value or a small integer value.
Segmented (Segmented Transmission)
Features: Used for 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. After each segment is transmitted, the receiving party needs to send an acknowledgment frame (handshake mechanism) to ensure reliable data transmission.
Application: Reading/writing long strings, large arrays, longer parameters.
Block (Block Transmission)
Features: Used for transmitting large - volume data (such as firmware updates, configuration tables).
Mechanism: The data is divided into blocks, and each block contains multiple data segments. After the sender sends all the data of a block, the receiving party sends an acknowledgment frame, reducing the number of handshakes and improving efficiency.
Supports CRC check: Block transmission usually supports an optional CRC check to ensure data integrity.
Application: Firmware download, batch parameter upload/download.
5.2 Communication Example (Expedited Read)
Scenario
The master station (Node - ID 0x0A, acting as an SDO client) wants to read the value of entry 0x1000:00 (device type) in the object dictionary of the device with Node - ID 0x10 (acting as an SDO server).
Request Frame (Master Station → Slave Station)
COB - ID: 0x60A (0x600 + client Node - ID 0x0A)
0x600 is the base address for SDO Tx (client sending 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 read value will be contained in the response.
Response Frame (Slave Station → Master Station)
COB - ID: 0x590 (0x580 + server Node - ID 0x10)
0x580 is the base address for SDO Rx (server sending to client).
Data: [0x4B, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00]
0x4B: SDO command byte, indicating an expedited read response.
0x00, 0x10: Index 0x1000 (echoing the requested index).
0x00: Sub - index 0x00 (echoing the requested sub - index).
0x00, 0x00, 0x00, 0x00: The actual value read from 0x1000:00.
SDO Abort Message
If an SDO request fails (e.g., the index/sub - index does not exist, or there is insufficient permission), the server will send an SDO Abort message with a command byte of 0x80 and an Abort Code.
VI. PDO (Process Data Object)
PDOs are designed for real - time, high - priority data transmission. They are typically used for the rapid exchange of process variables such as sensor data, motor positions, and controller outputs. PDOs do not provide a confirmation mechanism to achieve maximum efficiency.
6.1 Mapping Mechanism
The flexibility of PDOs lies in their mapping mechanism. Each PDO can map one or more entries in the object dictionary.
TPDO (Transmit PDO) Mapping (0x1A00 - 0x1A03)
Function: It defines which variables (as well as their order and data types) in the device's internal object dictionary will be packed into a certain TPDO frame and sent periodically.
Configuration: The NMT master configures the TPDO mapping parameters of the slave station through SDO. For example, setting 0x1A00:01 to 0x30010120 means that the first mapped entry of TPDO1 is a 32 - bit variable at OD index 0x3001 and sub - index 0x01.
RPDO (Receive PDO) Mapping (0x1600 - 0x1603)
Function: It defines how the data in a received RPDO frame is parsed and written to the corresponding variables in the device's object dictionary.
Configuration: The NMT master configures the RPDO mapping parameters of the slave station through SDO. For example, setting 0x1600:01 to 0x30000120 means that the data received by RPDO1 will be written to a 32 - bit variable at OD index 0x3000 and sub - index 0x01.
PDO Transmission Trigger Types
Synchronous: Send/receive after receiving a SYNC message.
Asynchronous (Event - driven): Send when the value of the mapped variable changes, reaches a specific threshold, or when the cycle time is up.
Cyclic: Automatically send at preset time intervals (independent of SYNC).
Remote Request (TPDO): Send when receiving an empty frame with the corresponding PDO COB - ID.
6.2 TPDO Example
Scenario
The TPDO1 of the device with Node - ID 0x10 (acting as a TPDO producer) maps entry 0x3001:01 in its object dictionary (assumed to be a 32 - bit input value, such as a sensor measurement). The device needs to send this value when the value changes or the timer triggers.
CAN Frame
COB - ID: 0x190 (0x180 + 0x10)
0x180 is the base address for TPDO1.
Data: [0x78, 0x56, 0x34, 0x12]
Assume the current value of 0x3001:01 is 0x12345678.
CANopen usually uses little - endian for multi - byte data transmission, with the least significant byte 0x78 first and the most significant byte 0x12 last.
After the receiving end parses this PDO frame, it will update the corresponding mapped variable 0x3001:01 to 0x12345678.
6.3 RPDO Example
Scenario
The master station (acting as an RPDO producer) writes to RPDO1 of the device with Node - ID 0x10 (acting as an RPDO consumer) at entry 0x3000:01 (assumed to be a 32 - bit output value, such as a motor speed setting).
Slave Station RPDO Mapping Configuration
Entry 0x1600:01 in the object dictionary of the device with Node - ID 0x10 has been configured to map to 0x3000:01.
CAN Frame (Sent by the Master Station)
COB - ID: 0x210 (0x200 + 0x10)
0x200 is the base address for RPDO1.
Data: [0xAA, 0xAA, 0x00, 0x00]
The master station wants to set the value of 0x3000:01 to 0x0000AAAA.
Due to little - endian, the data bytes are 0xAA, 0xAA, 0x00, 0x00.
After receiving this frame, the device with Node - ID 0x10 will update the value of entry 0x3000:01 in its internal object dictionary to 0x0000AAAA, and the device's application layer will control the output according to the new value.
VII. CiA 401 Application Profile (General I/O Specification)
In addition to the core communication protocol, CANopen defines a large number of application profiles. These profiles standardize the object dictionary entries and PDO mappings for specific types of devices, enhancing the interoperability between similar products from different manufacturers. CiA 401 is one of the most common application profiles, which defines the interface for general 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. Users can access the I/O functions of the devices in a standardized way without knowing the internal details of the devices.
Key Index Ranges
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 status of digital input pins or channels.
0x6200 - 0x62FF: Digital Output, used to control the status of digital output pins or channels.
0x6400 - 0x64FF: Analog Input, used to read the measurement values (such as voltage, current) of analog input channels.
0x6700 - 0x67FF: Analog Output, used to set the values of analog output channels.
7.2 Application Example: Digital Input Module
Assume there is a digital input module (Node - ID 0x10) compliant with the CiA 401 specification.
OD Entries
0x6000:01: Represents the current status of the first digital input channel of the module (1 = ON, 0 = OFF).
0x6000:02: Represents the status of the second digital input channel.
The values of these entries will change with the actual physical input.
PDO Configuration
The NMT master (controller) will configure TPDO1 of this module through SDO to map the above digital input entries:
The master sets entry 0x1A00:00 (the number of mapped entries for TPDO1) of the module to 1, and sets 0x1A00:01 to 0x60000108 (indicating mapping to 0x6000:01, 8 - bit data).
The master also configures the transmission type of TPDO1 (such as cyclic transmission or event - driven) to ensure that the module automatically sends TPDO frames containing these input statuses periodically or when the input status changes.
Advantages
Through PDO transmission, the master can obtain the status of all digital inputs in real - time and efficiently, without frequently sending SDO requests to poll each input status, reducing the bus load and improving the response speed.
7.3 Application Example: Digital Output Control
Assume there is a digital output module (Node - ID 0x20) compliant with the CiA 401 specification.
Slave Station RPDO Configuration
The NMT master will configure RPDO1 of this module through SDO to map to its digital output control entries:
COB - ID: The default COB - ID for RPDO1 of the module is 0x200 + Node - ID, i.e., 0x220.
Mapping Parameters: The master sets entry 0x1600:00 (the number of mapped entries for RPDO1) of the module to 1, and sets 0x1600:01 to 0x62000108 (indicating that the received data will be written to 0x6200:01, 8 - bit data).
Master Station Sending Frame
When the master wants to control the digital output, it constructs an RPDO frame and sends it to the module:
COB - ID: 0x220 (RPDO1 of the target device with Node - ID 0x20).
Data: [0x01, 0x00]
0x01: Set the value of the first byte to 0x01. If 0x6200:01 maps to bit 0 of this byte, the first output will be set to ON.
0x00: Set the value of the second byte to 0x00. If 0x6200:02 maps to bit 0 of this byte, the second output will be set to OFF.
Slave Station Behavior
After receiving this RPDO frame, the module will automatically parse the data and update the values of entries 0x6200:01 and 0x6200:02 in its object dictionary, thereby changing the status of its physical digital output pins.