CANopen: The Ultimate Guide (2023)

What is CANopen?

CANopen is short for, "Controller Area Network, the Open Communication Solution Dissemination Project," and is a CAN based communication protocol and device configuration file specification for embedded networking systems used in automation.

CANopen was developed as a standardized higher-layer protocol for embedded control systems with very flexible configuration functions. CANopen is very practical, as it enables off-the-shelf interoperability between machines and provides standard methods for configuring devices, with plug-and-play capability.

Originally, it was designed for motion-oriented machine control networks. Today, however, it is used in other application fields, such as medical equipment, off-road vehicles, maritime electronics, railway applications, or building automation.

How Does CANopen Work?

Every CANopen device must implement certain standard functions in its control software.

CAN and CANopen in the OSI Model

As we mentioned previously, the CANopen protocol is a higher-layer protocol that is built on the CAN bus. The first two levels are covered by CAN: the physical layer and the data link layer. The physical layer interprets the lines used, voltages, high-speed characteristics, etc. The data link layer includes the fact that CAN is a frame-based protocol.

The five top layers are covered by CANopen: network layer (addressing, routing), transport layer (end-to-end reliability), session layer (synchronization), presentation layer (data encoded in a standard way, data representation), and application layer. The application layer specifies how CANopen devices are configured, transmitted, and synchronized.

CANopen Communication Principles

Several devices communicate within a CANopen network, e.g., industrial robot arms with multiple automation components that are integrated by a PC or PLC. CANopen provides three models, which facilitate communication between the nodes.

CANopen Protocols

CANopen communication protocols implement several CANopen COBs (CAN-ID and the control bits) that are communicated with one of the CANopen bit rates. The communication objects enable system designers to transmit control information and react to certain error conditions or influence and control network behavior.

The CANopen protocols include:

• PDO protocol: Process data objects (PDOs) are used in CANopen for broadcasting high-priority control and status information transmitting real-time vehicle data between devices. A PDO is made up of a single CAN frame that transmits up to 8 bytes of pure application data.




• SDO protocol: Service data objects (SDOs) enables access/changes to all entries of a CANopen object dictionary. One SDO consists of two CAN data frames with different CAN IDs.

• NMT protocol: The network management (NMT) is used for controlling the state of CANopen devices to transit to the commanded NMT state, e.g., initialization state, pre-operational state, operational state, stopped state, and start, stop, reset. The NMT carries a single CAN frame with a data length of 2 bytes.

• Error control protocols: Error control protocols enable the monitoring of a CANopen network, e.g., heartbeat protocol. The heartbeat protocol is used to provide an ‘alive’ message, that all network participants are still “alive” in a CANopen network and that they are still in their NMT FSA state.

  Special function protocols: Three basic protocols are available in CANopen for generating unique network behavior.

• Synchronization (SYNC) protocol: This is a network protocol that allows for synchronous network activity. For the modification of a particular network time, the Time-stamp protocol (TIME) is used. Other network members may be notified of device-internal failures using the Emergency protocol (EMCY).

The PDO and SDO protocols are critical since they are the foundation for most CANopen communication.

The CANopen Frame

It is important to break down the CANopen CAN frame to comprehend CANopen communication:

The message format of the CANopen frame is based on the CAN frame format. In the CAN protocol, data is 11-bit or 29-bit CAN-ID, control bits (such as remote transmission bit (RTR), start bit, and 4-bit data length field), and 0 to 8 bytes of data.

It is usually called COB-ID in CANopen, which is composed of CAN-ID and control bits. In CANopen, the 11-bit CAN ID is divided into two parts: 4-bit function code and 7-bit CANopen node ID. The 7-bit size limit limits the number of devices on the CANopen network to 127 nodes.

All COB-IDs must be unique to prevent conflicts on the bus. In SDO communication, there should always be only one node that needs to access each object dictionary index of the slave node.

Object Dictionary

As mentioned above, an object dictionary (OD) is needed for all CANopen nodes and is one of the central themes.

Essentially, CANopen is a table that processes data and stores configuration. In other words, it is a standardized structure that contains all parameters that describe a CANopen node’s actions.

The object dictionary is the means of communicating with a CANopen computer. E.g., in the manufacturer-specific section of the object dictionary, one might write true to the index, which the system would interpret as an activated signal for acquiring data from a voltage input.

The master, on the other hand, may want to read information from the object dictionary to obtain the acquired data or to learn how the system is currently configured. Service data objects (SDOs) and Process data objects (PDOs) are the two communication frameworks for accessing the object dictionary.