This article contains a simple tutorial introduction to CANopen, to give you a non-professional and simple explanation of the CANopen protocol.
In this article we present the CANopen communication protocol basics, combined with the object dictionary, services, PDO, SDO and master/slave nodes.
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.
The communication unit implements a protocol for sending and receiving messages with other nodes in the network, such as; controlling the startup and reset of the device through the state machine. It must include state initialization, before running, running, and stopping. The transition between states by sending out network management (NMT) protocol communication objects to the device.
The object dictionary is a 16-bit index list of variables. In addition, each variable can have an 8-bit sub-index. Variables can be used to configure the device and reflect its environment, that is, contain measurement data. After the state machine is set to the operating state, the application part of the device performs the required functions of the device. The application is configured by variables in the object dictionary, and data is sent and received through the communication layer in the OSI model.
CANopen adds a range of new important concepts, that is built on the CAN bus and J1939.
Communication protocols - CANopen protocols are used for communication, state machine change commands, and monitor nodes in the network.
Communication models - 3 different kinds of models are used in the messaging between CANopen nodes: Master/slave, client/server, and producer/consumer.
Communication objects - All communication objects (application data and configuration parameters) of the device are described in its object dictionary in a standardized way. These objects can be accessed via a 16-bit index, and for arrays and records, there is an additional 8-bit sub-index.
Object dictionary - Each CANopen device must have an object dictionary which is the interface between the communication interface and the application software, describing the full functionality of a computer by communication objects.
Electronic data sheet - Electronic Data Sheet is a file format defined in CiA306, which describes the communication behavior of the device and object dictionary entries. In this way, tools such as service tools, configuration tools, and development tools can handle the equipment correctly.
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.
Master/Slave: The control interface acts as the application master controller and sends/requests data from the servo motors i.e., the slaves.
Client/Server: A client sends a data request to a server, which replies with the requested data.
Consumer/Producer: The producer node broadcast data to the network, which is consumed by the consumer node.
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.
Service Data Object
Each node on the network must also implement a server that handles read/write requests to its object dictionary, according to the CANopen protocol. This enables a CANopen master to communicate with the server as a client. The Service data object is the framework for direct access (read/write) to the server's object dictionary.
The node that accesses the object dictionary is known as the SDO server, and the node that grabs the data is known as the SDO client. The SDO client often initiates the switch.
Process Data Object
Process data refers to data that can change over time, such as the node controller's inputs (sensors) and outputs (motor drives). The object dictionary also stores process data. However, since SDO communication only allows access to one object dictionary index at a time, accessing constantly changing data can be time-consuming.
A node must also be able to send its own data without having to be polled by the CANopen master, according to the CANopen protocol. As a result, a particular method of transferring process data is used, called Process data objects.
If you are interested to learn more about other protocols, we have got your back. Learn more about CAN Bus, CAN FD, SAE J1939, LIN Bus, and more.
We can help you with your current project and build tailored solutions even for your specific needs. Contact us and find out more.