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, and 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 1000 distributed input/output (I/O) points every 30 µs to 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 user 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.
Avoiding complexity
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 behaviour 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. 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 the need to deal with complex mechanisms. The 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 behaviour 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 is no need to set addresses on each node manually, or ‘baptise’ 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 is also the same for all device implementations across the products from more than 3000 EtherCAT device manufacturers.
EtherCAT technology breaks the limits of ordinary Ethernet technologies
Through the ESC and EtherCAT technology, there is 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 fibre or low-voltage differential signalling (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 synchronisation and reduces the jitter – in the case of drives, the cyclic synchronous error – to values lower than 1 µs.
Link loss detection and behaviour 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 licence 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.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version