In the previous article, we briefly introduced the CANopen framework and the seven types of CANopen services. In this article, we will elaborate on the Object Dictionary, SDO, and PDO of CANopen. This series of articles mainly introduces the CANopen protocol, covering topics such as the Object Dictionary, services, SDO, PDO, and master/slave nodes. For CANopen software and hardware solutions or training services, you can contact the HongKe Industrial Control Team via 400-999-3848 or [email protected]!
Previous Review:
HongKe Insights | A Simple and Practical Introduction to CANopen (1)
HongKe Insights | A Simple and Practical Introduction to CANopen (2)
Among the seven CANopen services, PDO and SDO services are particularly important as they form the basis of most CANopen communications. Below, we will introduce them in detail, but first, we need to understand a core concept of CANopen: the Object Dictionary.
1
Object Dictionary (OD)
Object Dictionary
All CANopen nodes must have an Object Dictionary (OD), which is a standardized structure that contains all parameters describing the behavior of the CANopen node. OD entries are queried using a 16-bit index and an 8-bit sub-index. For example, the index 1008 (sub-index 0) of a node’s OD compliant with the CANopen standard contains the node’s device name.
Specifically, the entries in the Object Dictionary are defined by the following attributes:
❖
Index: The 16-bit address of the object
❖
Object Name: The manufacturer’s device name
❖
Object Code: Array, variable, or record
❖
Data Type: For example, VISIBLE_STRING, UNSIGNED32, or record name
❖
Access: “rw” (read/write), “ro” (read-only), or “wo” (write-only)
❖
Category: Indicates whether the parameter is mandatory or optional
Standardized Part of OD
The Object Dictionary is divided into standardized parts, with some entries being mandatory while others are fully customizable. Importantly, an OD entry of a device (e.g., a slave device) can be accessed by another device (e.g., a master device) via CAN, such as using SDO. This allows the master to change whether the slave node records data through specific input sensors or alters the frequency at which the slave sends heartbeats. Reading electronic data sheets and device configuration files can help understand the OD.
Electronic Data Sheet (EDS)
In practice, configuring/managing complex CANopen networks will require suitable software tools. To simplify this, the CiA 306 standard defines a human-readable and machine-friendly INI file format as a “template” for device ODs—such as “ServoMotor3000.” This EDS is typically provided by the vendor and contains information about all device objects (excluding values).
Device Configuration File (DCF)
Suppose a factory purchases a ServoMotor3000 for integration into their conveyor system. During operation, the operator edits the device’s EDS and adds specific parameter values or changes the description names of each object. In this way, the operator effectively creates what is known as a Device Configuration File (DCF). With this file, the ServoMotor3000 can be integrated into the specific CANopen network on-site.
Viewing real EDS/DCF examples is one of the best ways to understand the CANopen Object Dictionary. In the image below, you can notice the differences between EDS and DCF object entries and how the DCF includes specific parameter values.
Additionally, we recommend checking the official website for the CiA 306 standard to gain a deeper understanding of OD, EDS, and DCF through practical examples.
As mentioned earlier, DCF is usually created during device integration. However, it is often necessary to read or change an object’s value after the initial configuration—this is where the SDO service comes into play.
2
Service Data Object (SDO)
Configuring CANopen Networks
SDO services allow CANopen nodes to read/edit another node’s Object Dictionary values over the CAN network. As mentioned in the “Communication Model,” SDO services operate in a “client/server” mode. Specifically, an SDO “client” initiates communication with a dedicated SDO “server.” The purpose can be to update an OD entry (known as “SDO download”) or to read an entry (“SDO upload”). In a simple master/slave network, nodes with NMT master functionality act as clients to read or write the OD of all NMT slave nodes.
Example
Client Node SDO Download:
The client node can initiate an SDO download to node 5 via a broadcast below the CAN frame—this will trigger node 5 (and be ignored by other nodes, see above). The SDO “receive” (i.e., request) CAN frame is as follows:
SDO Message Variable Explanation
-
First, COB-ID 605 reflects the use of “SDO receive” (COB-ID 600 + node ID)
-
CCS (Client Command Specifier) is the transfer type (e.g., 1: download, 2: upload)
-
n is the number of bytes not included in bytes 4-7 (if e and s are set to valid)
-
e indicates “accelerated transfer,” and all data is in a single CAN frame (if set)
-
s indicates the data size displayed as n (if set)
-
The index (16-bit) and sub-index (8-bit) reflect the OD address to be accessed
-
Finally, node 5 will provide the relevant data contained in bytes 4-7
Once the master node (client) sends the CAN frame, the slave node 5 (server) responds with an “SDO transmission” via COB-ID 585. The response contains the index/sub-index and four empty data bytes. Naturally, if the client node requests an upload (i.e., reads data from node 5’s OD), node 5 will respond with the relevant data contained in bytes 4-7. Furthermore, for larger data scenarios, SDO segmentation/block transfer can be used.
In general, SDO is flexible but also incurs higher costs, making it less suitable for real-time operational data. This is where PDO comes into play.
3
Process Data Object (PDO)
Operating CANopen Networks
PDO services in CANopen are used to efficiently share real-time operational data between CANopen nodes. For example, PDO can carry pressure data from a pressure sensor or temperature data from a temperature sensor. In principle, SDO services could also achieve real-time operational data sharing, but since a single SDO response can only carry four data bytes, we do not recommend doing so for cost reasons.
Additionally, suppose a master node needs two parameter values from node 5 (e.g., “SensTemp2” and “Torque5”). If achieved through SDO, it would require four complete CAN frames (two requests and two responses). In contrast, a PDO message can contain eight complete data bytes and can include multiple object parameter values in a single frame. Therefore, at least four messages are needed in SDO service, while only one message may be needed in PDO service.
PDO is often seen as the most important CANopen protocol, as it carries a large amount of information. Below, we will introduce how the CANopen PDO service works.
PDO services use a “producer/consumer” model. Therefore, the producer “produces data” and transmits it to the “consumer” (master) using the sending PDO (TPDO). Conversely, it can receive data from the consumer via the “receiving PDO” (RPDO). For example, the producer node can be configured to trigger synchronization accordingly, broadcasting to the consumer every 100ms. Then, node 5 can broadcast under the PDO with COB-ID 185:
Note how the data bytes here are filled with three parameter values. These values reflect the real-time data of specific OD entries from node 5. The nodes using this information (consumers) need to know how to interpret the PDO data bytes.
To some extent, PDO services are somewhat similar to J1939 PGN and SPN, which is how specific J1939 parameter groups (PG) contain multiple SPN/signals (also known as data parameters) within 8 data bytes. J1939 CAN frames do not waste data bytes on “decoding” information because the relevant nodes (as well as external tools through J1939 DBC files or J1939 PDF standards) know this. The issue in CANopen is that these “PDO mappings” are often configurable and can be changed during the creation of DCF or via SDO services.
4
HongKe CANopen Solutions
HongKe Solutions
HongKe CANopen Data Logger
CANopen is often used in electric forklifts or automated guided vehicles in warehouses. Monitoring and analyzing CANopen data is beneficial for improving management, such as monitoring charging status to reduce failures and improve battery life. Additionally, industrial machinery can be monitored through cloud-based IoT CAN loggers, predicting and preventing failures based on CANopen data. Moreover, CAN loggers can serve as a “black box” for industrial machinery, providing data for resolving disputes between OEMs and users or as part of rare issue diagnostics.
HongKe CANopen IO Modules
The HongKe HK-CIO series is a remote IO module that supports the CANopen protocol, with IO types including digital, analog, high-speed counters, pulse outputs, PWM, PT100/1000, etc. It features a compact design and supports DIN rail mounting, with electrical isolation between IO and CANopen communications.
HongKe CANopen Protocol Development Solutions
HongKe’s CANopen source code implements full functionality compliant with the CiA 301 standard draft, supporting quick and standardized development of your CANopen master or slave devices, including NMT master (network management), LSS master (layer setting service), or SDO client.
For more information
Feel free to email [email protected]
END
▎Previous Issues