EtherCAT (Ethernet for Control Automation Technology) is a real-time Ethernet network developed by Beckhoff in 2003. The open standard is nowadays managed by the EtherCAT Technology Group (ETG), of which TRINAMIC Motion Control is a member. The original code by Beckhoff has remained unchanged, allowing for devices to communicate with each other using the master/slave principle – allowing for fast and dynamic communication structures. Because 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.
By using the original Beckhoff Slave Stack Code, Trinamic EtherCAT slave controllers and modules can effortlessly communicate with all other EtherCAT devices. Proven and certified by the EtherCAT foundation.
First, EtherCAT is incredibly fast. It sets new limits for real-time performance as it processes 1000 distributed I/O signals in 30 µs or 100 axes in 100 µs using twisted pair or fiber optic cables. This high speed makes EtherCAT 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 fieldbuses or wireless – and EtherCAT is one of the preferred technologies to do so. This means you have a wide offer of products to choose from communicating over the same interface using Beckhoff’s EtherCAT-IP.
Third, it’s build to last. Using proven Ethernet cables, EtherCAT terminals can operate within the -25°C to +60°C temperature range and Trinamic’s EtherCAT motion 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 TRINAMIC Motion Control develops easy to use products for motor and motion control ICs with EtherCAT protocol stacks.
EtherCAT masters are typically implemented as a software solution on standard or embedded computers with Ethernet MAC. Only a master can actively create a package with EtherCAT frames containing data of up to 1518 bytes per frame, and send it downstream to the slaves. Besides open EtherCAT master implementations like SOEM (Simple Open EtherCAT Master), over 100 companies provide a wide range of general purpose or specialized master EtherCAT products.
Other than in standard Ethernet devices, EtherCAT slaves process the frames on the fly with very tight timing requirements – they read the data and add their own information to that same frame as it is passing by. Doing so requires dedicated hardware in the EtherCAT slave controllers. No additional microcontroller is required for simple slave-devices, while more complex devices require a processor for protocol handling and application code. The unique way EtherCAT™ process frames makes it the fastest industrial Ethernet technology; no other technology can top EtherCAT’s bandwidth utilization or the corresponding performance.
The EtherCAT master writes a telegram and sends it downstream to all the slaves. As the data passes through each node in the network, the slave devices read the frame and add data to it, while at the same time checking if there is another slave device 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 slave will return the telegram back to the EtherCAT master following a predefined topology.
Because the data is processed on the fly, the frames don’t stop moving when a slave reads or adds data to the frame. Only hardware propagation delay times delay the data, with a 1µs port-to-port delay between received and transmitted frames. In general, there’s just a few nanoseconds delay between the master 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 EtherCAT master doesn’t have to make a new package for each individual slave in the network – saving time and eliminating the need for centralized I/Os.
Furthermore, each EtherCAT slave 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 also 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.
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 slave devices having one, two or more ports, various topologies are possible such as a simple line, star, or tree 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 slave controller in the segment of the network, or branch, detects automatically 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 slaves that receive the frames that are back on their way to the master will ignore it and simply let it pass through.
Whenever distributed applications require timely synchronized actions, like several servo axes starting or stopping at exactly the same time, EtherCAT’s distributed clock system comes into play.
The distributed clock mechanism synchronizes the clocks of all slave devices, leading to a deviation 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.