Shulou(Shulou.com)06/01 Report--

Brief introduction of 1.CANopen Protocol

At the same time, CAN only defines the physical layer and the data link layer, but does not specify the application layer, which itself is not complete, so it needs a high-level protocol to define the use of 11jump 29-bit identifiers and 8-byte data in CAN messages. Moreover, in the application of industrial automation based on CAN bus, there is a growing need for an open and standardized high-level protocol: this protocol supports the interoperability and interchangeability of all kinds of CAN equipment, and can provide a standard and unified system communication mode in CAN network, provide equipment function description, and perform network management functions.

The CANopen protocol is one of the standards defined by CAN-in-Automation (CiA) and has been widely recognized shortly after its release. Especially in Europe, CANopen protocol is considered to be the leading standard in CAN-based industrial systems. With the support of CANopen protocol, devices from different manufacturers can be configured through the bus.

In the OSI model, the relationship between CAN standard and CANopen protocol is shown in figure 1-1.

Figure 1-1 location block diagram of CAN standard and CANopen protocol in OSI network model

The relationship between CANopen and CAN messages is shown in figure 1-2.

Figure 1-2 the relationship between CANopen and CAN messages is shown.

The CAN message consists of seven different bit fields, and CANopen specifies the use of the arbitration field (11-bit identifier) and the data field (8 bytes of data).

2.CANopen device structure

CANopen is a high-level protocol based on CAN serial bus system and CAL (CAN application layer). The core concept of CANopen is the device object dictionary (OD: ObjectDictionary). CANopen communication can access all the parameters of the driver through the object dictionary (OD). The structure of the CANopen device is shown in figure 2-1.

Figure 2-1 CANopen device structure

2.1 CANopen object Dictionary

CANopen object Dictionary (Object Dictionary,OD) is the core concept of CANopen protocol. The so-called "object dictionary" is an ordered group of objects; each object is addressed with a 16-bit index value. In order to access the elements in the data structure, an 8-bit subindex is defined, and the structure of the object dictionary is shown in Table 2-1.

Table 2-1 object dictionary structure

Each node in the CANopen network has an object dictionary. The object dictionary contains all the parameters that describe the device and its network behavior.

Items in the CANopen object dictionary are described by a series of subprotocols. The sub-protocol describes the function, name, index, sub-index, data type, read / write properties of each object in the object dictionary, and whether the object is necessary or not, so as to ensure the compatibility of the same type of devices from different manufacturers.

The core description sub-protocol of CANopen protocol is DS301, including the application layer and communication structure description of CANopen protocol. Other sub-protocols are the supplement and extension of DS301 protocol description text.

The CANopen protocol contains many subprotocols, which are mainly divided into the following three categories:

1. Communication subprotocol

The communication subprotocol (Communication Profile) describes the main form of the object dictionary, as well as the communication objects and parameters in the object dictionary. This subprotocol applies to all CANopen devices and has an index value range of 0x1000~0x1FFF.

two。 Manufacturer custom subagreement

For special functions not defined in the device subprotocol, the manufacturer can define object dictionary entries according to requirements in the manufacturer custom subprotocol (Manufacturer-specific Profile). Therefore, the definition of the same object dictionary entry in this area is not necessarily the same for different vendors, and its index value range is 0x2000~0x5FFF.

3. Equipment subprotocol

The device subprotocol (Device Profile) defines objects in the object dictionary for different types of devices, with index values ranging from 0x6000~0x9FFF.

2.2 CANopen communication

In CANopen protocol, four kinds of objects are mainly defined: network management object (NMT), service data object (SDO), process data object (PDO), predefined message or special function object.

2.2.1 Network Management object

Network management objects are responsible for layer management, network management, and ID allocation services, such as initialization, configuration, and network management. In network management, only one master node, one or more slave nodes are allowed in the same network, and the master / slave mode is followed.

2.2.2 Service data object

The service data object is mainly used for the parameter configuration of the master node to the slave node. Service confirmation is the most important feature of SDO, which generates a reply for each message to ensure the accuracy of data transmission. In a CANopen system, usually the CANopen slave node acts as the SDO server and the CANopen master node acts as the client. The client can access the object dictionary on the data server through the index and sub-index, so the CANopen master node can access the parameters of any object dictionary entry of the slave node, and SDO can transmit data of any length (when the data length is more than 4 bytes, it is split into multiple messages to transmit).

2.2.3 process data object

The process data object is used to transmit real-time data, and its transmission model is a producer-consumer model, and the data length is limited to 1-8 bytes.

PDO communication objects have the following characteristics:

1. There is no protocol for PDO communication, and the content of PDO data is defined by its COB-ID. two。 Each PDO is described by two objects in the object dictionary, which are PDO communication parameters and mapping parameters.

1) PDO communication parameters: define the COB-ID, transmission type and timing period used by the device.

2) PDO mapping parameters: contains a list of objects in the object dictionary, which are mapped to the corresponding PDO, including the length of the data. For producers and consumers, only when this mapping parameter is known can the content of PDO be correctly interpreted. The PDO content is predefined, and if PDO supports variable PDO mapping, it can be configured through SDO.

3. PDO has two transmission modes: synchronous transmission and asynchronous transmission.

1) synchronous transmission: synchronization is realized by receiving synchronization objects, which can be divided into aperiodic transmission and periodic transmission according to the trigger mode. Aperiodic transmission is pre-triggered by remote frames or by object-specific events specified in the device subprotocol. Periodic transmission is realized by receiving synchronization objects, which can be triggered by 240 synchronization objects.

2) Asynchronous transfer: triggered by a specific event. According to the trigger mode, it can be divided into two types: one is triggered by sending the same remote frame as the COB-ID of PDO, and the other is triggered by object-specific events specified in the device sub-protocol (such as timing transmission, data change transmission, etc.).

2.2.4 predefined messages or special function objects

Predefined messages or special function objects provide specific functions for CANopen devices to facilitate the management of CANopen master stations to slave stations. In the CANopen protocol, COB-ID has been predefined for special functions. There are mainly the following special messages:

1. Synchronous message (Sync)

It mainly realizes the synchronous transmission of the whole network, and each node uses the synchronization message as the PDO trigger parameter, so the COB-ID of the synchronization message has a higher priority and the shortest transmission time.

two。 Time marking message (Time Stamp)

Provide a common time reference for each node.

3. Emergency incident message (Emergency)

When an error occurs within the device, the object is triggered, that is, the internal error code of the device is sent.

4. Node / Life Protection message (Node/Life Guarding)

The master node can obtain the status of the slave node through the node protection mode, and the slave node can obtain the status of the master node through the life protection mode.

5. Startup message (Boot up)

After the initialization of the node is completed, the object is sent to the network and enters the pre-operation state.

2.3 CANopen predefined connection set

In order to reduce the configuration workload of simple networks, CANopen defines a mandatory default identifier (CAN-ID) allocation table. These identifiers are available in a pre-operational state and can be modified by dynamic allocation. The CANopen device must provide the appropriate identifier to the communication object it supports.

The CAN-ID allocation table is based on the standard frame format of 11-bit CAN-ID and is divided into 4-bit function codes and 7-bit node numbers, as shown in figure 2-2.

Figure 2-2 predefined connection set ID

Node-ID is defined by the system integrator, and each CANopen device needs to be assigned a node number, which ranges from 1 to 127 (0 is not allowed to be used).

The predefined connection set defines 4 receiving PDO,4, sending PDO,1, SDO (occupying 2 CAN-ID), 1 emergency object and 1 node error control. Support for NMT module control services, synchronization and time identification object messages without acknowledgement. The default ID allocation table is shown in Table 2-2.

Table 2-2 CANopen predefined Master / Slave connection set CAN Identifier allocation Table

Note:

1) the PDO/SDO transmit / receive is observed by the (slave) CAN node.

2) NMT error control includes node protection (NodeGuarding), heartbeat message (Heartbeat) and Boot-up protocol.

3. references

"CANopen:high-level protocol for CAN-bus"

Project driven-basic course of CAN-bus fieldbus

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.