An Introduction to EtherCAT Fieldbus
EtherCAT® (Ethernet for control automation technology) is real-time Ethernet at the I/O level. Its flexible topology allows for a high level of design freedom. On top of this, the EtherCAT fieldbus reduces the number of cables, which in turn reduces the risk of failure. This technology is widely adopted, becoming the open standard in automation by allowing for fast and dynamic communication structures. Since the data uses the same format as Ethernet, it can be connected directly to an Ethernet network. There’s no need for a specific router or switches.
Why Is the EtherCAT Fieldbus So Popular?
First, the EtherCAT fieldbus is incredibly fast. It sets new limits for real-time performance as it processes 1000 distributed I/O signals in 30 µs or 100 motor axes in 100 µs using twisted pair or fiber optic cables. This high speed makes the EtherCAT fieldbus ideal for automation, Industrial Internet of Things (IIoT), and other applications requiring real-time optimization.
Second, it’s a widely adopted open standard. More and more devices are getting connected—over field buses or wirelessly—and EtherCAT is one of the preferred technologies to do so. This means you have an expansive selection of products communicating over the same interface using Beckhoff Automation’s EtherCAT IP.
Third, it’s built to last. Using industry- standard Ethernet cables, EtherCAT terminals can operate within the –25°C to +60°C temperature range. ADI Trinamic™ EtherCAT controllers even meet the –40°C to 125°C automotive grade temperature specifications.
Investing in EtherCAT-compliant products means investing in the future—which is why ADI offers easy-to-use Trinamic products for motor and motion control ICs with EtherCAT protocol stacks.
The EtherCAT Main/Subnode Architecture
The primary EtherCAT controller is typically implemented as a software solution on standard or embedded computers with Ethernet MAC. Only a main (controller) node can actively create a package with EtherCAT frames containing data of up to 1518 bytes per frame and send it downstream to the subnodes. Besides open EtherCAT controller implementations like SOEM (Simple Open EtherCAT Master), over 100 companies provide a wide range of general-purpose or specialized EtherCAT controller products.
Unlike standard Ethernet devices, EtherCAT subnodes process the frames on-the-fly with very tight timing requirements by reading the data and adding their own information to that same frame as it passes through. Doing so requires dedicated hardware in the EtherCAT subnode controller (ESC). No additional microcontroller is required for lean subnode devices, while smarter and more complex devices require a processor for protocol handling and application code. This unique frame processing method makes EtherCAT the fastest Industrial Ethernet technology; no other technology can top its bandwidth utilization or the corresponding performance.
Functional Principle
The main EtherCAT node writes a telegram and sends it downstream to all the subnodes. As the data passes through each node in the network, the subnodes read the frame and add data to it, while at the same time checking if there is another subnode further down the stream. If the last node in a segment of the network detects an open port, it knows instantly that there are no more devices to send the telegrams to. Instead, the telegram is returned to the main EtherCAT node following a predefined topology.
As the EtherCAT main node processes the data on-the-fly, the frames don’t stop moving when a subnode reads or adds data to the frame. Only hardware propagation delay times cause delays with a 1 µs port-to-port delay between received and transmitted frames. In general, there are just a few nanoseconds of delay between the main node sending and receiving a telegram using Ethernet technology’s full duplex.
One single telegram can be used to communicate all the data that needs to be processed by the entire network—if the data is not too big. In other words, the main EtherCAT node doesn’t have to make a new package for each individual subnode, which saves time and eliminates the need for centralized I/Os.
Furthermore, each EtherCAT subnode communicates over hardware, not software. This leaves more computing power for real-time critical tasks and ensures stable performance and full compatibility with all other EtherCAT devices in the network. Switches are not needed when the network consists of solely EtherCAT devices, meaning there is no additional time delay and no additional cost to set up the infrastructure.
Topologies
EtherCAT is based on the Ethernet’s physical layer. Datagrams can be transferred using full duplex, meaning the connection is made via a switch with buffers at each port. With EtherCAT subnodes having one, two, or more ports, various topologies are possible such as a simple line, star, or tree-like topology. One single EtherCAT network can support up to 65,535 devices without placing restrictions on the topology.
As the physical layer is Ethernet, no special cables are required and there is no need for a crossover. This means you won’t need the extra connection in the center of a mesh as you can see depicted in the image. Establishing this cable redundancy minimizes the risk of failure.
Every EtherCAT subnode in the segment of the network, or branch, automatically detects if there is a downstream device and opens or closes the respective port. The last device in a chain returns the packet to the sender by closing its port. All other subnodes that receive the frames that are back on their way to the main node will ignore it and simply let it pass through.
Synchronization
Whenever distributed applications require timely synchronized actions, like several servo axes starting or stopping at exactly the same time, the EtherCAT distributed clock system comes into play.
The distributed clock mechanism synchronizes the clocks of all subnode devices, leading to a deviation of less than 1 µs. These synchronized clocks result in a network with axes synchronized to the microsecond, resulting in very low jitter, even if the communication cycle jitters are increased.
ADI Trinamic solutions use the original Beckhoff code, meaning controllers and modules can effortlessly communicate with all other EtherCAT devices. Proven and certified by the EtherCAT foundation.
