Technical upgrade from CANopen to CANopen FD
[Guide]ON November 21, 2019, at the exhibition celebrating the 30th anniversary of SPS 2019, the CiA organization demonstrated the migration from classic CANopen to CANopen FD through a network connected by two bridges. So, what changes does the emergence of CANopen FD bring? This article focuses on the characteristics of CANopen FD.
This article briefly introduces CiA 1301-the technical upgrade from classic CANopen to CANopen FD.
On November 21, 2019, at the exhibition celebrating the 30th anniversary of SPS 2019, the CiA organization demonstrated the migration from classic CANopen to CANopen FD through a network connected by two bridges. So, what changes does the emergence of CANopen FD bring? This article focuses on the characteristics of CANopen FD.
Since the promulgation of the CAN 2.0 technical specification in 1991, CiA has been committed to the promotion of the CAN protocol, including the design of the CAN bottom layer (CAN data link layer, CAN physical layer) and the CAN application layer (CANopen). The CANopen protocol clearly specifies the specifications of its PDO, SDO, NMT network management and other protocols in CiA 301, and uses the classic CAN data link layer. In the SPS exhibition, CiA demonstrated the CANopen FD protocol specified in CiA 1301. Compared with CANopen using the classic CAN data link layer, the data segment provides 8-byte payload. CANopen FD is based on CAN FD, and the data segment payload is increased to 64 bytes, which solves the problem of insufficient data segment in some applications. .
Similarities of CANopen protocol upgrade to CANopen FD
1. NMT network management protocol
The Network Management System (NMT) is responsible for starting the network and monitoring equipment. Engineers designed the CANopen FD network management system as a master/slave system. Only one active NMT master is allowed in the CANopen FD network. All CANopen FD devices have the NMT slave function, and are started, monitored, and restarted by the NMT master, and are assigned to a unique node ID.
In order to facilitate the management of devices, all devices have an internal state machine built in, and the transition between states is triggered by internal events or externally from the host.
The NMT slave state machine is composed of an initialization state, a pre-operation state, an operation state and a stop state, and its state transition mode is shown in Figure 1.
Figure 1 Schematic diagram of NMT network management
The NMT command that controls the state of the device is sent through the CAN identifier with the highest priority. Once the CANopen FD device receives the NMT command to control the state of the device, it must perform a conversion. As shown in Figure 2, the NMT protocol is mapped to a single CAN FD data frame with a data length of two bytes. The first byte determines the command to be sent, that is, the command specifier; the second byte specifies the node ID of the CANopen FD device.
Figure 2 Schematic diagram of NMT protocol
2. Error control protocol
In the CANopen FD network, you can monitor whether the CANopen FD device is still in the network and in the expected NMT FSA state through the error control protocol (as shown in Figure 3 start protocol, Figure 4 heartbeat protocol), and it can also detect newly added network CANopen FD device. All CANopen FD devices are based on the same CAN FD information and have the CAN-ID700H+ node ID of the CANopen FD device.
Note: CANopen FD does not support CAN remote frame, so CANopen node/life protection is not supported.
Figure 3 Schematic diagram of the startup protocol
Figure 4 Schematic diagram of heartbeat protocol
3. Emergency communication object protocol (EMCY)
When an error occurs inside the CANopen FD device, the emergency error producer will send EMCY to trigger an interrupt alarm. EMCY will only be sent once every time an error event occurs, and it will be sent to all devices that support EMCY in a broadcast manner, so as to adjust for the error. When no new errors occur, EMCY messages will no longer be sent as shown in Figure 5.
Figure 5 Schematic diagram of emergency communication object protocol EMCY
4. SYNC synchronization protocol
Same as CANopen, in CANopen FD equipment, the SYNC synchronization protocol is periodically sent by the producer for network synchronization. All CANopenFD devices can be used as producers of SYNC. Normally, the SYNC protocol is used for bus load management. The SYNC message provides a 1-byte SYNC counter value. Each time SYNC is sent, the corresponding counter will increase by 1. At the same time, the transmission period of SYNC is configurable, the initial value of the counter is 1, and the maximum value can be configured in the data object synchronization counter overflow register (1019H), as shown in Figure 6.
Figure 6 Schematic diagram of SYNC synchronization protocol
5. Time stamp protocol
The time stamp protocol allows the CANopen FD system to adjust to a unique network time. Sent by the CANopen FD master device to synchronize the internal clocks of all slaves. The time stamp is mapped to a CAN single frame with a length of 6 bytes. As shown in Figure 7, the CAN frame has an identifier of 100h by default. This six-byte data provides “time” information, which is the number of milliseconds after midnight and the number of days since January 1, 1984.
Figure 7 Schematic diagram of timestamp protocol
Changes from CANopen to CANopen FD
1. USDO agreement
● USDO is used for configuration and diagnosis tasks in the CANopen FD system. However, process data can also be transmitted through USDO services. USDO has the following characteristics:
● USDO service can confirm communication between single or multiple USDO servers;
● USDO client can access all object dictionary entries in CANopen FD equipment;
● USDO can provide read and write access to one or several sub-indexes in the USDO server object dictionary;
● USDO has a routing function, which can realize data transmission on the boundary of the CANopen FD network;
● USDO client and USDO server can be connected to different CAN physical layers;
● Data content of any length can be transmitted between USDO client and USDO server.
As shown in Figure 8, it is the unicast and broadcast communication that USDO has confirmed.
Figure 8 USDO unicast and broadcast communication
The “Destination Address” of the USDO protocol determines whether USDO is connected in a point-to-point manner or communicates in a multi-channel or broadcast manner. The command specifier determines the type of USDO transmission. The session ID is used as the transaction number to enable the client to distinguish USDO accesses to the same USDO server. As in the traditional CANopen SDO, the index and sub-index identify the data elements accessed in the object dictionary of the USDO server. In addition to the classic SDO, USDO also describes the data to be transmitted in terms of size and data type, which enables the data receiver to perform consistency checks. As shown in Figure 9, to accelerate USDO protocol transmission.
Figure 9 Speeding up USDO protocol transmission
For longer data objects, such as domain data, which exceeds 7 bytes, the speed of USDO transmission is not very efficient. Similar to the CANopen protocol, in order to improve the efficiency of USDO transmission, the CANopen FD protocol introduces an extended USDO transmission method: block transmission. This USDO transmission method is more efficient and faster. The basic principle of this kind of block transmission is to divide the data into several single packets, and transmit these packets block by block in a continuous request or response. As shown in Figure 10, it is the USDO block transmission method.
Figure 10 USDO block transmission method
The USDO client informs the USDO server of the target index and sub-index, as well as the expected data type and length. After the USDO server confirms its request, it gives the maximum block size (the number of consecutive block messages) that it can handle. The USDO client will send out each segment of the first block, knowing that the server confirms the end of the reception.
2. PDO protocol
Process data objects (PDO) are used in CANopen FD to broadcast high-priority control and status information. A PDO is composed of a CAN data frame and can communicate up to 64 bytes of data. However, the data length of the CAN FD data frame is non-Linear from 8 bytes. Therefore, when the PDO producer uses the padding byte to fill the PDO to the next supported CAN FD frame length, the PDO consumer may receive more data than expected. As shown in Figure 11.
Figure 11 Schematic diagram of PDO protocol
CANopen FD and embedded network, industrial Internet of things
Nowadays, the industrial Internet of Things is gradually developing and becoming mature. Embedded is also developing into the integration of cloud application programs. The era of big data requires more data for more accurate and safe algorithm analysis. The bottom layer of CANopen FD provides a 64-byte payload based on CAN FD, which can better meet the security performance requirements of the big data era.
CANopen FD can better meet the development needs of the future industrial Internet. The important reason is the emergence of the new USDO protocol. Due to the flexible characteristics of USDO, the CANopen FD/IOT gateway can easily access any data in the network, and can connect and access remote network CANopen FD devices through the routing function.
CANopen FD relieves developers of the burden of dealing with specific details of CAN hardware, such as bit timing and acceptance filtering. CANopen FD provides a standardized communication object COB for configuration and network management data.
CANFDSM-100——Serial port to CANFD conversion module
In practical applications, engineers often use serial ports to send and receive data or debug. In this way, for the problem of CANopen FD equipment, we will need to implement serial port conversion to CANFD to help us better realize data transmission and conversion. As shown in Figure 12, it is a serial-to-CAN (FD) module CANFDSM-100 developed by Guangzhou Zhiyuan Electronics, with a built-in microprocessor. The module supports four modes: transparent conversion, transparent conversion with identifier, format conversion, and Modbus conversion. At the same time, the module integrates 1 CANFD interface and 1 UART interface. In CAN communication, it can be arbitrarily programmable between 40Kbps~1Mbps; in CANFD communication, it can be arbitrarily programmable between 1Mbps~5Mbps. Meet industrial requirements, support online firmware upgrades, etc.
Figure 12 Schematic diagram of CANFDSM-100
USBCANFD series CAN FD interface card
During the use of CANopen FD equipment, data analysis or troubleshooting is often carried out by capturing the underlying CAN FD messages. As shown in Figure 13 is the high-performance CANFD interface card developed by ZLG Zhiyuan Electronics, which integrates 1-2 CANFD interfaces. Each interface has an independent 2500VDC electrical isolation protection circuit to prevent the interface card from damage due to ground circulation and enhance the system’s Reliability for use in harsh environments. The PC is connected to the USBCANFD interface card through the USB2.0 port, so that it can send and receive data with the CAN(FD) network to form a CAN(FD)-bus control node.
Figure 13 Schematic diagram of USBCANFD-200U interface card
The Links: LTM150XH-T01 FF200R33KF2