Chip-based EtherCAT optimizes field communication
From ASICs to microcontrollers, ESC chips boost performance and simplify commissioning, in conjunction with diagnostics and development tools.
- Understand how the EtherCAT slave controller (ESC) is the chip-based solution for an EtherCAT field device.
- The data exchange is defined in the ESC and requires a configure device to use the inherent mechanism built into the protocol.
- EtherCAT uses unmodified Ethernet frames, and the ESC helps them operate efficiently.
The heart of EtherCAT is the concept of the EtherCAT slave controller (ESC), which is the chip-based part of an EtherCAT field device. The chip could be an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor or even a microcontroller. An ESC handles the reading and writing of cyclic (process) and acyclic (mailbox) data, as well as other background tasks necessary for a flexible fieldbus. Many ESC options are available from numerous vendors.
While EtherCAT network controllers do not require special hardware, having the ESC chip at the fieldbus device level can benefit the application. Using an ASIC for EtherCAT in the field device allows processing to be done in the chip. 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 in the ESC, an EtherCAT system can update 1,000 distributed input/output (I/O) points every 30 µs – 30 millionths of a second. The “data exchange on the fly” is defined in the ESC and only requires configuring a device to use the inherent mechanism built into the protocol and the specific chip.
No IP stack required for ESC
It is not unusual for a fieldbus to have a chip interface at the field level in a typical IP-based Ethernet network. This is the historical basis for CANopen, DeviceNet, SERCOS and others. 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 simplifies development for the device manufacturer and use of EtherCAT. However, 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.
All ESCs from all EtherCAT chip vendors behave the same way. As such, 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. System performance is predictable since no software stacks with unknown timing behavior are involved in the cycle time.
The developer and user leverages 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. Because there is only one version of EtherCAT, nothing changes over time in using devices in the field and network configuration. The operation of the EtherCAT protocol and ESCs also allows for the simple addition of new devices without concerns about adverse effects on the existing network.
The ESI, EtherCAT slave information
EtherCAT devices have an .xml file like EDS files in CANopen, DeviceNet and EtherNet/IP or GSD files in Profibus and Profinet. This EtherCAT slave information (ESI) file contains the data necessary to configure and use the device. 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 streamlined, without need not deal with complex mechanisms. Focus is on controlling a machine or process, without configuring and tuning a network. The ESI file defines how the ESC operates with local I/O and with higher-level processors. Field device configuration is accomplished with the common ESC behavior 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 locations in the network, compares the actual network configuration with the expected network configuration and assigns the addresses. This happens in the background and means there’s no need 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 because of ESC features.
Handling Ethernet on the fly, jitter
EtherCAT uses standard, unmodified Ethernet frames in a unique and efficient way. The ESC handles this complexity. The methodology also is the same for all device implementations, across the products from more than 3,000 EtherCAT device manufacturers.
EtherCAT technology breaks the limits of ordinary Ethernet technologies. Through the ESC and EtherCAT technology, there’s no need to send and receive individual frames of Ethernet data, decode the data and then copy the process data to different devices. Instead, an EtherCAT field device reads the data as the frame passes through the device. Output data from the field device also is written to the frame as it passes through the ESC. Because the field devices find the data via their positions in the global process image, no device address needs to be carried in the frame. This means 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 input and output data, which virtually doubles the bandwidth. The data reading/writing in the ESC 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 low voltage differential signaling (LVDS).
One hundred servos with 8-byte I/O data each can be updated every 100 µs. At this rate, the system can read the 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 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 cyclic redundancy check (CRC) for detecting transmissions errors. EtherCAT and the ESC use this in a very helpful way by exceeding the capabilities of standard Ethernet chips. Every port of an ESC counts link loss and FCS errors. This allows the user to determine and pinpoint occurrences even if intermittent.
Intermittent errors always have been a difficulty of any fieldbus. Because the ESC can count every occurrence of an issue at every port, this benefits 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 often mishandled.
Since all ESCs use the same basic mechanisms, one does not have to worry about which vendor supplies 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 resolve it.
The same tools and techniques can be used for all devices.
Slave stack code implementation
The slave stack code (SSC) implements the application layer above the ESC, which has no influence on the network performance. The ESC 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. This simplifies EtherCAT device development.
The combination of ESC and SSC is unique within the domains of fieldbus communications for these reasons and provides a unique combination of tools.
Robert B. Trask, P.E., is the North American Representative for the EtherCAT Technology Group, a CFE Media and Technology content partner. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, email@example.com.
Keywords: EtherCAT, Ethernet
Learn more about Ethernet at https://www.controleng.com/networking-and-security/ethernet/
Would less network programming help your Ethernet applications?