Abstract: With the advent of Industry 4.0, networking is an inevitable trend in the development of industrial products. This paper proposes a method for integrating multiple industrial buses (ETHERNETPowerlink, EtherCAT, CANOpen) into drives (such as servos and frequency converters), mainly solving the problems of multi-bus unification and multi-axis synchronization at the drive control level (such as PWM interrupts). Unlike methods that use multiple buses in parallel, this paper provides a unified architecture and interface based on IEC61800-7. The communication model of this architecture is divided into a physical layer, a protocol layer, an interface layer, and a drive application layer. The protocol layer is mainly based on the IEC61800-7-301 standard, which is a data exchange protocol based on an object dictionary and includes periodic data (PDO) and non-periodic data (SDO). The interface layer encapsulates the protocol layer, providing a unified function interface, object set, and object dictionary for drive-oriented applications, most importantly the synchronization interface for multi-axis drives. The drive application layer is used to implement the functions of the IEC61800-7-201 protocol and uses this protocol as the core of drive development, rather than just as a data interface. Then, this paper implements the integrated functionality of the aforementioned multi-industrial bus on the driver, which has high flexibility and scalability. Finally, the feasibility of the method and the synchronization performance of multi-axis are verified through experiments.
1 Introduction
Networking is one of the important directions for industrial development. The Industry 4.0 development strategy has placed higher demands on networked products. Networked drives, including networked servos and networked frequency converters, are an important direction for motion control development. They can improve system scalability, reduce wiring, and have the characteristics of high communication speed and large information capacity.
To unify industrial control networks, the IEC organization introduced the IEC 61158/ISASP 50.02 standard. However, due to market application and manufacturer promotion considerations, this standard did not provide a unified network standard, and the fourth edition limited it to 20 mainstream buses. Clearly, multiple network interfaces hindered the development of industrial motion control. On the one hand, drive manufacturers needed to support multiple bus interfaces, services, and support; on the other hand, controller manufacturers and system integrators had to consider how to integrate them, and even the same network interface could have different application layer control protocols. Therefore, the IEC 61800-7 standard was developed. This standard defines and describes the unified network mapping layer specification IEC 61800-7-300 and the application layer specification IEC 61800-7-200 for power drive systems in industrial automation, as shown in Figure 1.
This standard outlines four main application protocols: Cia402, CIPMotion, PROFIdrive, and SERCOS. While not a single protocol, these protocols significantly facilitate interaction between drives, controllers, and system integrators. Among them, the Cia402 protocol, due to its history and openness, is widely used in motion controllers. Originally developed by the CAN in Automation (CiA) organization, it is one of many application protocols within CANOpen. Initially reliant on the CAN bus, it is now included and expanded by IEC 61800-7-201 to support industrial real-time Ethernet, such as ETHERNET Powerlink (hereinafter referred to as Powerlink) and EtherCAT. Network-based servos can be divided into two types of interfaces: traditional fieldbuses and the newer real-time Ethernet. Real-time Ethernet represents a recent development direction for fieldbuses and offers the best real-time performance among industrial Ethernet networks. In the field of motion control, Powerlink and EtherCAT have good market share and versatility.
Networked servos are highly dependent on the master station. Due to industry and market factors, various controllers are available on the market, making it difficult for a single bus to adapt to all applications. Therefore, driver products integrating Powerlink, EtherCAT, and CANOpen are better suited to meet market demands and are the focus of this study. Furthermore, traditional pulse-type servos are struggling to meet the requirements of modern control systems. For example, industrial robots with multiple servos have complex pulse wiring, making it impossible to transmit advanced information such as alarms and torque.
Currently, there are no domestically produced drivers that simultaneously integrate Powerlink, EtherCAT, and CANOpen. Foreign servo products, such as Lenz servos, use plug-in communication cards to support multiple buses. JuKyungLee presented an implementation based on IEC61800 and EtherCAT, where both the controller and driver are implemented according to standards, but only one real-time Ethernet application interface is provided. Ding Xinzong of Shandong University presented a servo based on the EtherMAC bus, which uses a custom, non-standardized control protocol. Some bus manufacturers have provided their own integration methods; some offer simple hardware and protocol integration (such as PORTING and IXXAT bus products), while others provide a unified interface for communication (such as Softing and HRS), but none provide a unified interface for driver applications. Furthermore, due to significant differences between buses, the configuration and usage process remains cumbersome. Typically, the implementation of a driver for an integrated bus uses a parallel approach, as shown in Figure 2. In the figure, API represents the function application interface.
The drawbacks of this solution are that each industrial bus protocol requires its own object dictionary and objects, protocol conversion, and its own protocol stack runtime interface. This makes the switching process complex, and it does not provide a dedicated synchronization interface for the driver.
Given the current lack of a unified interface architecture for drivers that simultaneously supports Powerlink, EtherCAT, and CANOpen buses, this article will describe a solution. This project's driver application layer will not perform Cia402 conversion; instead, it will directly use Cia402 as a development guide to plan the internal state machine and control interface, while providing protocols and interfaces for multi-bus and multi-axis synchronization. Since the standard only provides communication-level synchronization messages, this article elevates communication-level synchronization to the synchronization of driver control interrupts (PWM interrupts).
2 System Structure
This article will focus on the underlying communication of the driver package based on IEC61800-7, and provide a unified driver application layer interface. Its communication model architecture and hardware platform are shown below.
2.1 Communication Model Architecture
The driver's communication model is divided into a physical layer, a protocol layer, an interface layer, and a driver application layer. The overall architecture diagram is shown in Figure 3.
The physical layer is located at the bottom layer and includes Ethernet hardware interfaces (such as PHY chips) and CAN hardware interfaces, which are used to exchange bus data with the protocol stack via network cable hardware.
The protocol layer, located between the physical layer and the interface layer, includes the Powerlink, EtherCAT, and CANOpenCia301 protocol stacks. This layer packages upper-layer object sets according to their respective protocols and sends them to the physical layer, and unpacks the physical layer data and sends it to the interface layer; it also provides interfaces accessible to the interface layer. The three buses differ in message parsing, requiring some customization and unification for the driver. For example, EtherCAT supports multiple communication protocols, such as SERCOSonEtherCAT (SOE), EthernetOnEtherCAT, CANOpenonEtherCAT (COE), and FileOnEtherCAT (FOE). Here, Cia301 is chosen as the upper-layer communication protocol. IEC61800-7-301 provides a detailed description of the Cia301 mapping, including the object dictionary, periodic communication objects (PDOs), non-periodic communication objects (SDOs), and their link definitions, which form the basis for the unified application layer protocol Cia402.
The interface layer includes function interfaces, object collections, and an object dictionary. Function interfaces are used to set communication types, access the protocol layer for configuring communication parameters, access and manage the object dictionary, manage the protocol stack state, and handle synchronous and asynchronous interrupts. The object dictionary is mainly defined according to IEC61800-7-301 and IEC61800-7-201 standards.
The driver application layer, located above the interface layer, implements the IEC 61800-7-201 protocol. The unification of application protocols is the ultimate goal of driver integration with multiple industrial buses. IEC 61800-7-201 defines 10 operating modes and a core control state machine for the driver. The synchronous periodic position/speed/torque modes were added later; these modes are widely used due to the good synchronization of Powerlink and EtherCAT interfaces. The CANOpen interface, due to its communication speed and synchronization accuracy, is not suitable for the synchronous periodic mode, but can be replaced by the interpolated position mode. All modes are configured and used by the master station.
2.2 Platform Setup
This system is built on a ZynQ hardware platform, as shown in Figure 4. ZynQ is a chip integrating an ARM Cortex A9 and an FPGA, making it well-suited for applications with bus communication. The network hardware for Powerlink and EtherCAT can be unified (both support MII and RMII interfaces). All three bus slaves are implemented using FPGAs. Specifically, CANOpen uses only the Microblaze soft core within the FPGA, without utilizing FPGA resources; Powerlink uses the FPGA to implement both OpenHUB for forwarding Ethernet packets and OpenMAC for managing MAC, while also using the Microblaze soft core for packet parsing; EtherCATIP uses the FPGA to implement functions such as distributed clock (DC), address mapping management (FMMU), and synchronization manager (SM). Each bus needs to provide an AXI-compliant interface for use by the ARM.
The ARM Cortex A9 includes: a ServoApp for implementing the servo application; an Interface layer that encapsulates the isolated bus; and libraries for the three buses, such as CANOpenLib, which provide protocol stack processing and access to the FPGA interface. This solution integrates commonly used buses on a single chip and allows switching based on the field application.
3 Interface Definition
Based on the above technical solution, this section provides a detailed description of the interface layer implementation. The interface layer is an important component of this solution and can be divided into data interfaces and function interfaces.
3.1 Object Dictionary and Object Collection
The data interface includes the aforementioned object dictionary and object collection, where the object collection is an instance of the object dictionary. The object dictionary primarily includes object definitions, such as type, index, length, and read/write attributes. As mentioned earlier, it includes two main categories of object definitions: Cia301 and Cia402. The former is related to communication parameters and mappings, while the latter is related to driver applications. IEC61800-7-301 is based on Cia301 and addresses...
CANOpen, Powerlink, and EtherCAT buses each provide more specific mapping definitions, such as DeviceType and data type definitions. In this paper, when instantiating objects, objects in Cia301 are defined according to the bus type with the most sub-indexes; Cia402 objects can be directly unified. In Cia402, the master station determines which objects are mapped to PDOs and which can be accessed by SDOs.
The Cia402 object collection used by the servo driver is shown in Figure 5. It does not include the VelocityMode. The object dictionary is defined as a structure type, and its main large structures refer to the classification in Cia402.
in,
(1) DeviceControl contains control words and status words to control the main state machine of the device;
(2) CSP_Mode is a periodic position mode related object;
(3) CSV_Mode is an object related to the periodic speed mode;
(4) CST_Mode is an object related to periodic torque mode;
(5) FactorGroup refers to the conversion-related objects of the scaling factor;
(6) GeneralInfo is an object related to servo and motor information;
(7) HommingMode is an object related to the homming mode;
(8) InterpolatedPositionMode is an object related to the interpolation position mode;
(9) PorfilePositionMode is a contour position mode related object. Compared with periodic position, it also includes trajectory control and acceleration/deceleration control.
(10) PositionControlFunction is an internal position control function that detects and limits the position loop.
(11) ProfileTorqueMode is contour torque control, which controls the torque acceleration and deceleration curve;
(12) ProfileVelocityMode is for contour velocity control, which controls the velocity curve.
In addition, custom objects (starting at address 0x2000) need to be added in IEC61800-7-201, including communication type objects, system configuration objects, and synchronization delay compensation objects. The system configuration object mainly includes node number (only useful for Powerlink and CANOpen), software version number, VendorID, and ProductID.
3.2 Function Interface
The function interface encapsulates and manages the underlying protocol stack, shielding interfaces not used by the driver, such as Ethernet, SOE, FOE protocols, and EtherCAT's free-running mode. It also adds a driver synchronization interface. The interfaces used by the driver are summarized and unified (data parameters are omitted for simplicity).
(1) CommHwInit(): Responsible for setting the communication type, as well as setting and initializing the communication-related hardware;
(2) CommStackInit(): Responsible for protocol stack initialization, such as setting object dictionary, state machine, communication-related parameters, and server configuration parameters;
(3) CommProcess(): Maintains the protocol stack state, such as network state machine, SDO state machine, error handling, etc.;
(4) CommExit(): Exits the protocol and clears resources;
(5) CommSyncHdl(): Synchronization interrupt;
(6) CommSyncCompensation(): Informs the driver of synchronization compensation during the synchronization interrupt;
(7) CommPDOCallback(): Exchanges periodic control data that takes effect during synchronous interrupts;
(8) CommAsyncHdl(): Asynchronous interrupt, including asynchronous events, such as periodic control data ready and non-periodic SDO events;
(9) CommSDOCallback(): In asynchronous interrupts, callback after successful non-periodic control data exchange;
(10) CommState(): Get the communication status.
During implementation, CANOpen, Powerlink, and EtherCAT all need to implement the above interfaces according to their own protocols and hardware. A schematic diagram of the overall driver initialization process is shown in Figure 6. First, the communication type and related hardware interfaces are initialized through the CommHwInit interface, enabling synchronous and asynchronous interrupts. Next, the protocol stack-related parameters, states, and object dictionary are initialized through the CommStackInit function interface. Then, the CommProcess function interface periodically maintains the network state machine in the background and waits for interrupts. The master station can switch the slave station's network state machine and configure the set of objects to be used through data frames. If an application error specified by the protocol stack occurs, the erroneous data object (0x603F object) is fed back to the master station, and the slave station enters the corresponding Cia402 state; if it is a communication error, the network state machine exits the operation state; if it is an unrecoverable system error, the CommExit function interface needs to be called.
The driver needs to monitor the communication status through CommState. All three protocols have two core state machines: a network state machine and a Cia402 application state machine. Their network state machine is switched by the master station and consists of four main states, as shown in Table 1. The application layer interface states can be simplified to initialization state, pre-operation state, and operation state. The driver application layer periodically queries the status and performs corresponding operations. In the initialization state, the protocol stack is initialized; the driver application layer can perform its own initialization and wait for the protocol stack to return successfully. In the pre-operation state, the driver can be configured through non-periodic communication; in the operation state, application layer operations and driver operation can be performed. If a communication error occurs, and the driver is in the operation state, the protocol layer switches to a non-operation state; if the driver application layer detects the change, it enters the error state of the application state machine. The SDO state machine and error handling retain the original processing methods of each protocol stack, but need to provide the driver application layer with events and information indicating the completion of object operations.
3.3 Synchronization and Interruption Handling
When communicating across multiple axes, data synchronization is required at the communication layer, followed by synchronizing the PWM output with the communication. As shown in Figure 7, communication interrupts typically include two interrupts: a synchronous interrupt and an asynchronous interrupt. The PWM interrupt is the core interrupt for servo motor control, with the highest priority and shortest cycle, such as 50µs. The communication synchronization interrupt has a longer cycle, lower priority, and a longer cycle, such as 1ms. The synchronization interrupt is used to synchronize data across slave stations. For Powerlink and CANOpen buses, this signal is generated by synchronization data packets (SOC messages in Powerlink and Sync messages in CANOpen). For EtherCAT buses, it is generated by a distributed clock DC, which is adjusted by timestamped messages. The synchronization accuracy of the Powerlink and EtherCAT communication layers is <1µs.
Asynchronous interrupts are mainly triggered by certain events. Powerlink and EtherCAT can be flexibly configured. Here, it is configured as a typical event of receiving data, that is, receiving periodic data triggers an asynchronous interrupt.
The handling of interrupt functions at the interface layer is consistent across the three buses. When the master station sends data, the slave station receives the data in the asynchronous interrupt. If it is periodic data (RxPDO), it is placed in the application layer buffer; otherwise, it provides non-periodic control data (SDO) and a callback interface to the driver application layer, informing it that the asynchronous data is ready. When the synchronous interrupt arrives, the data is copied to the application layer and takes effect. When the slave station sends data, the feedback data is copied to the protocol stack buffer in the synchronous interrupt. When the protocol stack sends the next data frame (in EtherCAT, the uplink and downlink data frames can be the same frame), it reads the periodic feedback data from the protocol stack buffer, encapsulates it, and sends it to the network hardware interface.
The driver application layer doesn't need to know too many communication details; it only needs to call the above interface when needed. An interrupt diagram illustrating the implementation is shown in Figure 8.
When the synchronization interrupt signal arrives, the system enters the interrupt handling function CommSyncHdl. To account for the scenario where the communication interrupt is interrupted by the PWM interrupt, the driver application layer needs to read the synchronization compensation value through CommSyncCompensation. This compensation value is the difference between the time the protocol stack receives the synchronization interrupt signal and the time the driver enters the synchronization interrupt service routine. The driver application layer uses this compensation value to adjust the PWM period so that the synchronization interrupt occurs in the middle of the PWM interrupt's idle time, and that the PWM interrupt marks the start of the entire current loop. Thus, the synchronization of multiple axes within the network depends on the synchronization of the PWM interrupt, which in turn is synchronized with the communication synchronization interrupt function, thereby achieving synchronized execution of multiple axes. In the diagram, CommPDOCallBack is responsible for synchronous data exchange.
Asynchronous interrupts have a lower priority than synchronous interrupts. When an asynchronous interrupt data frame arrives, the asynchronous interrupt handling function CommAsyncHdl is entered to handle asynchronous events, including asynchronous data reception start and reception completion events. When asynchronous data reception is complete, the Cia402 object is modified, and CommSDOCallback is called to notify the driver application layer.
3.4 Experiment
Platform setup: B&R controller (Powerlink master station), Beckhoff controller (EtherCAT master station), and Delta controller (CANOpen master station) are connected to 6 servos respectively, and each servo outputs the PWM interrupt synchronously from the IO1 pin.
Taking the Beckhoff controller as an example, during the testing process, an oscilloscope probe was used to test the IO1 output of the servo motors to observe the servo PWM synchronization deviation. Figures 9 and 10 show the test waveforms for 2 and 6 servo drivers, respectively. The upper part of each figure shows the PWM interrupt, with a high level indicating the PWM interrupt is entered and processed. The lower part shows the amplified image of the rising edge. It can be seen that the PWM synchronization levels are ±200ns and ±800ns, respectively. The testing process for the Powerlink bus and CANopen bus is the same.
The summarized test data is shown in Table 2:
The test data shows that, under this method, the synchronization accuracy of the three integrated industrial buses reaches a very high level, fully meeting the requirements of industrial-grade control and also suitable for 6-axis industrial robot applications.
4. Conclusion
In the context of industrial networking, the coexistence of multiple buses increases the resistance to driver networking, making the integration of multiple buses into a single driver essential. This paper integrates the commonly used Powerlink bus, EtherCAT bus, and CANOpen bus into a servo driver, enabling a single product to handle multiple master controllers. Each bus can leverage its respective advantages in specific applications, thus facilitating the completion of control tasks more conveniently.
This paper presents a unified architecture based on IEC61800-7-301 and IEC61800-7-201. It also verifies the feasibility of servo state machines and various control modes implemented based on these standards. Finally, experiments demonstrate that this driver-oriented architecture has excellent PWM synchronization performance. This technical solution has the following advantages:
(1) A unified object dictionary and objects are used for Powerlink bus, EtherCAT bus and CANOpen bus, and a unified function interface is provided to isolate the communication protocol;
(2) This enables the driver to support multiple industrial buses simultaneously, expanding the application areas and accelerating the development process while reducing development costs;
(3) Based on the standard development driver, the driver application layer directly adopts Cia402 objects and state machines as its core structure, which greatly reduces the development and maintenance costs. It can perform various applications of the driver according to the Cia402 application standard, such as the operation of state machine, position, speed and torque modes, instead of just serving as the driver's data interface, thus avoiding the trouble of protocol conversion and achieving higher transmission efficiency.
(4) The application layer for drivers provides function interfaces for synchronous interrupt handling and asynchronous interrupt handling, supporting the synchronization of multiple drivers;
(5) Unify the network hardware interfaces of Powerlink bus and EtherCAT bus and verify their feasibility. This allows for the reuse of hardware interfaces.
