EtherCAT - the Ethernet Fieldbus.

This section provides an in-depth introduction into EtherCAT (Ethernet for Control Automation Technology), the Ethernet-based fieldbus system. EtherCAT sets new performance standards. Handling is straightforward and similar to a fieldbus, thanks to flexible topology and simple configuration. Moreover, since EtherCAT can be implemented very cost-effective, the system enables fieldbusses to be used in applications where fieldbus networking was not an option in the past.

 

1. Introduction

1.1 Ethernet and real-time capability

2. EtherCAT operating principle

3. EtherCAT features

3.1 Protocol
3.2 Topology
3.3 Distributed Clocks
3.4 Performance
3.5 Diagnosis
3.6 High availability
3.7 Safety over EtherCAT (FSoE)
3.8 EtherCAT instead of PCI
3.9 Device profiles
3.9.1 CAN application protocol over EtherCAT (CoE)
3.9.2 Servo drive profile according to IEC 61491 over EtherCAT (SoE)
3.10 Ethernet over EtherCAT (EoE)
3.11 File Access over EtherCAT (FoE)

4. Infrastructure costs

5. Implementation aspects

5.1 Master
5.1.1 Master implementation services
5.1.2 Master Sample Code
5.2 Slave
5.2.1 EtherCAT Slave Controller
5.2.2 Slave Evaluation Kit incl. Slave Sample Code

6. Summary

7. Literature

1. Introduction 

 

Fieldbusses have become an integrated component of automation technology. They have been tried and tested and are now widely established. It was fieldbus technology that enabled the wide-scale application of PC-based control systems. While the performance of controller CPUs - particularly for IPCs - is increasing rapidly, conventional fieldbus systems tend to represent "bottlenecks" that limit the performance control systems can achieve. An additional factor is the layered control architecture consisting of several subordinate (usually cyclic) systems: the actual control task, the fieldbus system and perhaps local expansion busses within the I/O system or simply the local firmware cycle in the peripheral device. Reaction times are typically 3-5 times higher than the controller cycle time - an unsatisfactory solution (see Fig. 1).


Figure 1: Response times of conventional fieldbus systems

Above the fieldbus system level, i.e. for networking controllers, Ethernet has already been the state of the art for some time. What is relatively new is its application at the drive or I/O level, i.e. in areas that were dominated by fieldbus systems in the past. The main requirements for this type of application are high real-time capability, suitability for small data quantities, and naturally cost-effectiveness. EtherCAT meets these requirements and at the same time makes internet technologies available at the I/O level.

1.1 Ethernet and real-time capability 

There are many different approaches that try and provide real-time capability for Ethernet: for example, the CSMA/CD media access procedure is disabled via higher level protocol layers and replaced by the time slice procedure or polling; other propositions use special switches that distribute Ethernet packets in a precisely controlled timely manner. Whilst these solutions may be able to transport data packets more or less quickly and accurately to the connected Ethernet nodes, the times required for the redirection to the outputs or drive controllers and for reading the input data strongly depend on the implementation.

If individual Ethernet frames are used for each device, the usable data rate is very low in principle: The shortest Ethernet frame is 84 bytes long (incl. inter-packet gap IPG). If, for example, a drive cyclically sends 4 bytes of actual value and status information and accordingly receives 4 bytes of command value and control word information, at 100% bus load (i.e. with infinitely short response time of the drive) a usable data rate of only 4/84= 4.8% is achieved. At an average response time of 10 µs, the rate drops to 1.9%. These limitations apply to all real-time Ethernet approaches that send an Ethernet frame to each device (or expect a frame from each device), irrespective of the protocols used within the Ethernet frame.

2. EtherCAT operating principle 

 

EtherCAT technology overcomes these inherent limitations of other Ethernet solutions: the Ethernet packet is no longer received, then interpreted and process data then copied at every device. The EtherCAT slave devices read the data addressed to them while the frame passes through the node. Similarly, input data is inserted while the telegram passes through (see Fig. 2). The frames are only delayed by a few nanoseconds.

Process data is inserted in telegrams
Figure 2: Process data is inserted in telegrams

Since an Ethernet frame comprises the data of many devices both in send and receive direction, the usable data rate increases to over 90%. The full-duplex features of 100BASE-TX are fully utilized, so that effective data rates of > 100 Mb/s (>90% of 2 x 100 Mb/s) can be achieved (see Fig. 3).


Figure 3: Comparison of Bandwidth Utilisation

The Ethernet protocol according to IEEE 802.3 remains intact right up to the individual device; no sub-bus is required. In order to meet the requirements of a modular device like an electronic terminal block, the physical layer in the coupling device can be converted from twisted pair or optical fibre to LVDS (alternative Ethernet physical layer, standardized in [4,5]). A modular device can thus be extended very cost-efficiently. Subsequent conversion from the backplane physical layer LVDS to the 100BASE-TX physical layer is possible at any time - as usual with Ethernet.

3. EtherCAT features 

 

3.1 Protocol 

The EtherCAT protocol is optimized for process data and is transported directly within the Ethernet frame thanks to a special Ethertype. It may consist of several EtherCAT telegrams, each serving a particular memory area of the logical process images that can be up to 4 gigabytes in size. The data sequence is independent of the physical order of the Ethernet terminals in the network; addressing can be in any order. Broadcast, Multicast and communication between slaves are possible. Direct Ethernet frame transfer is used in cases where maximum performance is required and the EtherCAT components are operated in the same subnet as the controller.

However, EtherCAT applications are not limited to single a subnet: EtherCAT UDP packages the EtherCAT protocol into UDP/IP datagrams (see Fig. 4). This enables any control with Ethernet protocol stack to address EtherCAT systems. Even communication across routers into other subnets is possible. In this variant, system performance obviously depends on the real-time characteristics of the control and its Ethernet protocol implementation. The response times of the EtherCAT network itself are hardly restricted at all: the UDP datagram only has to be unpacked in the first station.


Figure 4: EtherCAT: Standard Frames according to IEEE 802.3 [3]

In addition to data exchange according to the master/slave principle, EtherCAT is also very suitable for communication between controllers (master/master). Freely addressable network variables for process data and a variety of services for parameterization, diagnosis, programming and remote control cover a wide range of requirements. The data interfaces for master/slave and master/master communication are identical.

For slave to slave communication, two mechanisms are available. Upstream devices can communicate to downstream devices within the same cycle, and thus extremely fast. Since this method is topology dependent, it is particularly suitable for slave to slave communication relationships given by machine design - e.g. in printing or packaging applications. For freely configurable slave to slave communication, the second mechanism applies: the data is relayed by the master. Here two cycles are needed, but due to the extraordinary performance of EtherCAT this is still faster than any other approach.

EtherCAT only uses standard frames according to [3] - the frames are not shortened. EtherCAT frames can thus be sent from any Ethernet MAC, and standard tools (e.g. monitor) can be used.

3.2 Topology 

Line, tree or star: EtherCAT supports almost any topology (see Fig. 5). The bus or line structure known from the fieldbusses thus also becomes available for Ethernet, without the quantity limitations implied by cascaded switches or hubs.


Figure 5: Flexible Topology: Line, Tree or Star

Particularly useful for system wiring is the combination of line and branches or stubs: the required interfaces exist on many devices (e.g. on I/O modules); no additional switches are required. Naturally, the classic switch-based Ethernet star topology can also be used.

Wiring flexibility is further maximised through the choice of different cables. Flexible and inexpensive standard Ethernet patch cables transfer the signals in 100BASE-TX mode. Plastic optical fibres (POF) complement the system for special applications. The complete choice of Ethernet wiring - such as different optical fibres and copper cables - can be used in combination with switches or media converters.

The Fast Ethernet physics (100BASE-TX) enables a cable length of 100 m between two devices. Since up to 65535 devices can be connected, the size of the network is almost unlimited.

3.3. Distributed Clocks 

Accurate synchronization is particularly important in cases where spatially distributed processes require simultaneous actions. This may be the case, for example, in applications where several servo axes carry out coordinated movements simultaneously.

The most powerful approach for synchronization is the accurate alignment of distributed clocks, as described in the IEEE 1588 standard [6]. In contrast to fully synchronous communication, where synchronization quality suffers immediately in the event of a communication fault, distributed aligned clocks have a high degree of tolerance versus possible fault-related delays within the communication system.

With EtherCAT, the synchronization of the devices is fully based on a pure hardware machine. Since the communication utilizes a logical (and thanks to full-duplex Fast Ethernet also physical) ring structure, a timestamp can be sampled within each device for the incoming and the returning frame.With these timestamps the master can determine the propagation delay offset to the individual slave clocks simply and accurately. The Distributed Clocks are adjusted based on this value, which means that a very precise network-wide time base with a jitter of significantly less then 1 microsecond is available (see Fig. 6). External synchronization, e.g. across the plant, is then based on IEEE 1588.


Figure 6: Synchronicity and Simultaneousness: Scope view of
two distributed devices with 300 nodes and 120 m of cable between them

However, high-resolution Distributed Clocks are not only used for synchronization, but can also provide accurate information about the local timing of the data acquisition. For example, motion controllers typically calculate velocities from sequentially measured positions. Particularly with very short sampling times, even a small temporal jitter in the position measurement leads to large step changes in the computed velocity. With EtherCAT, timestamp data types are introduced as a logical extension. The high resolution system time is linked to the measured value, which is made possible by the large bandwidth offered by Ethernet.The accuracy of a velocity calculation then no longer depends on the jitter of the communication system. It is orders of magnitude better than that of measuring techniques based on jitter-free communication.

3.4 Performance 

EtherCAT reaches new dimensions in network performance. Thanks to hardware integration in the slave and direct memory access to the network controller in the master, the complete protocol processing takes place within hardware and is thus fully independent of the run-time of protocol stacks, CPU performance or software implementation. The update time for 1000 I/Os is only 30 µs - including I/O cycle time (see Table 1). Up to 1486 bytes of process data can be exchanged with a single Ethernet frame - this is equivalent to almost 12000 digital inputs and outputs. The transfer of this data quantity only takes 300 µs.


Table 1: EtherCAT Performance Overview

The communication with 100 servo axes is also extremely fast: every 100µs, all axes are provided with command values and control data and report their actual position and status. The distributed clock technique enables the axes to be synchronised with a deviation of significantly less than 1 microsecond. And even at this pace, there is more than sufficient bandwidth for asynchronous communications such as TCP/IP, parameter download or diagnostis data upload.

The extremely high performance of the EtherCAT technology enables control concepts that could not be realised with classic fieldbus systems. With EtherCAT, a communication technology is available that matches the superior computing capacity of modern Industrial PCs. The bus system is no longer the bottleneck of the control concept. Distributed I/Os are recorded faster than is possible with most local I/O interfaces. The EtherCAT technology principle is scalable and not bound to the baud rate of 100 MBaud - extension to Gigabit Ethernet is possible.

3.5 Diagnosis 

Experience with fieldbus systems shows that availability and commissioning times crucially depend on the diagnostic capability. Only faults that are detected quickly and accurately and located unambiguously can be rectified quickly. Therefore, special attention was paid to exemplary diagnostic features during the development of EtherCAT.

During commissioning, the actual configuration of the nodes (e.g. drives or I/O terminals) should be checked for consistency with the specified configuration. The topology should also match the configuration. Due to the built-in topology recognition down to the individual terminals, this verification can not only take place during system start-up, automatic reading in of the network is also possible (configuration upload).

Bit faults during the transfer are reliably detected through evaluation of the CRC checksum: The 32 bit CRC polynomial has a minimum hamming distance of 4. Apart from broken wire detection and localisation, the protocol, physical layer and topology of the EtherCAT system enable individual quality monitoring of each individual transmission segment. The automatic evaluation of the associated error counters enables precise localisation of critical network sections. Gradual or changing sources of error such as EMI influences, defective connectors or cable damage are detected and located, even if they do not yet overstrain the self healing capacity of the network.

3.6 High availability 

Increasing demands in terms of system availability are catered for with optional cable redundancy that enables devices to be changed without having to shut down the network. Adding redundancy is very inexpensive: the only additional hardware is another standard Ethernet port (no special card or interface) in the master device and the single cable that turns the line topology into the ring (see Fig. 7). Switchover in case of device or cable failure only takes one cycle, so even demanding motion control applications survive a cable failure without problems. EtherCAT also supports redundant masters with hot standby functionality. Since the EtherCAT slave controllers immediately return the frame automatically if an interruption is encountered, failure of a device does not lead to the complete network being shut down. Dragchain applications, for example, can thus be specifically configured as stubs in order to be prepared for cable break.


Figure 7: Low cost cable redundancy with standard slaves

3.7 Safety over EtherCAT 

In the interest of realizing safe data communication over EtherCAT, the Safety over EtherCAT protocol has been disclosed within the EtherCAT Technology Group. EtherCAT is used as a single-channel communication system for transferring safe and non-safe information. The transport medium is regarded as a "black channel" and not included in safety considerations (see Fig. 8). A safety frame containing the safe process data and the required data backup is included in the EtherCAT process data. This "container" is safely analyzed in the devices at the application level. Communication remains single-channel. This corresponds to Model A from the annex of pre-IEC 61784-3.


Figure 8: Safety over EtherCAT Software architecture with black channel approach

The Safety over EtherCAT protocol has been assessed by German Technical Inspection Agency (TÜV). It is certified as a protocol for transferring process data between Safety over EtherCAT devices up to SIL 3 according to IEC 61508. The implementation of the Safety over EtherCAT protocol in a device must meet the requirements of the safety target. The associated product-specific requirements must be taken into account.


Figure 9: Safety over EtherCAT System

The application in figure 9 utilizes the benefits of the technology. The safety components are deployed wherever they are required in the automation system. Scalable local input and output components can be used in the system. An additional input or output can be extended flexibly using safety and non-safety Bus Terminals as required. The safety logic is also embedded within the network strand. A standard PLC can thus continue dealing with control tasks without a safety extension. Safe input and output functions are linked in the local safety logic in the form of an intelligent, safe Bus Terminal. This saves the costs otherwise required for an expensive safety PLC and enables scaling of the logic according to the task at hand. Only the messages between the Safety over EtherCAT master and the allocated safe slaves are routed via the non-safe, standard PLC.

  • The protocol has no restrictions with regard to safe process data length, communication medium, or transfer rate.
  • EtherCAT is used as a "black channel", i.e. the communication system plays no part in the safety considerations.
  • The protocol has been specified and reviewed and meets the requirements of IEC 61508 SIL 3.
  • Products offering the Safety over EtherCAT protocol have been available since 2005.

3.8 EtherCAT instead of PCI 

With increasing miniaturisation of the PC-components, the physical size of Industrial PCs is increasingly determined by the number of required slots. The bandwidth of Fast Ethernet, together with the process data width of the EtherCAT communication hardware enables new directions: classic interfaces that are conventionally located in the IPC are transferred to intelligent EtherCAT interface terminals (see Fig. 10). Apart from the decentralised I/Os, drives and control units, complex systems such as fieldbus masters, fast serial interfaces, gateways and other communication interfaces can be addressed.


Figure 10: Decentralized Fieldbus Interfaces

Even further Ethernet devices without restriction on protocol variants can be connected via decentralised switchport devices. The central IPC becomes smaller and therefore more costeffective. One Ethernet interface is sufficient for the complete communication with the periphery (see Fig. 11).


Figure 11: EtherCAT leads to smaller Controllers

3.9 Device profiles 

The device profiles describe the application parameters and the functional behaviour of the devices including the device class-specific state machines. For many device classes, fieldbus technology already offers reliable device profiles, for example for I/O devices, drives or valves. Users are familiar with these profiles and the associated parameters and tools. No EtherCAT-specific device profiles have therefore been developed for these device classes. Instead, simple interfaces for existing device profiles are being offered. This greatly assists users and device manufacturers alike during the migration from the existing fieldbus to EtherCAT.

3.9.1 CAN application protocol over EtherCAT (CoE) 

CANopen®* device and application profiles are available for a wide range of device classes and applications, ranging from I/O components, drives, encoders, proportional valves and hydraulic controllers to application profiles for plastic or textile machinery, for example. EtherCAT can provide the same communication mechanisms as the familiar CANopen [7] mechanisms: object dictionary, PDO (process data objects) and SDO (service data objects) - even the network management is comparable. EtherCAT can thus be implemented with minimum effort on devices equipped with CANopen. Large parts of the CANopen firmware can be reused. Objects can optionally be expanded in order to account for the larger bandwidth offered by EtherCAT.

3.9.2 Servo drive profil according to IEC 61491 over EtherCAT (SoE) 

SERCOS interface™** is acknowledged and appreciated worldwide as a high-performance real-time communication interface, particularly for motion control applications. The SERCOS profile for servo drives and the communication technology are covered by the IEC 61800-7 standard. The mapping of this profile to EtherCAT is specified in part 3 [8]. The service channel, and therefore access to all parameters and functions residing in the drive, is based on the EtherCAT mailbox (see Fig. 12). Here too, the focus is on compatibility with the existing protocol (access to value, attribute, name, units etc. of the IDNs) and expandability with regard to data length limitation. The process data, with SERCOS in the form of AT and MDT data, are transferred using EtherCAT slave controller mechanisms. The mapping is similar to the SERCOS mapping. The EtherCAT slave state machine can also be mapped easily to the phases of the SERCOS protocol. EtherCAT provides advanced real-time Ethernet technology for this device profile, which is particularly widespread in CNC applications. The benefits of the device profile are combined with the benefits offered by EtherCAT. Distributed clocks ensure precise network-wide synchronisation. Optionally, the command position, speed or torque can be transferred. Depending on the implementation, it is even possible to continue using the same configuration tools for the drives.


Figure 12: Several Device Profiles and Protocols can co-exist side by side

3.10 Ethernet over EtherCAT (EoE) 

The EtherCAT technology is not only fully Ethernet-compatible, but also characterised by particular openness "by design": the protocol tolerates other Ethernet-based services and protocols on the same physical network - usually even with minimum loss of performance. There is no restriction on the type of Ethernet device that can be connected within the EtherCAT segment via a switch port. The Ethernet frames are tunneled via the EtherCAT protocol, which is the standard approach for internet applications (e.g. VPN, PPPoE (DSL) etc.). The EtherCAT network is fully transparent for the Ethernet device, and the real-time characteristics are not impaired (see Fig. 13).


Figure 13: Transparent for all Ethernet Protocols

EtherCAT devices can additionally feature other Ethernet protocols and thus act like a standard Ethernet device. The master acts like a layer 2 switch that redirects the frames to the respective devices according to the address information. All internet technologies can therefore also be used in the EtherCAT environment: integrated web server, e-mail, FTP transfer etc.

3.11 File Access over EtherCAT (FoE) 

This very simple protocol similar to TFTP enables access to any data structure in the device. Standardized firmware upload to devices is therefore possible, irrespective of whether or not they support TCP/IP.

4. Infrastructure Costs 

 

Since no hubs and switches are required for EtherCAT, costs associated with these devices including power supply, installation etc. are avoided. Standard Ethernet cables and standard low cost connectors are used, if the environmental conditions permit this. For environment requiring increased protection sealed connectors according to IEC standards are specified.

5. Implementation Aspects 

 

The EtherCAT Technology was developed with very low cost devices in mind, like I/O terminals, sensors, and embedded controllers. EtherCAT only uses standard Ethernet frames according to IEEE 802.3. These frames are sent by the master device, the slave devices extract and/or insert data on the fly. Thus EtherCAT uses standard Ethernet MACs, where they really make sense: in the master device. And EtherCAT slave controllers are used, where such dedicated chips really make sense: in the slave device, where they handle the process data protocol in hardware and provide maximum real time performance regardless of the local processing power or software quality.

5.1 Master 

EtherCAT communicates a maximum of 1486 Bytes of distributed process data with just one Ethernet frame. So unlike other solutions, where the master device in each network cycle has to process, send and receive frames for each node, EtherCAT systems typically only need one or two frames per cycle for the entire communication with all nodes. Therefore EtherCAT masters do not require a dedicated communication processor. The master functionality puts hardly any load on the host CPU which can handle this task easily besides processing the application program: so EtherCAT can be implemented without special and expensive active plug-in card by just using a passive NIC card or the on-board Ethernet MAC. Implementation of an EtherCAT master is very easy, particularly for small and medium-sized control systems and for clearly defined applications.

For example a PLC with a single process image: if it does not exceed the 1486 bytes, cyclic sending of a single Ethernet frame with the cycle time of the PLC is sufficient (see Fig. 14). Since the header does not change at run time, all which is required is a constant header to be added to the process image and the result to be transferred to the Ethernet controller.

The process image is already sorted, since with EtherCAT mapping does not occur in the master, but in the slaves - the peripheral devices insert their data at the respective points in the passing frame. This further unburdens the host CPU. It was found that an EtherCAT master entirely implemented in software on the host CPU uses less of its processing power than much slower fieldbus systems implemented with active plug-in cards - even servicing the DPRAM of the active card puts more load on the host.

System configuration tools - available from several manufacturers - provide the network and device parameters including the corresponding boot-up sequence in a standardized XML format.


Figure 14: Master-Implementation with one Process Image

5.1.1 Master implementation services 

EtherCAT masters have been implemented on a wide range of RTOS, including but not limited to: eCos, INtime, MICROWARE OS-9, MQX, On Time RTOS-32, Proconos OS, Real-Time Java, RT Kernel, RT-Linux, RTX, RTXC, RTAI Linux, PikeOS, Linux with RT-Preempt, QNX, VxWin + CeWin, VxWorks, Windows CE, Windows XP/XPE with CoDeSys SP RTE, Windows NT/NTE/2000/XP/XPE/Vista with TwinCAT RTE, Windows 7 and XENOMAI Linux.

Master stacks are available as open source projects, as sample code and as commercial software. Implementation services are also available from a variety of vendors and for a variety of hardware platforms. Information about this fast growing offering can be found within the Product section of the EtherCAT website [1].

5.1.2 Master Sample Code 

Another possibility to implement an EtherCAT master is to use sample code which is available for a nominal fee. The software is supplied as source code and comprises all EtherCAT master functions, including Ethernet over EtherCAT (see Fig. 15). All the developer has to do is adapt the code, which was created for Windows environments, to the target hardware and the RTOS used. This has already been done successfully for a number of systems.


Figure 15: Structure of Master Sample Code

5.2 Slave 

A cost-effective EtherCAT slave controller is used in the slave devices.With EtherCAT the slave does not need a microcontroller at all. Simple devices that get by with an I/O interface can be implemented only with the ESC and the underlying PHY, magnetics and the RJ45 connector. The process data interface (PDI) to the slave application is a 32-bit I/O interface. This slave without configurable parameters needs no software or mailbox protocol. The EtherCAT State Machine is handled in the ESC. The boot-up information for the ESC comes out of the EEPROM that also supports the identity information of the slave. More complex slaves that are configurable have a host CPU on board. This CPU is connected to the ESC with an 8-bit or 16-bit parallel interface or via a serial connection (SPI). The performance of the host CPU is determined by the slave application – the EtherCAT protocol software can be run additionally. The EtherCAT stack manages the EtherCAT state machine and the communication protocol: This means in general the CoE protocol and for supporting firmware download via FoE (File Access over EtherCAT). Optional the EoE protocol can be implemented.

5.2.1 EtherCAT Slave Controller 

Several Manufacturers provide EtherCAT slave controllers. Slave controller functionality can also be implemented very cost effectively on FPGAs, for which binary code is available as buy-out license.

The slave controllers typically feature an internal DPRAM and offer a range of interfaces for accessing this application memory:

  • The serial SPI (serial peripheral interface) is intended particularly for devices with small process data quantity, such as analog I/O modules, sensors, encoders or simple drives. This interface is typically used with 8Bit µControllers, such as Microchip PIC, DSPic, Intel 80C51 etc. (see Fig. 16)
  • The parallel 8/16-bit microcontroller interface corresponds to conventional interfaces for fieldbus controllers with DPRAM interface. It is particularly suitable for more complex devices with larger data volume. µControllers typically using this interface are e.g. Infineon 80C16x, Intel 80x86, Hitachi SH1, ST10, ARM or TI TMS320 Series (see also Fig. 16).
  • The 32-bit parallel I/O interface is suitable for the connection of up to 32 digital inputs/outputs, but also for simple sensors or actuators operating with 32 data bits. Such devices do not need a host CPU at all (see Fig. 17).


Figure 16: Slave Hardware: FPGA with Host CPU


Figure 17: Slave Hardware: FPGA with direct I/O

Latest information on the choice of EtherCAT Slave Controllers can be found on the EtherCAT website [1].

5.2.2 Slave Evaluation Kit 

The corresponding Slave Evaluation Kit from Beckhoff makes all these interfaces easily accessible. Since with EtherCAT powerful communication processors are unnecessary, the Slave Evaluation Kit contains an 8 bit µC which optionally can be used as host CPU. The kit comes with slave host software - the equivalent to a protocol stack - in source code (Slave Sample Code), and a reference master software package (TwinCAT).

6. Summary 

 

EtherCAT is characterised by outstanding performance, very simple wiring and openness for other protocols. EtherCAT sets new standards where conventional fieldbus systems reach their limits: 1000 I/Os in 30 µs, optionally twisted pair cable or optical fibre and, thanks to Ethernet and Internet technologies, optimum vertical integration. With EtherCAT, the costly Ethernet star topology can be replaced with a simple line structure - no expensive infrastructure components are required. Optionally, EtherCAT may also be wired in the classic way using switches, in order to integrate other Ethernet devices. Where other Real-time-Ethernet approaches require special connections in the controller, for EtherCAT very cost-effective standard Ethernet cards (NIC) are sufficient.

EtherCAT is versatile: Master to Slave, Slave to Slave and Master to Master Communication is supported (see Fig. 18). Safety over EtherCAT is available. EtherCAT makes Ethernet down to the I/O level technically feasible and economically sensible. Full Ethernet compatibility, internet technologies even in very simple devices, maximum utilisation of the large bandwidth offered by Ethernet, outstanding real-time characteristics at low costs are outstanding features of this network.


Figure 18: Versatile network architecture

7. Literature 

 

[1] EtherCAT Technology Group (ETG)
http://www.ethercat.org/
[2] IEC 61158-3/4/5/6-12 (Ed.1.0), Industrial communication networks – Fieldbus specifications – Part 3-12: Data-link layer service definition – Part 4-12: Data-link layer protocol specification – Part 5-12: Application layer service definition – Part 6-12: Application layer protocol specification – Type 12 elements (EtherCAT)
[3] IEEE 802.3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications
[4] IEEE 802.3ae-2002: CSMA/CD Access Method and Physical Layer Specifications: Media Access Control (MAC) Parameters, Physical Layers, and Management Parameters for 10 Gb/s Operation
[5] ANSI/TIA/EIA-644-A, Electrical Characteristics of Low Voltage Differential Signaling (LVDS) Interface Circuits
[6] IEEE 1588-2002: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
[7] EN 50325-4: Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces. Part 4: CANopen
[8] IEC 61800-7-301/304 (Ed.1.0), Adjustable speed electrical power drive systems – Part 7-301: Generic interface and use of profiles for power drive systems – Mapping of profile type 1 to network technologies – Part 7-304: Generic interface and use of profiles for power drive systems – Mapping of profile type 4 to network technologies
[9] SEMI E54.20: Standard for Sensor/Actuator Network Communications for EtherCAT.
http://www.semi.org/
[10] IEC 61784-2 (Ed.1.0), Industrial communication networks – Profiles – Part 2: Additional fieldbus profiles for real-time networks based on ISO/IEC 8802-3

* CANopen is a trademark of the CAN in Automation e.V.
** SERCOS interface is a trademark of the SERCOS International e.V.