In-depth discussion of the CANopen protocol for low-power electronic control

The client node plays a key role in monitoring the communication status of the associated server nodes in different operating states. This is achieved by implementing the NMT mechanism. Two different methods, heartbeat and node guard, enable the client node to evaluate the communication integrity of the server node. The TMCM-6212 uses heartbeat technology to verify that the communication is correct. Each node uses object 1017h to send a heartbeat signal at a user-configurable cyclic time interval (in milliseconds). This ensures that all nodes are active and can communicate.

Table 1 lists the combination of all communication objects used in different communication states. When the device enters the initialization state after power-on or reset, a startup message is generated. The device then transitions to the pre-operational state and is ready to perform the desired operations. In the pre-operational state, all nodes in the network can transmit all objects related to SDO, heartbeat/node guardian, emergency and time/synchronization. In the operational state, in addition to all objects available in the pre-operational state, PDO objects can be mapped. Finally, in the stopped state, the device disables the communication of all SDO and PDO objects and only allows the execution of NMT commands.

Table 1. Status configuration in NMT communication

Service Data Object: The SDO communication protocol is mainly used in the pre-operational state of the NMT state machine. It operates in a client-server configuration, where the client has access to all objects available in the object dictionary of all connected servers (nodes). In this protocol, the client always initiates a read/write transaction with the server, and the task completion is confirmed by the server. This process ensures that every transaction in SDO is confirmed.

Figure 2 shows a client-server based configuration of the SDO protocol in a multi-node network. Each node is assigned a channel through which it can communicate with the client. In this case, the Trinamic TMCM-6212 six-stepper motor driver/controller acts as a server, while the connected PC acts as a client, initiating read/write transactions with a specific node (NODE-1 in this case). Although all nodes will receive the SDO client message, only the target node will respond, while other servers will ignore the client request.

Service Data Object Datagram

Figure 2 shows the complete structure of an SDO datagram. The SDO header consists of a COB-ID (Connection Object ID), which is a unique number assigned to a specific task (e.g., read or write functions). Therefore, two COB-IDs are required for SDO communication. The first COB-ID represents the NODE-ID+function code of the client's upload/download request, i.e., 600h+NODE-ID. The second COB-ID (580h+NODE-ID) is used for the server's response.

The first byte in an SDO message is the descriptor, which is critical in determining the nature of the message, indicating whether the client intends to write (download) or read (upload) data, and also indicates any errors in the transaction through an abort message. The descriptor byte is divided into 8 bits, as shown in Figure 3. Bits 7-5 are the client command descriptor (CCS), which provides key information about the nature of the message. The client command descriptor has different configurations depending on the client's operation (such as read, write, segmented/fast transfer, or error in the transaction). In the server's response, the three bits of the descriptor (SCS, server command descriptor) are used to determine whether the transaction was successful. Table 2 lists the various combinations of CCS and SCS bits for different operations. Bit 4 in the descriptor datagram is a toggle bit used in data transfers exceeding four bytes. Bits 3-2 do not contain any data and are only valid if bits 0-1 are set. Bit 1 determines the type of message transmitted over the SDO channel, indicating whether it is a segmented or fast transfer. In the SDO datagram, as shown in Figure 3, the last four bytes are dedicated to the data that needs to be transmitted. If the data exceeds four bytes, it is sent in segments. On the other hand, if the SDO datagram contains complete data, it is considered a fast transfer. Therefore, bit 1 high indicates a fast transfer and bit 1 low indicates a segmented transfer. In a segmented transfer, the data is transmitted in packets. In response to the client's initial read/write request, the server provides the data size in the data field. Then, as each packet is transmitted to the client, the fourth bit (the toggle bit) starts to toggle. Finally, if bit 0 in the descriptor datagram is set, bits 3-2 indicate the data size, as previously described.

Table 2. CCS and SCS configuration

Bytes 2-3 and 4 in the SDO datagram correspond to the index and sub-index bytes, respectively, as shown in Figure 3. These bytes are used to access all objects available in the device object dictionary. The object dictionary contains all device parameters, allowing the user to configure the device's functionality based on the real-time application requirements. By profiling the device, we can achieve standardized behavior, whether it is a control device like a drive or a simple I/O device. As mentioned earlier, the last four bytes in the SDO datagram are dedicated to the data that needs to be transmitted through the SDO layer.

Once an error occurs, the SDO transfer is aborted and the reason for the transfer stop can be determined by referring to the error code explanation provided in the target device manual. In this case, the CCS bit has a value of 4, the index and sub-index specify the parameters affected in the device during the transfer, and the last four bytes indicate the error code.

Real-time communication analysis

This section uses the live communication log window of the machine in a pre-operational state to explain the SDO datagrams. The ADI Trinamic TMCM-6212 six-axis stepper motor driver/controller 4 is used in conjunction with the QSH4218-35-10-027 [5] stepper motor. For this setup, the maximum current of the motor (object 2003h) is set to 200. The upload and download transactions between the client and server are further explained using the highlighted messages in the software interface log window of the target setup, as shown in Figure 4.

Scenario 1: Download operation between client and server

Initiated by the client: 0x601: 2f 03 20 c8 00 00 00 (Figure 5).

The server responded: 0x581:60 03 20 00 00 00 00 (Figure 6).

In the operation shown in Figure 6, the combination of CCS and SCS bits shows the successful write operation of the client and the response of the server, which is also reflected in Table 2.

Scenario 2: Upload operation between client and server

Initiated by the client: 0x601:40 03 20 00 00 00 00 (Figure 7).

Server response: 0x581: 4f 03 20 00 c8 00 00 00 (Figure 8)

in conclusion

The combination of the CCS and SCS bits indicates a successful upload operation between the client and the server. The examples mentioned in this article can be generalized to other objects in the device object dictionary, helping us gain insight into the status of the machine. The main purpose of this demonstration is to help users interpret the communication log and monitor the status of the drive. Users can troubleshoot errors in real time and explore the advanced features of ADI Trinamic CANopen more efficiently. The integration of the CANopen protocol in ADI products brings flexibility to customers. Customers can integrate their own PLCs with ADI Trinamic modules to enable the development of multi-vendor systems. This interface is particularly valuable for customers engaged in complex application areas such as laboratory automation, robotics, liquid handling, semiconductor processing, etc.