Introduction to EtherCAT

With the NI 9144 expansion chassis and a set of industrial communication drivers, National Instruments has increased its offering of deterministic distributed I/O products and now supports an open, real-time Ethernet protocol called EtherCAT^®. This white paper covers the fundamentals of EtherCAT technology as it applies to NI products, including protocol basics, data transfers, and distributed clock synchronization.

Introduction

EtherCAT (Ethernet Control Automation Technology) is a high-performance, industrial communication protocol for deterministic Ethernet. It extends the IEEE 802.3 Ethernet standard to transfer data with predictable timing and precise synchronization. This open standard has been published as part of the IEC 61158 and is commonly used in applications such as machine design and motion control. 

EtherCAT implements a master/slave architecture over standard Ethernet cabling. EtherCAT masters from National Instruments consist of real-time controllers with dual Ethernet ports such as NI CompactRIO and PXI. Each NI slave also contains two ports that permit daisy chaining from the master controller.  

Figure 1. EtherCAT master/slave architecture with NI hardware.

EtherCAT Protocol Basics

The EtherCAT protocol transports data directly within a standard Ethernet frame without changing its basic structure. When the master controller and slave devices are on the same subnet, the EtherCAT protocol merely replaces the Internet Protocol (IP) in the Ethernet frame. 

Figure 2. Ethernet frame structure with EtherCAT.

Data is communicated between master and slaves in the form of process data objects (PDOs). Each PDO has an address to one particular slave or multiple slaves, and this “data and address” combination (plus the working counter for validation) makes up an EtherCAT telegram. One Ethernet frame can contain multiple telegrams, and multiple frames may be necessary to hold all the telegrams needed for one control cycle.

Data Transfers

With some real-time protocols, the master controller sends a data packet and must wait for the process data to be interpreted and copied at every slave node. However, this method of determinism may be difficult to sustain because the master controller must add and manage a certain amount of processing time and jitter per slave.

EtherCAT technology overcomes these system limitations by processing each Ethernet frame on the fly. For example, suppose the Ethernet frame is a moving train, and the EtherCAT telegrams are train cars. The bits of PDO data are people in the cars who can be extracted or inserted by the appropriate slaves. The whole “train” passes through all the slave devices without stopping, and the end slave sends it back through all the slaves again.  

Figure 3. EtherCAT data transfers.

In the same way, when device 1 encounters the Ethernet packet sent by the master, it automatically begins streaming the packet to device 2, all while reading and writing to the packet with only a few nanoseconds delay. Because the packet continues passing from slave to slave to slave, it could exist in multiple devices at the same time.

What does this mean practically? Let’s say you have 50 slave devices, and different data is sent to each slave. For nonEtherCAT implementations, this may mean sending out 50 different packets. For EtherCAT, one long packet that touches all slaves is sent, and the packet contains 50 devices worth of data. However, if all the slaves need to receive the same data, one short packet is sent, and the slaves all look at the same part of the packet as it is streaming through, optimizing the data transfer speed and bandwidth.

High-Speed Performance

EtherCAT is designed for reaching high performance and high channel count for single-point applications such as control. Because slave reads and writes can occur in the same frame, the EtherCAT telegram structure is optimized for decentralized I/O. Plus, the complete protocol processing takes place within hardware and is thus independent of the run-time of protocol stacks, CPU performance, or software implementation. For example, with direct memory access (DMA), data can be transferred between the network card and the master processor or slave I/O with minimal CPU usage. Also, each NI slave device uses several fieldbus memory management units (FMMUs) dedicated to PDO transfers and address examination. The slaves, not the master, are in charge of mapping the appropriate telegrams to themselves, so this reduces the complexity of the master and frees its resources.

Timing and Synchronization

Another factor in achieving deterministic networks is the master controller’s responsibility to synchronize all slave devices with the same time using distributed clocks. Out of all the slave devices, one of them must contain the master clock that synchronizes the other slave devices’ clocks. For NI implementation, the first slave device is designated with the master clock, and the master controller sends a special synchronization telegram to read the master clock in every scan cycle. This telegram then updates and realigns the clocks on all other slave devices to prevent drifting.

Accurate synchronization is particularly important in cases where widely distributed processes require simultaneous actions, such as coordinated motion between motion axes. NI uses timestamps to measure the time difference between the leaving and returning frame. In this way, propagation delay is calculated between nodes, and precise synchronization (less than 1 µs) can be achieved by the exact adjustment of distributed clocks.

Using NI Hardware for EtherCAT

National Instruments offers a variety of platforms that are compatible with deterministic distributed I/O over EtherCAT. For the master controller, you may use any CompactRIO controller with two Ethernet ports or PXI system with an NI PXI-8231/8232 Ethernet interface with the NI-Industrial Communications for EtherCAT software driver. Then you may daisy chain multiple NI 9144 slave chassis from the controller to expand your time-critical applications, all while maintaining hard determinism with minimal processor resources.

Figure 4. cRIO-9074 controller with NI 9144 slave chassis.

The NI 9144 is an 8-slot rugged chassis that works with more than 30 analog and digital C Series modules. These I/O modules provide direct connectivity with a wide variety of sensors and reusability with other NI hardware platforms. Best of all, the out-of-box experience has greatly minimized any configuration for the NI 9144 by automatically recognizing all connected slaves and their modules in LabVIEW 8.6 Real-Time. With LabVIEW, you have easy access to the physical channels using the click-and-drag I/O Variable, live test panels, and I/O forcing for troubleshooting. For more information on NI deterministic distributed I/O, reference the following links.

Related Links:
Building Real-Time Systems with Distributed I/O
NI 9144 Expansion Chassis Under the Hood

1 ratings | 5.00 out of 5

Read in English Chinese (Simplified) Chinese (Traditional) German Italian Japanese | Print

Reader Comments | Submit a comment »