From ASICs to microcontrollers, ESC chips boost performance and simplify commissioning, working in conjunction with unique diagnostics and development tools
At the heart of EtherCAT is the concept of the ESC. This is the chip-based solution for an EtherCAT field device; it could be an ASIC, an FPGA, a microprocessor or even a microcontroller. An ESC (short for EtherCAT Slave Controller) handles the reading and writing of cyclic (process) and acyclic (mailbox) data, as well as other background tasks necessary for a flexible fieldbus. There are many ESC options available from numerous vendors.
While EtherCAT network controllers do not require special hardware, having the ESC chip solution at the fieldbus device level is a huge benefit. Using an ASIC for EtherCAT in the field device allows processing to be done in hardware. As a result, network performance is independent of the performance of the microcontrollers in the devices and their ability to run complex software stacks. The real-time protocol handling is embedded in the chip and the field devices don’t have to manage a typical Ethernet connection.
With the EtherCAT functional principle implemented within the ESC, an EtherCAT system can update 1,000 distributed I/O points every 30 µs – that is, 30 millionths of a second! The unique “data exchange on the fly” that makes EtherCAT so special is defined in the ESC and requires nothing more than configuring a device to use the inherent mechanism that is built into the protocol and the specific chip.
Industrial Ethernet networking with no IP stack
None of this would be possible in a typical IP-based Ethernet network. It is not unusual for a fieldbus to have a chip interface at the field level. This is the historical basis for CANopen, DeviceNet, SERCOS, etc. In EtherCAT’s case, it saves the field device from having to provide enough processing to deal with IP-based Ethernet communications – a savings in processor cost, footprint, heat and power, not to mention the complexities of working with an IP stack.
EtherCAT uses the physical mechanisms of Ethernet without the overhead of having to implement a full seven-layer Open Systems Interconnection (OSI) model Ethernet stack at the field level. This greatly simplifies development for the device manufacturer and use for the end user of EtherCAT. To be clear, EtherCAT is not an IP-based protocol. EtherCAT is a fieldbus that uses standard IEEE 802.3 Ethernet without the complexities of having to configure and power a full Ethernet implementation.
Avoiding complexity
All ESCs behave the same way no matter the vendor of the EtherCAT chip. As such, both device developers and system users benefit from far less programming than is necessary with other Ethernet-based technologies. The functionality of an EtherCAT field device is built in. It only needs to be configured, not programmed from scratch. The user especially benefits from predictable system performance, since no software stacks with unknown timing behavior are involved in the cycle time.
The developer and user leverage EtherCAT devices in similar ways because the ESC provides a common interface. This also simplifies diagnostics because the same diagnostic techniques can be used for all EtherCAT devices. And because there is only one version of EtherCAT, nothing changes over time in using devices in the field and network configuration. Additionally, the operation of the EtherCAT protocol and ESCs allows for the simple addition of new devices without any concerns about adverse effects on the existing network.
The ESI, EtherCAT Slave Information
EtherCAT devices have an .xml file just like EDS files in CANopen, DeviceNet and EtherNet/IP or GSD files in PROIBUS and PROFINET. This EtherCAT Slave Information (ESI) file contains the data necessary to configure and use the device. So every EtherCAT device comes with an accompanying ESI file that describes the features and capabilities of the device. This means users can implement EtherCAT devices without needing to have intimate knowledge of the inner workings of the device or Ethernet.
Implementing an EtherCAT field device is a streamlined affair. Users need not deal with complex mechanisms, so they’re free to do what they are there for: to control a machine or process, and not be burdened with configuring and tuning a network. The ESI file defines how the ESC operates both with local I/O and with higher-level processors. The user does not have to worry about configuring the field device because it is accomplished with the common ESC behavior together with the ESI file.
Automatic Address Distribution
The ESC also masters the smart “auto-increment” commands on which the automatic address distribution of EtherCAT is based: using this feature at boot-up, the controller identifies the devices and their physical location in the network, compares the actual network configuration with the expected network configuration and assigns the addresses. This happens in the background and means that the user does not have to set addresses on each node manually, or “baptize” each node one by one as in other networks. With EtherCAT, users don’t have to handle MAC or IP addresses, configure subnet masks or any other IT-related settings – all due to the features provided by the ESCs.
ESC handles ‘Ethernet on the fly’
EtherCAT uses standard, unmodified Ethernet frames and uses them in a unique and efficient way. The ESC handles this complexity. And an important note: the methodology is the same for all device implementations, across the products offered by more than 3,000 EtherCAT device manufacturers.
EtherCAT technology breaks the limits of ordinary Ethernet solutions. Through the ESC and EtherCAT technology, we do not need to send and receive individual frames of Ethernet data, decode the data and then copy the process data to different devices. An EtherCAT field device reads the data as the frame passes through the device. Concurrently, output data from the field device is also written to the frame as it passes through the ESC. And since the field devices find the data via their position in the global process image, no device address needs to be carried in the frame - it is therefore addressed implicitly, not explicitly. This means that there is no "per-node" overhead in the frame, and process data communication becomes maximally efficient. Also, the same frame, or even the same area in the frame, is used for both input and output data. This virtually doubles the bandwidth. And the data reading/writing within the ESC itself is accomplished within several nanoseconds.
With the ESC, EtherCAT uses standard Ethernet full duplex technology and supports different topologies, including line, tree, drop and star. Its physical layer is 100BaseTX twisted-pair wire, 100BASE-FX fiber or LVDS (low voltage differential signaling).
One hundred servos with 8-byte I/O data each can be updated every 100 µs. At this rate, the system can read the actual positions and status and send new command values and control data. Distributed clocks technology takes care of precise synchronization and reduces the jitter – in the case of drives, the cyclic synchronous error – to values significantly lower than 1 µs.
Link loss detection and behavior if a physical link is missing
Another aspect of the ESC is using mechanisms inherent in Ethernet in a useful way. Ethernet communication is based on a carrier signal, the “link”, and the Frame Check Sequence (FCS) in the Ethernet frame is a CRC for detecting transmissions errors. EtherCAT and the ESC uses this in a very helpful way, exceeding the capabilities of standard Ethernet chips. Every port of an ESC, not just the device, counts both link loss and FCS errors. This allows one to determine and pinpoint occurrences even if intermittent.
Intermittent errors have always been a difficulty of any fieldbus. Because the ESC can count every single occurrence of an issue at every port, this provides an immense benefit to the determination of an issue. No guessing or mindless switching out of components is necessary. By far most issues are physical: wiring, a connector or something that can be stretched, pulled and generally mishandled.
Since all ESCs use the same basic mechanisms, one does not have to worry about which vendor is supplying the field device. They all operate the same way; no special software or troubleshooting tools are necessary. One must only understand how EtherCAT and the ESC operate to determine the source of an issue and quickly resolve it. Powerful diagnostics is a profound benefit to EtherCAT. And because of the universality of the ESC standard, the same tools and techniques can be used for all devices.
The SSC, Slave Stack Code
Yet another amazing thing about using the ESC is a software tool called the Slave Stack Code (SSC). The SSC implements the application layer above the ESC, which has no influence on the network performance. The ESC therefore requires very little processing power on the device’s processor. The SSC comes with a royalty-free license and provides ASCI C handling: device state, PDO (cyclic) access, SDO (acyclic) access, and interrupts. Any ETG member has access to the SSC to develop devices. This hugely simplifies development of an EtherCAT device.
The combination of ESC and SSC is completely unique within the domains of fieldbus communications for these reasons. There is no near equivalent for this unique combination of tools. This is just one more reason why EtherCAT still stands apart from the other fieldbus technologies in the market.
Want to learn more about how ESCs provide unmatched performance for your applications? Contact ETG or your local Beckhoff sales engineer today.
Bob Trask, P.E., is the North American Representative for the EtherCAT Technology Group.
A version of this article previously appeared in Control Engineering. It is republished here with permission from ETG.