“On November 21, 2019, at the SPS 2019 exhibition celebrating the 30th anniversary, the CiA organization demonstrated the migration from classic CANopen to CANopen FD via a network connected by two bridges. So what changes does the emergence of CANopen FD bring? Here we focus on the characteristics of CANopen FD.
“
On November 21, 2019, at the SPS 2019 exhibition celebrating the 30th anniversary, the CiA organization demonstrated the migration from classic CANopen to CANopen FD via a network connected by two bridges. So what changes does the emergence of CANopen FD bring? Here we focus on the characteristics of CANopen FD.
Since the CAN 2.0 technical specification was promulgated 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 stipulates the specifications of its PDO, SDO, NMT network management and other protocols in CiA 301, and uses the classic CAN data link layer, while at 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 an 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 segments in some applications. .
1. The same thing about upgrading the CANopen protocol 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, restarted by the NMT master, and assigned to a unique node ID.
In order to facilitate the management of devices, all devices have a built-in internal state machine, and transitions between states are triggered by internal events or externally from the host.
NMT slave state machine consists of initialization state, pre-operation state, operation state and stop state, and its state transition mode is shown in Figure 1.
Figure 1 Schematic diagram of NMT network management
NMT commands that control the state of the device are sent with the CAN identifier with the highest priority. Once a CANopen FD device receives an NMT command that controls the state of the device, it must make a transition. As shown in Figure 2, the NMT protocol maps to a single CAN FD data frame with a data length of two bytes. The first byte determines the command to be issued, 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, it can be monitored 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, the start protocol, and the Figure 4 heartbeat protocol). 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 the CAN remote framework and therefore CANopen Node/Lifeguard.
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, an EMCY is sent by the emergency error producer, which triggers an interrupt alarm. Each time an error event occurs, EMCY will only be sent once, and it will be broadcast to all devices that support the EMCY function, and then adjust for the error. When no new error occurs, no EMCY message will 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 devices, the SYNC synchronization protocol is sent periodically by the producer for network synchronization. All CANopenFD devices can act as SYNC producers. Typically, the SYNC protocol is used for bus load management. The SYNC message provides a 1-byte SYNC counter value. Each time a SYNC is sent, the corresponding counter is incremented by 1. At the same time, the transmission cycle of SYNC can be configured, 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. Timestamp 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 timestamp is mapped to a single CAN frame of 6 bytes in length. As shown in Figure 7, by default, the CAN frame has the identifier 100h. This six-byte length of data provides “time” information, which is the number of milliseconds since midnight and the number of days since January 1, 1984.
Figure 7 Schematic diagram of timestamp protocol
2. Changes from CANopen to CANopen FD
1. USDO Agreement
USDO is used for configuration and diagnostic tasks in CANopen FD systems. However, process data can also be transferred via USDO services. USDO has the following characteristics:
l USDO service can confirm communication between single or multiple USDO servers;
l USDO clients can access all object dictionary entries in CANopen FD devices;
l USDO can provide read and write access to one or several sub-indexes in the USDO server object dictionary;
l USDO has routing function, which can realize data transmission on the boundary of CANopen FD network;
l USDO client and USDO server can be connected to different CAN physical layers;
l Data content of any length can be transmitted between the USDO client and the USDO server.
As shown in Figure 8, it is unicast and broadcast communication confirmed by USDO.
Figure 8 USDO unicast and broadcast communication
The USDO protocol “destination address” determines whether USDO communicates in a point-to-point connection or as a multiplex or broadcast. The command specifier determines the type of USDO transfer. The session ID is used as a transaction number, enabling clients to distinguish USDO accesses to the same USDO server. As in traditional CANopen SDO, indexes and sub-indexes identify data elements that are accessed in the USDO server’s object dictionary. In addition to classic SDO, USDO describes the data to be transferred by size and data type, which enables data recipients to perform consistency checks. As shown in Figure 9, in order to accelerate the USDO protocol transmission.
Figure 9 Speeding up USDO protocol transmission
For long data objects, such as data of type domain, which exceeds 7 bytes, the efficiency of accelerating USDO transmission is not very high. 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 transfer is to divide the data into several single packets, and transmit these packets block by block in successive requests or responses. As shown in Figure 10, it is the USDO block transmission method.
Figure 10 USDO block transfer 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 acknowledges its request, it gives the maximum block size (number of consecutive block messages) it can process. The USDO client will send each segment of the first block until the server confirms the end of reception.
2. PDO protocol
Process Data Objects (PDOs) are used in CANopen FD to broadcast high priority control and status information. A PDO consists of a CAN data frame and can communicate up to 64 bytes of data. However, the data length of CAN FD data frame is nonlinear from 8 bytes later. Therefore, when the PDO producer uses padding bytes to pad the PDO to the next supported CAN FD frame length, the consumer of the PDO may receive more data than expected. As shown in Figure 11.
Figure 11 Schematic diagram of PDO protocol
3. CANopen FD and Embedded Network, Industrial Internet of Things
Nowadays, the Industrial Internet of Things is gradually developing and rising, and slowly becoming mature. Embedded is also integrated into cloud application programs. In the era of big data, more data is needed for more accurate and secure algorithm analysis. The bottom layer of CANopen FD provides a payload of up to 64 bytes based on CAN FD, which can better meet the security performance requirements in the era of big data.
CANopen FD can better meet the development needs of the future industrial Internet, and the important reason is due to the emergence of the new USDO protocol. Due to the flexible nature 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 CAN hardware specific details, such as bit timing and acceptance filtering. CANopen FD provides a standardized communication object COB for configuration and network management data.
Four, CANFDSM-100 – serial port to CANFD conversion module
In practical applications, engineers often use serial ports to send and receive data or to debug. In this way, for the problem of CANopen FD equipment, we will need to implement serial port to CANFD to help us better realize data transmission and conversion. As shown in Figure 12, it is a serial port to CAN (FD) module CANFDSM-100 developed by Guangzhou Zhiyuan Electronics, with a built-in microprocessor. The module supports four modes: transparent conversion, transparent band identifier conversion, format conversion, and Modbus conversion. At the same time, the module integrates one CANFD interface and one 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-grade requirements, support online firmware upgrade, etc.
Figure 12 Schematic diagram of CANFDSM-100
Five, USBCANFD series CAN FD interface card
During the use of CANopen FD devices, data analysis or troubleshooting is often performed by grabbing the underlying CAN FD messages. As shown in Figure 13, it is a high-performance CANFD interface card developed by Guangzhou Zhiyuan Electronics Co., Ltd. It integrates 1-2 CANFD interfaces, and each interface has an independent 2500VDC electrical isolation protection circuit, so that the interface card can avoid damage due to ground circulation, enhance Reliability of the system 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: NL6448BC20-30 CM400HA-34H