CANopen is based on the C level communication protocols and device profile specification AN protocol. This protocol was developed for embedded network applications (such as in-vehicle networks). CANopen covers the network programming framework, device descriptions, interface definitions and application configuration files. CANopen standardizes the communication between devices and applications from different manufacturers. It has been widely used in various industries and has outstanding performance in automation and motion applications.
As far as the OSI communication system model is concerned, CAN covers the first two levels: the physical layer and the data link layer. The physical layer defines the lines used, voltages, high-speed characteristics, etc. The standard CAN protocol implements the data link layer, which is a frame-based (message) protocol. CANopen covers the above five layers: network (addressing, routing), transmission (end-to-end reliability), session (synchronization), representation (data encoded in a standard way, data representation) and application. The application layer describes how to configure, transmit and synchronize CANopen devices.
Many processors have implemented CAN bus interfaces and drivers. We assume that readers already understand the basic knowledge of CANBUS, and focus on the application CANopen protocol.
Basic concepts of CANopen
The emergence of every new technology will be accompanied by a lot of technical terms and English abbreviations, making it difficult for beginners to understand. One Japanese called it "a torrent of terms". It is much better to use simple language to explain the basic framework of a complicated matter than to throw out the terms and details at the beginning. This is my attempt at writing this blog post.
- CANBUS is a bus type communication network. All nodes are connected in parallel on two communication lines.
- CANBUS is similar to Ethernet and is based on frame transmission, except that one frame of Ethernet can be 1500 bytes, while CANBUS frame can only transmit 8 bytes at most
Ethernet frame structure
CANopen frame structure
Don't think that a short data frame is not good. Short has the advantage of being short. It will be more reliable and real-time.
- The 11 bits are further divided into 4 function codes and 7 IDs. 7-bit size limit The number of devices on the CANopen network is limited to 127 nodes.
- In a control system, the device ID and data format are specified by the system manufacturer. For example, the author once developed a steering wheel angle sensor on a car. It is designed by the frame data format and ID data table provided by the car factory. It is not the same as similar products from Bosch.
We have been saying that the underlying communication protocol only solves the problem of grammar, but does not solve the problem of grammar-does the data represent the above meaning?
CANOpen is an application protocol based on the CANBUS link layer to solve semantic problems (what does 8 bytes mean?). Let the products of different manufacturers be truly interconnected.
Object-based communication
Each device has various data to be exchanged with the outside world, such as the angle, speed and acceleration of the direction sensor. These parameters have characteristics such as name, type, and length. The simplest way to access these parameters is to define the address and length. Then read. The modbus protocol in PLC is such a simple and rude method. This low-level approach is obviously more error-prone. The setup is complicated.
Control protocols have increasingly adopted the idea of object-oriented programming. Define each parameter as a data object. And it can be written in a human-readable way, such as XML language for description.
CANopen uses a similar idea. It defines parameters as objects. Each device has an object dictionary. The object dictionary can be described by a file. It is called EDS (Electronic data sheet), and it uses the INI file format.
In order to simplify the data exchange in the protocol, the CANopen protocol only customizes the index and sub index of the object and does not transmit all the information of the object. This is like exchanging only the page numbers, rows, and columns in a dictionary. Both parties in the communication go to look up the dictionary. Understand the specific meaning.
As a result, the poor 8 bytes of CANBUS are divided into three parts. One byte is used for the specifier, three bytes are used for the node index and sub-index, and four bytes are used for the actual data in transmission. The real data is only 4 bytes.
When all the data that needs to be transmitted cannot be put into a message, segment transmission will be selected, so multiple messages or "segments" must be used to transmit data. The seventh of the specifier is 1 to indicate that there is subsequent data.
Object dictionary
One of CANopen's central themes is the Object Dictionary (OD), which is essentially a table for storing configuration and process data. All CANopen devices must implement an object dictionary.
The CANopen standard defines a 16-bit bit index and an 8-bit sub-index. In other words, each index is allowed to contain up to 65536 indexes and 256 subentries.
The standard defines that certain indexes and index ranges must contain specific parameters. For example, the standard definition index 1008h (sub-index 00h) must contain the device name. In this way, any CANopen master can read this index from the CANopen slave network,
Some object dictionary indexes (such as device type (1000h)) are mandatory, while others are optional, such as manufacturer software version (100Ah). The set of mandatory indexes represents the minimum object dictionary, which is necessary for marking CANopen-compliant devices.
The two communication mechanisms for accessing the object dictionary are Service Data Objects (SDO) and Process Data Objects (PDO).
The basic data types contained in the object dictionary are: Boolean, void (placeholder), unsigned integer, signed integer, floating point number and character. You can construct more complex data types from basic data types, such as string, date, and time.
EDS file
As mentioned earlier, every CANopen compatible device needs to provide an EDS file so that other devices that access the node can form an object dictionary. The master station program needs to import the EDS file. EDS uses the INI file format. It was originally the format of windows configuration files. Some manufacturers have also developed editing tools for EDS.
Service Data Object (SDO)
On the CANopen protocol network, each node must implement a server, which processes read/write requests for its object dictionary. The CANopen master serves as the client of the server. The mechanism for direct access (read/write) of the server object dictionary is the Service Data Object (SDO) . The node that has accessed the object dictionary is called the SDO server, and the node that gets the data is called the SDO client. The transmission is always initiated by the SDO client.
Usually, the main CANopen node will send a request to the network, and the interested node will respond with the requested data. When the SDO client wants to request information from the server, it will send the SDO request using the CAN-ID of 600h + node ID. Then, the server will respond with 580h CAN-ID + node ID. The node ID specifies which slave node the message comes from. In the example shown below, the CAN-ID of the master node (SDO client) sending a message to the network is 603h. Although all nodes can see this message, all nodes except the target node will ignore the message. The target node knows that the message with ID 603h means that the message is for this node, which is an SDO request. The data field of the message will specify the index and sub-index of the object whose data the master node wants to access. Then, the target node responds with message ID 583h.
Process Data Object (PDO)
Process data represents data that can change over time, such as the input (ie, sensor) and output (ie, motor driver) of the node controller. Process data is also stored in the object dictionary. However, since SDO communication only allows access to one object dictionary index at a time, there may be a lot of overhead in accessing constantly changing data. In addition, the CANopen protocol requires nodes to be able to send their own data without polling by the CANopen master. Therefore, the method of transmitting process data using a communication method called " Process Data Object" (PDO) is also different .
There are two types of PDO: transmitting PDO (TPDO) and receiving PDO (RPDO). TPDO is the data from the node (generated), and RPDO is the data arriving at the node (consumed). In addition, PDO has two types of parameters: configuration parameters and mapping parameters. The part of the object dictionary reserved for PDO configuration and mapping information is the index 1400h-1BFFh.
The configuration parameters specify COB-ID, transmission type, inhibit time (TPDO only) and event timer, which will be explained in this section. There are multiple ways to initiate PDO transmission. These methods include event-driven, time-driven, individual polling and synchronous polling. The transmission type is specified in the configuration parameters of the PDO. In event-driven transmission, when the process data is changed, PDO transmission will be started. In time-driven transmission, PDO transmission occurs at fixed time intervals. In individual polling, PDO transmission is initiated using an unusual mechanism called remote request. In synchronous polling, the SYNC signal is used to initiate PDO transmission. The synchronization signal is often used as a global timer. For example, if the CANopen master sends a SYNC message, multiple nodes can be configured to view and respond to the SYNC. In this way, the master station can obtain "snapshots" of multiple process objects at the same time.
Overview of Network Management (NMT)
Network management services include the ability to change the status of slaves during initialization, before running, and between running and stopping. The NMT protocol allows the CANopen network to control the communication status of each node. The pre-operation state is mainly used to configure CANopen devices. Therefore, PDO communication is not allowed in the pre-operation state. PDO communication can be carried out in the operating state. In the stopped state, the node can only perform node protection or heartbeat, but cannot receive or transmit messages. Certain types of CANopen communication allow different states. For example, SDO is allowed in the pre-operation state, but PDO is not allowed. This is because SDO is usually used to initialize object dictionary parameters,
Guardian and Heartbeat
The CANopen specification requires that a node must use some method to check whether the node is "active". The two methods available are: node protection and heartbeat, the latter is the preferred method.
In the heartbeat protocol, the CANopen node periodically sends heartbeat messages, which make the CANopen master device or heartbeat user know that the node is still active. If the heartbeat message does not arrive within a certain period of time, the host can take specific measures. Such operations may be to reset the node or report an error to the operator. The heartbeat message is identified by CAN-ID 0x700 + node ID, where the first data byte is equal to 1110.
In the node protection protocol, the CANopen master polls the current status information of the slave node. If a node does not respond within a certain period of time, the master server will consider the node dead and will take action.
The heartbeat protocol is the preferred method because it has less overhead than node protection.
Urgent message
Each node in the CANopen network is assigned an emergency message (EMCY) to communicate the status of the node. Please note that heartbeat and node protection protocols are designed to communicate communication failures, while emergency messages are used to communicate errors within the node (ie, sensor failures). The EMCY message is identified by 80h COB-ID + node ID. The data part of the EMCY message contains information about the error that occurred.
Next I will talk about the combination of CANopen and IEC61499.