In this article, we will introduce the basic knowledge of CANopen protocol. Contains object dictionary, service, SDO, PDO and master/slave nodes.
1. What is CANopen?
The CANopen protocol is a communication protocol based on CAN.
The CANopen standard is very effective because it enables existing interoperability between devices (nodes) in industrial machinery. In addition, it provides a standard method for configuring devices.
The CANopen protocol was originally designed for motion-oriented machine control systems.
Today, the CANopen protocol has been widely used in motor control (stepping/servo motors), but also in other applications:
Such as robot technology (automated robots, conveyor belts and other industrial machinery), medical category (X-ray generators, syringes, hospital beds and dialysis equipment), automotive industry (agriculture, railways, trailers, heavy duty, marine, etc.).
2. CANopen-high-level protocol
The CANopen protocol is a "higher layer protocol" based on the CAN bus.
This means that the CAN bus (ISO 11898) acts as a "vehicle" for CANopen communication.
CANopen in the OSI model as shown below:
The OSI model is a conceptual model used to standardize communication functions between various communication technologies. The lower layer describes basic communication (eg, raw bitstream), while the higher layer describes things such as segmentation of long messages and services such as initiation, indication, response, and confirmation of messages.
The CAN bus represents the two lowest layers (1: physical layer, 2: data link). This shows that CAN can simply enable the transmission of frames with 11-bit CAN ID, remote transmission (RTR) bits and 64 data bits (fields related to higher-level protocols).
As shown above, the CANopen protocol implements the seventh layer of the OSI model (application) through a set of standard protocols. As part of it, it adds some important concepts, which we will introduce in detail below.
In addition, CANopen can also be applied to other data layer protocols other than CAN (eg EtherCAT, Modbus, Powerlink).
3. Six core concepts of CANopen
Even if you are familiar with the CAN bus protocol, the CANopen protocol will add a series of important new concepts:
Communication mode
There are three models of device/node communication: master device/slave device, client/server and producer/consumer
Protocol
Protocols are used for communication, such as configuring nodes (SDO) or transmitting real-time data (PDO)
device status
The device supports different states. The "master" node can change the state of the "slave" node, for example to reset it.
Object dictionary
Each device has an OD, and the OD has entries specifying the device configuration, which can be accessed via SDO
EDS
EDS is a standard file format for OD that allows the service of updating devices
Device profile
The CIA standard describes vendor independent I/O modules (CiA 401) and motion control (CiA 402)
The following figure shows the relationship between the six concepts of CANopen. We will explain each concept in detail below:
In a CANopen network, multiple devices need to communicate.
For example, in an industrial automation setup, you may have a robot with multiple servo motor nodes and a control interface/PC node.
To facilitate communication, there are three models within CANopen-each model is closely related to the CANopen protocol that we will discuss shortly. See the brief introduction below:
1. CANopen communication model
(1) Master and slave
A node (such as a control interface) acts as the application's main node or host controller. It sends/requests data from a slave station (for example, a servo motor). This is used for diagnosis or status management, for example. In standard applications, there can be 0-127 slaves. Please note that in a single CANopen network, there may be different host controllers sharing the same data link layer.
Service example: NMT
(2) Client server
The client sends a data request to the server, and the server will reply with the requested data. For example, it is used when the application host needs data from the slave OD. Reading from the server is "uploading" and writing is "downloading" (the term uses the "server-side" view).
Service example: SDO
(3) Consumers/producers
Here, the producer node broadcasts the data to the network and is consumed by the consumer node. The producer sends this data upon request (pull model) or without specific request (push model).
Obviously, these models are actually the same, but for consistency of terminology, we have distinguished them.
2. Communication protocol
To understand CANopen communication, it is necessary to understand the CANopen/CAN framework:
The 11-bit CAN ID is called the communication object identifier (COB-ID) and is divided into two parts: By default, the first 4 bits are equal to the function code, and the last 7 bits contain the node ID.
In order to understand how COB-ID works, let us first understand the predefined assignment of identifiers used in a simple CANopen network (see table below).
Note: We will refer to the COB-ID and node ID in hexadecimal below.
Obviously, the COB-ID (for example, 381, 581, etc.) is linked to the communication service (sending PDO 3, sending SDO, etc.).
In this way, the COB-ID specifies which node is sending/receiving data and the services used.
Example: A CANopen device with a node ID of 5 will transmit SDO via the 11-bit CAN ID 585.
This corresponds to binary function code 1011 and node ID 5 (binary: 0000101)-see diagram:
7 service types of CANopen communication protocol
Below we briefly outline the above seven service types, including. How do they use 8 CAN frame data bytes.
#1 Network Management (NMT)
Definition: The NMT service is used to control the state of CANopen devices (eg, pre-operation, operation, stop) through NMT commands (eg, start, stop, reset).
How it works: In order to change the status, the NMT master sends a 2-byte message with a CAN ID of 0 (that is, function code 0 and node ID 0). All slave nodes process this message. The first CAN data byte contains the status of the request-and the second CAN data byte contains the node ID of the target node. Node ID 0 indicates a broadcast command.
Commands include transition to operation (state 01), stop (state 02), before operation (state 80), and reset application (81) and reset communication (82).
#2 SYNC
Definition: SYNC messages are used, for example, for the sensing of synchronous inputs and the actuation of several CANopen devices-usually triggered by the application host.
How it works: The application host sends a SYNC message (COB ID 080) to the CANopen network (with or without a SYNC counter). Multiple slave nodes can be configured to react to SYNC and respond by sending input data captured simultaneously with nodes participating in the synchronization operation or setting outputs simultaneously. Using the SYNC counter, you can configure several sets of synchronously operated devices.
#3 Emergency Situation (EMCY)
Definition: Emergency services are used when the device has a fatal error (such as a sensor failure) so that it can indicate this error to the rest of the network.
How it works: The affected node sends a single EMCY message to the network with high priority (for example, node 5 has COB-ID 085). The data byte contains information about the error, you can find detailed information.
#4 Timestamp (TIME) [PDO]
Definition: Using this communication service, global network time can be allocated. The TIME service contains a 6-byte date and time information.
How it works: The application host sends a TIME message with CAN ID 100, where the first 4 data bytes contain the number of milliseconds after midnight, and the next 2 bytes contain the number of days since January 1, 1984.
#5 Process Data Object [PDO]
Definition: PDO service is used to transmit real-time data between devices, such as measurement data (such as position) or command data (such as torque request). In this respect, it is similar to the broadcast data parameters in J1939, for example.
How does it work? We will discuss it in depth below.
#6 Service Data Object [SDO]
What is it? The SDO service is used to access/change values in the object dictionary of CANopen devices-for example, when the application host needs to change certain configurations of CANopen devices.
How does it work? We will discuss it in depth below.
#7 Node monitoring [SDO]
Definition: The heartbeat service has two purposes: to provide an "active" message and confirm the NMT command.
How it works: The NMT slave device sends heartbeat messages (for example, CAN ID 705 of node 5) periodically (for example, every 100 milliseconds) and sends the node's "status" in the first data byte
If the message is not received within a certain period of time, the "consumer" of the heartbeat message (such as the NMT master device and any other optional devices) will react.
PDO and SDO services are particularly important because they form the basis of most CANopen communications.
Below we will discuss these contents in depth, but first, we need to introduce the core concept of CANopen: object dictionary.
3. CANopen object dictionary
All CANopen nodes must have an object dictionary (OD), but what is it?
The object dictionary refers to a standardized structure containing all parameters describing the behavior of the CANopen node.
Find the OD entry by 16-bit index and 8-bit subindex. For example, the index 1008 (sub-index 0) of the node OD conforming to CANopen contains the node device name.
Specifically, the entries in the object dictionary are defined by attributes:
Index: 16-bit base address of the object
Object name: manufacturer equipment name
Object code: array, variable or record
Data type: such as VISIBLE_STRING or UNSIGNED32 or record name
Access: rw (read/write), ro (read only), wo (write only)
Category: Indicates whether this parameter is required/optional (M/O)
OD standardized part
The object dictionary is divided into standardized parts, some of which are required, while others are completely customizable.
It is important that the OD entry of the device (eg slave) can be accessed via CAN by other devices (eg master) using SDO.
For example, this may cause the application host to change whether the slave node records data through a specific input sensor, or how often the slave sends heartbeats.
Link to spreadsheets and device profiles
To understand OD, it is helpful to view the spreadsheet and device configuration files.
Electronic Data Sheet (EDS)
In practice, appropriate software tools will be used to configure/manage complex CANopen networks.
To simplify this process, the CiA 306 standard defines a human-readable (and machine-friendly) INI file format that is used as a "template" for device ODs (such as "ServoMotor3000"). This EDS is usually provided by the vendor and contains information about all device objects (but not values).
Device Configuration File (DCF)
Suppose a factory purchases ServoMotor3000 and integrates it into its conveyor belt. To do this, the operator edits the device EDS and adds specific parameter values ??and/or changes the name of each object described in EDS.
In doing so, the operator can effectively create a so-called device configuration file (DCF). With this, ServoMotor3000 can be integrated into a specific CANopen network on site.
EDS and DCF examples
The EDS/DCF example is the best way to really understand the CANopen object dictionary, for example, see the difference between the EDS and DCF object entries below. We recommend that you review the CiA 306 standard to gain a deeper understanding of OD, EDS and DCF through practical examples.
As mentioned above, DCF is usually created during device integration. However, it is usually necessary to read and/or change the object value of the node after initial configuration-this is where the SDO service comes into play.
4. SDO-Configure CANopen network
What is SDO service?
This SDO service allows the CANopen node to read the object dictionary/edit value of another node via the CAN network.
As stated in the "Communication Model", SDO services utilize "client/server" behavior.
Specifically, an SDO "client" initiates communication with a dedicated SDO "server".
The purpose can be to update the OD entry (called "SDO download") or to read the entry ("SDO upload").
In a simple master/slave network, the node with the NMT master function acts as a client for all NMT slave nodes to read or write their OD.
Example: Client node SDO download
The client node can initiate the SDO download to node 5 by broadcasting below the CAN frame, which will trigger node 5 (and be ignored by other nodes, see the figure above). The SDO "receive" (ie request) CAN frame is as follows:
SDO message variable description:
First, COB-ID 605 reflects the use of "SDO Reception" (COB-ID 600 + Node ID).
The CCS (Client Command Specifier) ??is the type of transmission (for example, 1: download, 2: upload)
n is #bytes that does not contain data in data bytes 4-7 (valid if e&s is set)
If set, e means "fast transmission" (all data in a single CAN frame)
If set, s indicates that the data size is displayed in n
The index (16-bit) and sub-index (8-bit) reflect the OD address to be accessed
Finally, bytes 4-7 contain the data to be downloaded to node 5
Annotation example:
Once the master node (client) sends a CAN frame, the slave node 5 (server) will respond via "SDO send" with COB-ID585. The response contains the index/sub-index and 4 empty data bytes. Naturally, if the client node requests an upload (that is, reads data from node 5 OD), node 5 will respond with the relevant data contained in bytes 4-7.
Obviously, each SDO uses 2 identifiers to create a "SDO channel"
The example has been simplified to "fast" (data is contained in 4 bytes)
For larger data schemes, SDO segmentation/block transmission can be used
SDO is flexible, but it will bring a lot of output, making it unsuitable for real-time operation data.
But this is the main role of PDO.
5. PDO-Run CANopen network
First: What is the CANopen PDO service?
The PDO service is used to effectively share real-time operating data across CANopen nodes.
For example, PDO will carry pressure data from a pressure sensor or temperature data from a temperature sensor.
But can't the SDO service do this?
Yes, SDO services can be used in principle. However, due to the output (command byte and OD address), a single SDO response can only carry 4 data bytes. In addition, suppose a master node needs two parameter values ??from node 5 (eg "SensTemp2" and "Torque5")-to get this value via SDO, it will require 4 complete CAN frames (2 requests, 2 responses ).
In contrast, a PDO message can contain 8 full bytes of data-and it can contain multiple object parameter values in a single frame. Therefore, it may be necessary to complete the SDO operation with at least 4 frames in one frame in the PDO service.
Because PDO carries a lot of information, it is usually regarded as the most important CANopen protocol.
How does the PDO service work?
For PDO, use consumer/producer terminology. Therefore, the producer "produces data" and uses the transmission PDO (TPDO) to transmit it to the "consumer" (primary user). Instead, it can receive data from users by receiving PDO (RPDO).
The producer node may, for example, be configured to respond to the SYNC trigger broadcast by the consumer every 100 ms. Then, the node 5 may, for example, broadcast below to send the PDO with COB-ID 185:
Note how the data bytes are packed with 3 parameter values. These values reflect the real-time data of the specific OD entry of node 5. The node (user) using this information of course needs to know how to interpret the PDO data bytes.
