High-Performance EtherCAT Master Station Solution Based on Xilinx FPGA

Image Source:Hongke Electronics

EtherCAT is an open real-time Ethernet communication protocol developed by Beckhoff Automation GmbH. EtherCAT features high performance, low cost, and ease of use, and is widely used in the industrial field.

The ZCU102 evaluation kit helps designers quickly start designs aimed at automotive, industrial, video, and communication applications. This kit features the Zynq® UltraScale+™ MPSoC device based on Xilinx 16nm FinFET+ programmable logic architecture, providing a quad-core ARM® Cortex®-A53, a dual-core Cortex-R5F real-time processor, and a Mali™-400 MP2 image processing unit. The ZCU102 supports all major peripherals and interfaces for various application developments.

The KPA EtherCAT master station is a stable quality EtherCAT protocol stack with high recognition and cost performance, offering significant reference value. This article will introduce the transplantation and testing of the KPA EtherCAT master station on the ZCU102 platform.

EtherCAT (Ethernet for Control Automation Technology) is a high-performance industrial communication protocol for deterministic Ethernet, extending the IEEE 802.3 Ethernet standard to provide predictable timing and high-precision synchronization in data transmission. This open standard is part of IEC 61158 and is commonly used in mechanical design and motion control applications.

The KPA EtherCAT master software provides four versions of the master protocol stack: Basic, Standard, Premium, and Extension, based on different functionalities. In addition to supporting the ETG1500 defined Class A and Class B master types, KPA also supports some extended features such as Data- and Frame-Logger, Access Rights, Multi Master, Cable Redundancy, Hot-Connect, and more.

It offers ready-made development kits based on various hardware platforms and OS, supporting mainstream hardware platforms such as SoC (ARM+FPGA), ARM, X86, and PowerPC, as well as Linux (Xenomai/RT-preempt), Windows (InTime/RTX), QNX, Ucos, and Vxworks. This is a master station solution that meets almost all current user master station development requirements.

The KPA master protocol stack adopts a modular architecture, allowing for the implementation of each specific project application. It enables the master station to expand freely to accommodate applications of different sizes, and to port different operating systems and a variety of hardware platforms. Each module can be customized or developed separately without compromising the integrity of other modules. The master station structure is as follows:

The main functional modules of KPA are:

(1) Application Layer: The application layer is responsible for interacting with various programming/configuration environments and with different applications or devices. It ensures smooth access to master station function functions at the application or process task end; interacts with the master station through Remote Procedure Calls services, providing TCP/IP and UDP connections, such as mailbox-related communication with slave devices via UDP.

(2) Mailbox Module: The core mailbox module of the EtherCAT master station utilizes different protocols to process Service Data Objects (SDP), data transmission, and data exchange. It supports mailbox services such as CoE, FoE, EoE, SoE, VoE, and AoE.

(3) Process Image Module: The Process Image (PI) address is derived from the EtherCAT Network Information (ENI) file, which can be automatically generated by the configuration tool KPA Studio. Accessing the process image from control/process tasks is executed by the master station interface.

(4) Distribution Clock: This module ensures that all EtherCAT devices (including the master and slaves) always share the same EtherCAT system time. This is achieved by compensating for compile and drift time.

(5) Frame Schedule Module: Different PDOs use different scanning cycles. In the KPA Studio configuration tool, users can individually define the scanning rate for each slave. The frame scheduling module manages EtherCAT frame rates and forwards them to the EtherCAT network driver.

(6) OSAL (Operating System Abstraction Layer) Module: This includes wrappers for functions related to the operating system, such as handling threads, timers, mutexes, etc.; it also includes network adapter driver modules: extracting the core of the master station stack from the underlying network implementation.

Unlike other Ethernet-based industrial interfaces, EtherCAT uses a hop-to-hop communication protocol: the data packet is common to all slave devices connected to the bus, and it is passed from one device to another. The master station is the manager, which cyclically creates data packets with read or write requests and sends them to the bus at strict time intervals. Each slave device can insert (write) or extract (read) data blocks explicitly addressed to it.

This function was originally designed to efficiently utilize bus throughput, but it is also very useful for fault tolerance: any device connected to the bus is fully aware of the activities of all slaves and can transparently obtain or sniff the data transmitted between the bus master and slaves. Users do not need to modify any slave devices, add any additional signals, or change the transmission protocol, and this function does not incur any cost (other than a smarter master device).

The KPA EtherCAT Master uses this edge effect to introduce another bus master (or multiple masters) into the bus. During normal operation, this redundant master station is passive, able to sniff data but not inject its own packets. The passive master is considered secondary, while the active master is considered primary. Since all auxiliary masters are consistent with bus activity, they can take over the primary master when the latter fails.

Additionally, to detect abnormal situations on the bus, auxiliary masters can operate without any dedicated control devices or additional signal lines. EtherCAT packets are sent periodically and strictly at time intervals. When a passive auxiliary master does not receive its expected packet, it knows that there is no master on the bus anymore. The redundant master can immediately take control and send its own packets without waiting for the current cycle to end. This packet will be correct and meaningful because the auxiliary master has been tracking all changes, becoming a replacement for the faulty master.

The EtherCAT configuration enabling master redundancy includes one active (master) master device and one or more passive (auxiliary) master devices. The master device may not be configured for Master Redundancy, but it is best to use KPA EtherCAT Master software to maximize the utility of this technology. The auxiliary master connects to the bus as a shadow agent. It sniffs the data packets in transit without any changes. At the same time, this master calculates the arrival time of each telegram and tracks the possible delays between the expected and actual arrival times.

The master station hardware mainly consists of three parts, as shown below: the ZCU102 master station development board and the extended FMC network card. The KPA MAC IP core constructs the FPGA network card on the PL side, and the FreeRTOS master can run on either the R5 CPU or the A53 CPU. Additionally, a PC is needed to input operating system commands via a serial terminal. The EtherCAT network diagnostic configuration tool, KPA EtherCAT Studio, connects to the ZCU102 master board via RPC services, enabling configuration of both the master and slave stations and generating network configuration files.

Hardware Development Board

Xilinx HW-Z1-ZCU102 revision1.1

EtherCAT Master Software Development Package

MDK_xilinx-2018.3_freertos_a53_trial_v2.4.48714.0-release.zip

HW_SAMPLE_xilinx-2018.3_freertos_a53_trial_v2.4.48714.0-release.zip

Software Compilation

Unzip MDK_xilinx-2018.3_freertos_a53_trial_v2.4.48714.0-release.zip into the mdk_a53 folder

Enter the \\mdk_a53\samples path and modify the corresponding sample program. Each different sample program contains different APIs and has different functionalities. Here, taking 24_DriveRotationCiA402 as an example, this is a simple program for running a single-axis servo. To adapt to the Maxon servo driver, the descriptions in the C file must remain consistent with the ENI file description. After modification, save it.

Go to \\mdk_a53 and open build.bat, modify the compiler path, which is the path where Xilinx SDK is installed.

Run cmd, enter this path, and run build.bat to compile all sample codes, including compiling sample 24, generating the 24_DriveRotationCiA402.elf file in \\build\samples path.

Creating the Running Program

Enter mdk_a53\externals\boot path, according to the readme file and 24_DriveRotationCiA402.bif file;

Copy the design_1_wrapper.bit() file generated by the vivado project from zcu102_freeRTOS into this path, overwriting the original bit file;

Copy fsbl.elf from zcu102_freertos\project_1\project_1.sdk\fsbl\Release into this path, overwriting the original fsbl.elf file;

Copy the generated 24_DriveRotationCiA402.elf from \\build\samples into this path;

Copy the generated ENI file (master.xml) into this path;

Open Xilinx XSCT tool and enter the \\externals\boot path to generate boot.bin.

Copy the boot.bin file to the SD card, set the development board to boot from the SD card, and power on to run.

Network Configuration:Beckhoff EK1100+EL1004+EL2004+EL6692 (60 bytes frame).

Running on R5 CP (x32) test data:

Running on A53 CPU (x64) test data:

For targeted analysis of Wireshark data packets, set the time display format as follows:

Use the command ecat.ado == 0x130 to filter out which packet the slave entered the op state at, here it is 33900, meaning that the packets before 33900 cannot be used to analyze the circle time, as PDO data/periodic data is only sent after the slave enters op.

Analyze periodic packets, noting that each periodic packet contains three sub-packets (logical addressing) and one DC-related ARMW command.

Filter out periodic packets using the command ecat.sub1.cmd == LRD && ecat.sub1.cnt == 0, filtering out sub-packet 1 as LRD and the counter value as 0 (indicating sent from the master station, not traversed the slave) periodic packets. Choose the triangle to sort the packets, which can be from small to large or from large to small, with the smallest cycle being 999.496us.