Industrial automation systems require a standardized communication protocol to ensure the interoperability and interchangeability of network devices. CANopen is a CAN-based application layer protocol especially dedicated for industrial applications. The CiA (CAN in Automation) group has standardized the CANopen protocol, which describes basic principles, data types, encoding rules, and services. In this article, we cover the CANopen system architecture, frame format, and communication model.
CANopen is a master-slave communication network protocol. It follows the Physical, Datalink, and Application layer of OSI (Open Systems Interconnection ) reference model. the CANopen application layer defines the device profile and Communication profile of the network. CAN hardware completely handles the CANopen Physical and Data link layer. Each device in the network consists of three essential features:
- Application software
- CANopen object dictionary
- CANopen protocol stack
1. Application software: The application software is designed to fullfill the CANopen standard. It comprises the functionality of the device and provides the CAN hardware support functions with the help of CANopen library.
2. CANopen object dictionary: The CANopen object dictionary is a non-volatile central data storage, mainly used to store network configuration and process information. The Object Dictionary provides standardized communication objects for real-time data exchange between network devices. The CANopen protocol defines the 16-bit index and 8-bit sub-index to access the entries (using physical address) in the object directory. CANopen supports all data types (integer, array, floating point, and character). CANopen devices should maintain the four types of objects:
- Network Management Objects (NMT)
- Emergency Objects (EMCY)
- Service Data Object (SDO)
- Process Data Object (PDO)
Network Management Objects (NMT): The Network initializing and monitoring uses network management objects. These objects can change the communication status of a node during the operational state. Using network management objects, the master controls the communication state of individual nodes to start, stop, or reset the devices.
Emergency (EMCY) Objects: EMCY Objects have information about the standard error codes and synchronization message objects.
Service Data Objects (SDO): The Service Data Object support the configuration and diagnostic access between CANopen devices for peer to peer communication.
Process Data Objects (PDO): The Process Data Object represents the device inputs or outputs that can be changing in real time. The slave devices store the inputs (e.g., sensors) and outputs (e.g., motor drives) of the node in the object dictionary.
CANopen protocol stack: The CANopen protocol stack handles the communication services using the protocol software library that provides the services to transmit and receive objects over the CAN bus. The CANopen master protocol stack offers the functionality of the CANopen standards CiA 301, CiA 302, and CiA 305. The CANopen slave protocol stack facilitates the functioning of I/Os such as intelligent sensors and actuators.
All CANopen device manufacturers follow the same standard which helps to interface devices from different manufacturers into one network. Figure 1 shows the block diagram of a CANopen network architecture.
Figure 1: CANopen network architecture
Physical layer (CAN bus): The CANopen physical layer consists of a CAN-H and CAN-L channels to transmit the differential signals. The industrial standard CANopen physical layer includes the power bus that provides the required power to all devices in that network. The CAN bus physically connects the master and slave devices and supports all network topologies. The CANopen devices support 9-pin D-sub connector, 5-pin mini style connector, and the multi-pole connector.
Master node: CANopen master node is the commander of the CANopen network, and is responsible for data communication, synchronization, and network management. A single CANopen master can communicate with up to 127 slave devices in a network. A CANopen master can be implemented on a single board computer (SBC) or Personal Computer (PC), with a master interface card for hardware connectivity with the network. An Application Program Interface (API) is used to communicate with the CAN open hardware and its peripherals. An Electronic Data Sheets (EDS) file is used to specify the supported Object Dictionary (OD) entries and node identification numbers (ID). A CANopen master library helps to build a CANopen master system quickly and easily.
Slave node: The CANopen slave device performs tasks, specified by the master. Usually, the slave node drives the control devices such as barcode readers, RFID readers, actuators, sensors, and human-machine interfaces. Each device has a unique device identification number that helps to address the individual slave-node in the network. The acceptance filter has to be implemented in a slave node to filter the messages. These devices respond to the request message, addressed to its ID or broadcast messages.
CANopen FRAME FORMAT
CANopen frames are structured using "dominant" bits (logic 0) and "recessive" bits (logic 1). It is similar to the CAN frame format. Figure 2 illustrates the CANopen message frame format.
Figure 2: CANopen frame format
Start of Frame (SoF): The message frame starts with one dominant bit which is used to synchronize the network devices.
Communication Object Identifier (COB-ID): COB-ID is a header of the CANopen message. It includes function code and a CAN Identifier. The function code represents the type of communication (NMT, SYNC, EMCY, PDO, and SDO) and kind of action needed to be performed using the data fields. The CAN Identifier (CAN-ID) is used to address the nodes in the network.
Remote Transfer Request (RTR): This bit is used to represent the data frame or arbitration frame. The Master controller uses the arbitration frame to take control over the CAN bus. The data frame is used for a message transaction between the nodes.
Data Length Code (DLC): It represents the data length information of the transmitted message.
DATA: This field holds the actual message or index address of object types.
Cyclic Redundancy Check (CRC): It helps to identify the bit error in the message frame.
Acknowledgment (ACK): It represents the status of the transmitted message. If the message is successfully sent, the acknowledgment signal becomes dominant. For transmission failure, the ACK becomes recessive.
End of Frame (EoF): The seven consecutive recessive bits represents the end of the frame.
The master node initiates the CANopen protocol. The application layer performs initialization, configuration, and error handling on a CAN network. The CANopen library consists of hardware independent and hardware dependent services that communicate with message queues.
After p[ower-on, a device is in the initializing stage. On completion of the initialization, the device transmits the bootup message to the network to indicate that it is ready to work and switches to the pre-operational stage. In the pre-operational stage, the master can communicate via Service Data Objects for device configuration, but the exchange of Process Data Objects are not permitted.
In a multi-master network, only one master can command the network devices. In the idle state of the CAN bus, n-number of masters can start transmission of the arbitration message. The higher priority message wins the arbitration, and that master becomes active. The active master sends the reset command to all devices, whereas other masters work as a slave.
The active master finds all the nodes in the network using the network service message. It changes the slave device configuration and COB-ID using service data objects. The master can configure all slave devices at the same time or can configure them, one by one. All the devices in the network communicate at the same baud rate. A user can set the baud rate using the proprietary configuration tool.
After initialization of all parameters, the master controller sets all devices in its operational mode and communicates with them, either using Service Data Object mode or Process Data Object mode.
1. SDO communication mode: The SDO communication always starts with the master controller. Service Data Messages are used to access the object dictionary of a device. In this communication mode, the master sends a write or read request to the slave controller. The slave device replies to the master request. If any error occurs during reading or writing an object, the slave device sends an error message.
2. PDO communication mode: Process Data Objects are used to share the process information between multiple devices. In this mode, data can transfer from one node to one or more receiver nodes. There are two types of data transfer modes available, event-driven and remotely requested.
- Event-driven: In this case, the master does not need to poll status all the time. Instead, the occurrence of an object-specific event starts the PDO transfer to the network devices. Receiver devices use that process information and change the output state accordingly.
- Remotely requested: The master node sends a request message to slaves for PDOs. The slave devices respond for the request with valid process information. If the number of received data for the defined mapping is not sufficient, the entire PDO gets rejected, and an Emergency Message gets generated.
- Emergency message: The emergency messages get triggered by the occurrence of a device internal failures such as voltage failure, communication error, CAN Overrun (Object lost), or CAN-ID collision. In this situation, the Emergency Protocol transmits the Emergency Data Object to the network devices. The error message has a higher priority as it contains information about the error code and error register, as defined in the communication profile. The master provides the solution to the failure based on the error code.
A loss of the CANopen master can be fatal for the whole network. If the active master fails, a new negotiation is started automatically, depending on the priority of nodes and the node number of the master capable devices.
The CANopen is widely used in applications, such as electric vehicles, medical equipment, locomotive applications, and Industrial control application. There are many off-the-shelf devices, tools, and protocol stacks available for quick and easy implementation of your end application.