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.
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 of delay. Because the packet continues passing from slave to slave to slave, it could be present in multiple devices at the same time.
What does this mean practically? Consider having 50 slave devices, and different data is sent to each slave. For non-EtherCAT implementations, this may mean sending 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, which optimizes the data transfer speed and bandwidth.
EtherCAT is designed to achieve high performance and high channel counts 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. 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.