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.