Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

Abstract

CANopen is a high-level communication protocol built on the Controller Area Network (CAN), where the object dictionary is the core concept of the protocol. Mastering its related content thoroughly will allow you to use CANopen with ease and confidence.

The CANopen object dictionary (OD: Object Dictionary) is the core concept of the CANopen protocol. The object dictionary is an ordered group of objects that describes all parameters corresponding to the CANopen node, including the storage location of communication data, which is also included in its index. This table, when made transferable, is called an EDS file (Electronic Data Sheet). The object dictionary is like a medical examination form, containing parameters for each function of a person, facilitating reasonable task allocation by the employer (master station). As shown in Figure 1.

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopenFigure1Object Dictionary and Medical Examination Form

Each object is addressed using a 16-bit index value, commonly referred to as the index, which ranges from 0x0000 to 0xFFFF. To avoid a lack of index allocation when there are many data points, an 8-bit index value is also defined under certain indexes, commonly referred to as the sub-index, which ranges from 0x00 to 0xFF.

Each specific parameter within an index can be represented using a maximum of a 32-bit variable, i.e., Unsigned32, four bytes.

Each CANopen device has an object dictionary that records these parameters using an Electronic Data Sheet (EDS file), eliminating the need to record these parameters on paper. For the master node in the CANopen network, it does not need to access every object dictionary item of the CANopen slave nodes.

The items in the CANopen object dictionary are described by a series of sub-protocols. Each sub-protocol describes the function, name, index, sub-index, data type of each object in the object dictionary, as well as whether this object is required, read/write attributes, etc., ensuring compatibility among similar devices from different manufacturers.

The core descriptor sub-protocol of the CANopen protocol is DS301, which includes the application layer and communication structure description of the CANopen protocol. Other sub-protocols are supplementary and expansions of the DS301 protocol description text. A CANopen device sub-protocol is drafted for different application industries, and the sub-protocol number is generally DS4xx.

Overview of the Object Dictionary

As shown in Table 1, the index area of the object dictionary is defined, where the green-highlighted communication object sub-protocol area and manufacturer-specific sub-protocol area are the areas the user needs to focus on.

Table 1 Overview of the Object Dictionary

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

Communication Object Sub-Protocol Area

The Communication Profile Area defines all object parameters related to communication. As shown in Table 2, the index range highlighted in green from 1000h to 1029h is for general communication objects, which all CANopen nodes must possess; otherwise, they cannot join the CANopen network. Other indexes are allocated and defined based on actual conditions.

Table 2 Communication Object Sub-Protocol Area

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

General Communication Objects

Due to the importance of general communication objects, the NMT master (CANopen master) typically reads all or part of the general communication objects’ indexes from all slaves during startup, so all general communication objects must be implemented in the CANopen slaves. Users must also be familiar with these index addresses and their meanings. As shown in Table 3.

Table 3 General Communication Objects

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

Manufacturer-Specific Profile

The object dictionary indexes from 2000h to 5FFFh are for manufacturer-specific profiles, usually storing application data of the applied sub-protocol. The previously described Communication Profile Area stores the communication parameters of these application data. For example, the XGate-COP10 slave module from Guangzhou Zhiyuan Electronics specifies that:

  • The communication parameters of RPDO are stored from 1400h to 15FFh, mapping parameters are stored from 1600h to 17FFh, and data is stored after 2000h in the manufacturer-defined area;

  • The communication parameters of TPDO are stored from 1800h to 19FFh, mapping parameters are stored from 1A00h to 1BFFh, and data is stored after 2000h in the manufacturer-defined area.

For special functions not defined in the device sub-protocol, manufacturers can also define object dictionary objects in this area as needed. Therefore, this area may have different definitions for the same object dictionary item among different manufacturers.

Standardized Profile Area

The standardized profile area defines the object dictionary objects for various types of standard devices across different industries. Currently, there are more than a dozen sub-protocols defined for different types of devices, such as DS401, DS402, DS406, etc., with index values ranging from 0x6000 to 0x9FFF. Similarly, this area may have different definitions for the same object dictionary item among different standardized device sub-protocols.

Easily Mastering the Most Difficult-to-Understand Object Dictionary of CANopen

CANopen Slave Module

Contact Information

  • Sales Phone: 400-888-4005 ext 1

  • Technical Support Phone: 400-888-4005 ext 2

Zhiyuan Electronics (ID: ZLG_zhiyuan )

Haven’t followed Zhiyuan Electronics yet? You will miss out on daily valuable insights! You will miss a history that disrupts foreign brands!! Sometimes you want to prove something to ten thousand people, but later you find that one understanding person is enough. Are you the congee we have been waiting for? Our WeChat ID: ZLG_zhiyuan.

Leave a Comment