Principle of operation

There are many different approaches that try to provide real-time capability for Ethernet: for example, the CSMA/CD access procedure is disabled via higher level protocol layers and replaced by time slicing or polling. Other propositions use special switches that distribute Ethernet telegrams in a precisely controlled timely manner. While these solutions are able to transport data packets more or less quickly and accurately to the connected Ethernet node, bandwidth utilisation is very poor, particularly for typical automation devices, since even for very small data quantities a complete Ethernet frame has to be sent. Moreover, the times required for the redirection to the outputs or drive controllers and for reading the input data strongly depend on the implementation. A sub-bus is usually also required, particularly in modular I/O systems, which, like the Beckhoff K-bus, may be synchronised and fast, but nevertheless always adds small delays to the communication that cannot be avoided.

With EtherCAT technology, Beckhoff overcomes these system limitations of other Ethernet solutions: the process no longer involves consecutive steps for receiving and interpreting telegrams and copying the process data. In each device (down to the I/O terminals) the EtherCAT Slave Controller reads the data relevant for the device while the frame passes through it. Similarly, input data is inserted into the data stream on the fly. While the frames (delayed by only a few bit times) are already passed on, the slave recognises relevant commands and executes them accordingly. The process is hardware-implemented in the slave controller and is, therefore, independent of the protocol stack software run-times or the processor power. The last EtherCAT slave in the segment returns the fully processed frame, so that the first slave device forwards it to the master as a kind of response telegram.

From an Ethernet point of view, an EtherCAT bus segment is simply a single large Ethernet device that receives and sends Ethernet frames. However, the “device“ does not contain a single Ethernet controller with downstream microprocessor, but a large number of EtherCAT slaves. Like for any other Ethernet device, direct communication may be established without a switch, thereby creating a pure EtherCAT system.

Protocol processing completely in hardware

Protocol processing completely in hardware | Protocol ASICs flexibly configurable. Process interface from
2 bit to 64 kbyte.


Ethernet down to the terminal

The Ethernet protocol remains intact right down to the individual devices, i.e. down to the individual I/O terminals; no sub-bus is required. Only the physical layer is converted in the coupler from 100BASE-TX or -FX to E-bus, in order to meet the requirements of the electronic terminal block. The E-bus signal type (LVDS) within the terminal block is nothing proprietary, it is also used for 10 Gbit Ethernet. At the end of the terminal block, the physical bus characteristics are converted back to the 100BASE-TX standard.

The on-board Ethernet MAC is sufficient as hardware in the master device. DMA (direct memory access) is used for data transfer to the main memory. That means that the network data access burden is lifted from the CPU. The same principle is also used in the Beckhoff multiport cards, which bundle up to four Ethernet channels on one PCI slot.

EtherCAT Slave Controller (ESC)

EtherCAT Slave Controller (ESC) | EtherCAT is not only faster outside the I/O device, but also inside. Digital I/Os are directly operated by the EtherCAT Slave Controller, without delays through local firmware and independent of the installed μC performance.



The EtherCAT protocol is optimised for process data and is either transported directly in the Ethernet frame or packed into UDP/IP datagrams. The UDP version is used in situations where EtherCAT segments in other subnets are addressed via routers. Ethernet frames may contain several EtherCAT telegrams, with each telegram serving a particular memory area of the logical process image with an addressable size of up to 4 GB. The data sequence is independent of the physical order of the EtherCAT Terminals in the network; addressing can be in any order. Broadcast, Multicast and communication between slaves are possible.

The protocol can also handle parameter communication, which typically is acyclical. The structure and meaning of the parameters is specified via CANopen device profiles, which are available for a wide range of device classes and applications. EtherCAT also supports the servo profile according to IEC 61800-7-204. Under the name of SERCOS this profile is recognised and popular for Motion Control applications worldwide.

In addition to data exchange according to the master/slave principle, EtherCAT is also very suitable for communication between controllers (master/master). Freely addressable network variables for process data and a variety of services for parameterisation, diagnosis, programming and remote control cover a wide range of requirements. The data interfaces for master/slave and master/master communication are identical.

Protocol structure

Protocol structure | The process image allocation is freely configurable. Data are copied directly in the I/O terminal to the desired location within the process image: no additional mapping is required. There is a very large address space of 4 Gbytes.



EtherCAT reaches new dimensions in network performance. The update time for the data from 1,000 distributed inputs/outputs is only 30 µs – including terminal cycle time. Up to 1,486 byte of process data can be exchanged with a single Ethernet frame – this is equivalent to almost 12,000 digital inputs and outputs. The transfer of this data quantity only takes 300 µs.

The communication with 100 servo axes takes place every 100 µs. With this cycle time, all axes are provided with set values and control data and report their actual position and status. The distributed clock technique enables the axes to be synchronised with a jitter of significantly less than 1 microsecond.

The extremely high performance of the EtherCAT technology enables control concepts that could not be realised with classic fieldbus systems. Very fast control loops can thus also be closed via the bus. Functions that previously required dedicated local hardware support can now be mapped in software. The tremendous bandwidth enables status information to be transferred with each data item. With EtherCAT, a communication technology is available that matches the superior computing capacity of modern Industrial PCs. The bus system is no longer the “bottleneck” of the control concept. Distributed I/Os are recorded faster than is possible with most local I/O interfaces.

The benefits of this network performance also become apparent in smaller controllers with comparatively moderate computing capacity. The EtherCAT cycle is so fast that it can be executed between two control cycles. The controller thus always has the latest input data available; the outputs are addressed with minimum delay. The response behaviour of the controller is improved significantly without increasing the computing capacity itself.

The EtherCAT technology principle is scalable and not bound to the baud rate of 100 Mbaud – extension to Gbit Ethernet is possible.


EtherCAT instead of PCI

With increasing miniaturisation of the PC components, the physical size of Industrial PCs is increasingly determined by the number of required slots. The bandwidth of Fast Ethernet, together with the data width of the EtherCAT communication hardware (EtherCAT Slave Controller) opens up new opportunities: interfaces that are conventionally located in the IPC are transferred to intelligent interface terminals at the EtherCAT system. Apart from the decentralised I/Os, axes and control units, complex systems such as fieldbus masters, fast serial interfaces, gateways and other communication interfaces can be addressed via a single Ethernet port in the PC. Even further Ethernet devices without restriction on protocol variants can be connected via decentralised switch port terminals. The central IPC becomes smaller and therefore more cost-effective, one Ethernet interface is sufficient for the complete communication with the periphery.