Currently, the CANopen communication protocol has been widely used in the industrial field. Due to its object-oriented design philosophy, the CANopen protocol has become one of the standard communication interfaces for automation companies in countries like Europe. In this series of articles, we will introduce the basic content of the CANopen protocol, including object dictionary, services, SDO, PDO, and master/slave nodes.If you need CANopen software and hardware solutions or training services, please email [email protected] to contact the Hongke Industrial Control team!
1
What is CANopen?
CANopen is a communication protocol based on CAN. This protocol is very useful because it allows for ready interoperability between devices and nodes (such as industrial machinery), as well as providing a standard method for configuring devices before and after installation. CANopen was originally designed for motion control systems, and today it is widely used in the field of motor control (stepper/servo motors) and has found extensive application in:
Robotics: including automated robots, conveyor belts, and other industrial machinery.
Medical: including X-ray generators, injectors, patient beds, and dialysis equipment.
Automotive: including agriculture, railways, trailers, heavy vehicles, and ships.
CANopen is a “higher-layer protocol” based on the CAN bus, which means that the CAN bus (ISO 11898) acts as a “transport vehicle” for CANopen information, similar to a truck carrying containers. In the OSI model, the CAN bus represents the two lowest layers (physical layer and data link layer). This means that CAN only implements the transmission of frames that contain fields with an 11-bit CAN ID, a remote transmission (RTR) bit, and 64 data bits (related to higher-layer protocols). In other words, the role of the CAN bus in CANopen is the same as in the J1939 protocol, while CANopen implements the seventh layer of the OSI model and can adapt to other data link layer protocols besides CAN (such as EtherCAT, Modbus, and Powerlink).
It is worth noting that with the introduction of CAN FD, CANopen FD as the next generation CANopen standard may play an increasingly important role. For specific details, please visit the CiA official website.
Compared to the CAN bus and J1939 protocol, the CANopen protocol introduces the following six core concepts:
Communication Modes
There are three modes of communication for devices/nodes: master/slave, client/server, and producer/consumer.
Communication Protocols
Protocols used for communication, such as configuring nodes (SDO) or transmitting real-time data (PDO), etc.
Device Status
Each device supports different statuses. A “master” node can change a “slave” node, including operations like reset.
Object Dictionary
Each device has an OD, which contains entries specifying device configurations, etc., accessible via SDO.
Electronic Data Sheet
EDS is the standard file format for OD entries, allowing service tools to update devices.
Device Configuration Files
Describes vendor independence for I/O modules (CiA 401) and motion control (CiA 402).
2
Basic Knowledge of CANopen Communication
In a CANopen network, multiple devices need to communicate. For example, in an industrial automation setup, you might have a robotic arm with multiple servo motor nodes and a control interface/PC node. To facilitate communication, there are three modes in CANopen, each closely related to the CANopen protocol we are discussing. Below is a brief introduction to these three modes:
The Three Modes of CANopen Communication
01 Master/Slave
A node (e.g., control interface) acts as the application master or main controller. It requests data from slave devices (e.g., servo motors). This process is used for diagnostics or status management. In standard applications, there can be 0 to 127 slaves. Note: Different master controllers can share the same data link layer in a single CANopen network.
Service Example: NMT
02 Client/Server
The client sends a data request to the server, and the server replies with the requested data. For example, this mode is used when the application master needs to retrieve data from the slave’s OD. Reading from the server is an “upload,” while “writing” is a “download” (the terms are from the server’s perspective).
Service Example: SDO
03 Consumer/Producer
In this mode, the producer node broadcasts data to the network, which is consumed by the consumer nodes. The producer sends this data based on requests (pull model) or without specific requests (push model).
Service Example: Heartbeat
Clearly, these models are essentially the same, but they have been distinguished for consistency in terminology.
In the next article, we will continue to explain the basic knowledge of CANopen communication. Please follow this public account to get updated content first. Hongke has been deeply engaged in the fields of CAN, CANopen, etc., for many years, with strong technical capabilities. We have launched CANopen development source code, CANopen data loggers, and products supporting the CANopen protocol, such as gateways, boards, and I/O devices for the domestic market. Additionally, in response to customer training needs in CANopen, Hongke has also launched related course training services. Please call 400-999-3848 to learn more.
▎Previous Reviews