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.
What is the CANopen Network Protocol?
CANopen is a commander-responder 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 commander 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 responder 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 commander protocol stack offers the functionality of the CANopen standards CiA 301, CiA 302, and CiA 305. The CANopen responder protocol stack facilitates the functioning of I/Os such as intelligent sensors and actuators.
Network Architecture
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 commander and responder 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.
Commander node: CANopen commander node is the commander of the CANopen network, and is responsible for data communication, synchronization, and network management. A single CANopen commander can communicate with up to 127 responder devices in a network. A CANopen commander can be implemented on a single board computer (SBC) or Personal Computer (PC), with a commander 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 commander library helps to build a CANopen commander system quickly and easily.
Responder node: The CANopen responder device performs tasks, specified by the commander. Usually, the responder 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 responder-node in the network. The acceptance filter has to be implemented in a responder 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 commander 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.
Operation
The commander 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 power-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 commander can communicate via Service Data Objects for device configuration, but the exchange of Process Data Objects are not permitted.
In a multi-commander network, only one commander can command the network devices. In the idle state of the CAN bus, n-number of commanders can start transmission of the arbitration message. The higher priority message wins the arbitration, and that commander becomes active. The active commander sends the reset command to all devices, whereas other commanders work as a responder.
The active commander finds all the nodes in the network using the network service message. It changes the responder device configuration and COB-ID using service data objects. The commander can configure all responder 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 commander 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 commander controller. Service Data Messages are used to access the object dictionary of a device. In this communication mode, the commander sends a write or read request to the responder controller. The responder device replies to the commander request. If any error occurs during reading or writing an object, the responder 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 commander 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 commander node sends a request message to responders for PDOs. The responder 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 commander provides the solution to the failure based on the error code.
A loss of the CANopen commander can be fatal for the whole network. If the active commander fails, a new negotiation is started automatically, depending on the priority of nodes and the node number of the commander capable devices.
Applications
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.