Tutorial: EtherCAT primer – real-time industrial Ethernet for automation
Author : Rolf Horn | Applications Engineer | Digi-Key Electronics
01 June 2021
EtherCAT logo courtesy of the ETG
The foundations of Ethernet for Control Automation Technology (EtherCAT) were established nearly 40 years ago. Today, the Ethernet-based fieldbus system is standardised in IEC 61158 and is indispensable in a wide array of advanced industrial automation applications. Here, Rolf Horn, Applications Engineer at electronic component distributor, Digi-Key Electronics outlines the origins, core elements, timeline & current status of the real-time industrial E
The full version of this tutorial was originally featured in the June 2021 issue of EPDT magazine [read the digital issue]. And sign up to receive your own copy each month.
In the mid-1980s, automation manufacturers saw the rise of the networking technology, Ethernet and wondered if it was possible to leverage its benefits on the factory floor. Some, having experience with PC-based control systems, realised Ethernet’s physical hardware wasn’t hardened for industrial applications. Even more problematic was how the TCP/IP protocol and computing power of the time were too slow for the most advanced automation. Plus, data on Ethernet wasn’t deterministic. On the other hand, there was an exponential increase in the number of installed nodes — and connecting Ethernet was so simple that, if its limitations were overcome, an Ethernet approach could provide a practical architecture far less expensive than existing fieldbuses.
Early origins & core elements of EtherCAT
One early improvement to Ethernet was ruggedising the RJ45 plug-to-blue-cable connection. For use in industrial settings, this connector needed to be a tough and watertight connection capable of withstanding abrasions, impacts and multiple flex cycles. Cable manufacturers that saw Ethernet, as an enabling technology, began introducing such connectors — at first, for Industrial Ethernet (IE) control based on the standard TCP/IP protocol and the Open Systems Interconnection (OSI) 7-layer standard already in use.
Such physical connections complemented new forms of industrial controls, with data-collection cards on their motherboards — capable of handling data and providing control signals for simple processes. It was a logical first step in the move towards more use of Ethernet in automation, and for events that were not time critical (or process variables such as temperature, flow and humidity, that changed fairly slowly), such arrangements worked just fine.
However, automation control based on PCs was still out of reach: packet collisions made timing inconsistent and tasks couldn’t be synchronised with the split-second timing needed for more advanced operations — such as high-speed production-line bottle inspection or flying-knife operations inside a packaging machine. Such automation demanded a new approach, and several manufacturers came through with various solutions. The most widely adopted of these was EtherCAT.
First released in 2003, EtherCAT had (and still has) some of the fastest cycle times of Ethernet-based communication options, so it quickly became a preferred networking and control architecture for factory automation. One caveat: getting the most out of EtherCAT (to satisfy industrial automation’s requirements for speed and determinism) necessitated that the bus be complemented by fast control hardware; which in many cases relies on application-specific integrated circuits or ASICs within the controls handling EtherCAT functionality.
Basic structure of EtherCAT for determinism
EtherCAT uses the telegram structure of Ethernet data to establish a primary (master control) and its relationship with secondary (node) sensors and actuators on the factory floor. Those small inexpensive ASICs reside in each node to boost the performance of this configuration.
Here’s how it works: a telegram travelling along EtherCAT’s ring topology starts at the primary controller and travels through all the nodes. At every node, there are instructions ready to be offloaded, as well as data packets ready to add their information to the telegram. Without slowing down as the telegram passes through the node, each node’s ASIC orchestrates a high-speed exchange of information and then the telegram speeds off to the next node. Once it’s made a complete round, everything is updated within the controller, and another data packet is sent down the track. This scheme is inherent to the EtherCAT structure and prevents packet collisions, while ensuring that data is instantly available to the controller at the end of every cycle. Only the primary (controller) is allowed to release a telegram.
This example uses a ring topology, but it is a full-duplex system, so if the last node in a segment is open, that node sends the packet back up the line to the primary.
To ensure deterministic data, EtherCAT uses a distributed clock. Here, the primary controller sends a packet to all nodes, which in response latch their internal clock twice — first when the packet is received and then again when it returns to the primary. Such a routine (which in fact can be repeated several times) provides a direct measurement of the propagation delay associated with each node. Then the resultant calculated delays are loaded into an offset clock. Finally, the primary sets the first node in the sequence as a reference clock for all the other nodes on the bus.
EtherCAT can be configured to update this delay periodically, or even with every cycle. The combination of rapid data cycle times and the distributed clock allows the whole system to operate with less than 0.1 msec of jitter at a data rate of 100 Mbit/sec, capable enough for most industrial tasks.
EtherCAT has another built-in time management feature as well. Certain sensors, actuators and systems are critically dependent on real-time control: servomotors, safety equipment and elevators are just a few examples. EtherCAT systems can be setup to support these components and systems by allowing the programming of the system’s primary controller to give preference to critical data. Less critical components then get fewer data requests and updates, while critical components get more frequent data requests and updates...
Read the full article in EPDT's June 2021 digital issue...
More information...
Contact Details and Archive...
