A Deep Dive into the CANopen Protocol for Low-Power Industrial Motor Control

summary

Robust communication protocols and interfaces play an important role in industrial motor control applications. In industrial drive applications, when multiple processor elements are required to communicate continuously to complete complex tasks, CANopen® is favored by many engineers due to its easy integration, high configurability, and support for efficient and reliable real-time data exchange. This article explores CANopen from the perspective of low-power motor control applications.

Background on Controller Area Networks

Developed by Robert Bosch Gmbh in 1983, the Controller Area Network (CAN) is a highly robust communication protocol and interface that was created to overcome the limitations of traditional serial communication networks such as RS232, which cannot support real-time communication between multiple controllers. The automotive industry was the first to adopt CAN due to its requirement for multiple sensors to continuously and synchronously transmit data. CAN allows multiple nodes to communicate with each other using short messages, making it an ideal choice for automotive applications.

Over time, CAN has become increasingly popular across industries due to its proven robustness and many benefits. However, due to proprietary coding rules, integrating multiple devices from different vendors into a single system using the CAN protocol is challenging and sometimes even impossible. To overcome this limitation, the International User and Manufacturer Association of CAN in Automation (CiA) developed a higher-level protocol, CANopen.

The rest of this article will explore the CANopen protocol architecture and its use in controlling multi-axis motor drives. This article will delve into the intricacies of this high-level communication protocol and its impact on the world of motor and motion control. To provide readers with an understanding of the CANopen protocol, we will analyze the real-time communication logs of the ADI Trinamic™ TMCM-6212 multi-axis motor controller/driver module and the QSH4218-35-10-027 stepper motor. Specifically, we will focus on the network management (NMT) status and the client-server based CANopen protocol. In addition, we will use a case study to show how to interpret the communication logs and determine the status of the drive.

CANopen Architecture

This section explains the various application principles of the CANopen protocol, including NMT and SDO (Service Data Object).

Network Management: NMT is a key communication principle in CANopen that every CANopen compliant device must comply with. It operates as a state machine and plays an important role in coordinating applications within the CANopen framework.

Network Management State Machine Architecture: The NMT state machine is shown in Figure 1 and consists of three different states, as detailed below:

► Initialization state

►Pre-operation status

►Operation status

Figure 1. NMT state machine

The client node plays a key role in monitoring the communication status of the associated server nodes under different operating conditions. 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 out a heartbeat signal at a user-configurable cyclic time interval (in milliseconds). This ensures that all nodes are active and can communicate.

Initialize Pre-run Run Stop

start up •

SDO • •

Emergency • •

Sync/Time • •

Heartbeat/Node Guardian • • •

PDO (Process Data Object) •

Table 1. Status configuration in NMT communication

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.

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.

Figure 2. Multi-node SDO configuration

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.

Figure 3. SDO datagram structure

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 initial read/write request from the client, 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.

Operation Client Request (CCS) Server Response (SCS)

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 affected parameters 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.

Figure 4. CANopen IDE

Scenario 1: Download operation between client and server

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

Figure 5. The client initiates a download request