The CANopen protocol stack serves as a high-level communication specification built on the CAN bus, utilizing a standardized Object Dictionary (OD) for device parameter management and COB-IDs composed of function codes and node IDs to identify communication objects, facilitating highly interoperable network management, real-time data exchange, and synchronized monitoring in industrial embedded systems.
CANopen is a high-level communication protocol built on a Controller Area Network (CAN bus), including communication sub-protocols and device sub-protocols. It is commonly used in embedded systems and is also a frequently used industrial fieldbus in industrial control. We previously introduced a detailed explanation of the CANopen protocol; this article mainly provides an overview of the CANopen protocol stack.
I. Overview of the CANopen Protocol
The CANopen protocol 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. The core goal of the CANopen protocol is to define a network layer and application layer specification for embedded systems, ensuring seamless interconnection and interoperability of devices from different manufacturers on the same CAN bus.
1. Core Advantages of the CANopen Protocol
The most significant advantage of CANopen lies in its device interoperability. As long as devices from different manufacturers conform to the CANopen standard, they can work together on the same network without extensive customization, greatly simplifying system integration and reducing development costs and time.
2. CANopen Protocol Application Areas
Due to its high reliability, real-time performance, flexibility, and standardization, the CANopen protocol is widely used in the following fields:
• 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 equipment;
• Building Automation: HVAC systems, lighting control;
• Rail Transportation: Train control systems;
• Marine Electronic Equipment: Navigation and control systems;
II. CANopen Core Concepts
1. Object Dictionary (OD)
The object dictionary is the core of a CANopen device, and can be likened to the device's "brain" or "configuration file." It is a standardized and structured parameter storage area containing all configurable parameters, status information, diagnostic data, and communication settings of the device.
1.1 Core Functions
• Parameter Configuration: Allows external devices (such as NMT master stations) to modify the device's operating parameters over 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;
1.2 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 a primary address, used to identify a major function or parameter group;
• Sub-index: Similar to a secondary address, used to identify a specific sub-parameter or array element within the primary parameter group;
• Example: 0x1000:00 represents the device type, 0x1017:00 represents the heartbeat cycle;
1.3 Content Classification
• Standard Definition Entries: The protocol reserves specific index ranges for general functions, such as 0x1000 to 0x1FFF, which are typically used for communication parameters and general device information;
• Application configuration file defines entries: Standardized object dictionary entries are defined for specific device types (e.g., CiA 401 general I/O, CiA 402 motion control);
• Vendor-defined extended entries: Vendors can add unique functions and parameters within the custom range reserved by the protocol (usually 0x2000 to 0x5FFF);
1.4 Access Methods
Entries in the object dictionary are typically read and written via the SDO (Service Data Object) protocol. SDO provides a reliable, request-response communication mechanism, ideal for non-real-time parameter configuration and diagnostics.
2. Communication Objects
The CANopen protocol defines several different types of communication objects (COBs). Each object has its specific functions 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 status (start, stop, reset, etc.) of all devices in the network. It adopts a master-slave mode, typically with one NMT master station managing all slave stations. NMT messages have the highest priority. • Heartbeat: The heartbeat mechanism periodically reports the current NMT status of a 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 employ 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 (typically 1-8 bytes) process data. They use a broadcast/multicast communication mode, without handshake confirmation, enabling fast and efficient data exchange.
SYNC
(Synchronous Object): A synchronization object is a periodic broadcast message used to coordinate the periodic actions of multiple devices in the network, ensuring that multiple devices execute tasks synchronously.
EMCY
(Emergency Object): Emergency event objects are used to report internal faults or errors occurring within a device. They are sent immediately when the device detects an internal error, have high priority, and allow relevant nodes to respond and handle the anomaly promptly.
3. Node ID
The 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 by the NMT master to send broadcast commands.
• Configuration Methods:
◦ Hardware Configuration: Directly set on the device via DIP switches, jumper caps, etc.
◦ Software Configuration: Configured via SDO during device startup;
◦ LSS (Layer Setting Services): A low-level service defined by the CANopen standard, allowing the master to dynamically assign and configure Node IDs.
4. COB-ID (Communication Object Identifier)
The COB-ID is an 11-bit CAN frame ID used in the CANopen protocol to identify the CAN frame type and priority, following the CAN standard's priority rules: the smaller the value, the higher the priority.
4.1 Composition Description
COB-ID typically consists of two parts:
• Function Code: Identifies the type of CANopen message (e.g., NMT, SDO, PDO, Heartbeat, etc.);
• Node-ID: Identifies the source or destination device of the message.
4.2 Determining Message Type and Priority
• Message Type: The function code determines the type of communication object the CANopen message represents;
• Priority: A lower COB-ID value indicates a higher CAN bus priority, which is crucial for real-time communication.
4.3 Application Examples
• 0x000: NMT command, the highest priority COB-ID in CANopen;
• 0x080: SYNC synchronization message, second only to NMT in priority;
• 0x180 + Node-ID: TPDO1, e.g., the COB-ID of TPDO1 for Node-ID 0x10 is 0x190;
• 0x200 + Node-ID: RPDO1, e.g., when the master station sends RPDO1 to Node-ID 0x10, the COB-ID is 0x210;
• 0x580 + Node-ID: SDO Rx (Server -> Client), e.g., the COB-ID of the SDO response for Node-ID 0x10 is 0x590;
• 0x600 + Node-ID: SDO Tx (Client -> Server), e.g., when the master station sends an SDO to Node-ID 0x10... Request, COB-ID is 0x610;
0x700 + Node-ID: Heartbeat message, such as a heartbeat message with Node-ID 0x10 and COB-ID 0x710.
As you can see, CANopen is not just a data transmission protocol; the CANopen bus also provides a complete mechanism for managing and monitoring the entire network. With continuous technological advancements, CANopen is constantly evolving to adapt to new application scenarios and requirements. Whether in traditional industrial automation or in the growing applications of smart devices and the Internet of Things, the CANopen protocol stack will continue to play a vital role.
FAQ
Q1: What is the role of the "Object Dictionary (OD)" in CANopen?
A1: The Object Dictionary is the core configuration interface of a CANopen device. It stores all configurable parameters, status data, and communication settings in a standardized structure (using 16-bit indices and 8-bit sub-indices). This ensures that devices from different manufacturers provide a unified data interface, allowing for seamless interoperability.
Q2: How do you determine the priority of a CANopen message via its COB-ID?
A2: CANopen adheres to CAN bus arbitration rules where a lower COB-ID numerical value indicates a higher priority. For example, NMT (Network Management) commands carry a COB-ID of 0x000, the highest possible priority, while SYNC (Synchronization) objects are set at 0x080 to ensure precise timing for control tasks across the network.
Q3: What are the primary differences between PDO and SDO communication objects?
A3: PDOs (Process Data Objects) are optimized for real-time transmission of process data (such as sensor values) using a broadcast model without confirmation for maximum speed. In contrast, SDOs (Service Data Objects) are used for non-real-time configuration or diagnostics, employing a request-response handshake to ensure data integrity and reliability.
