EtherCAT master in TwinCAT

The EtherCAT master as a virtual software device

EtherCAT as an Ethernet-based real-time fieldbus requires a physical Ethernet interface at the controller and a real-time trigger as required for connection with the I/O environment. It enables the EtherCAT master to communicate with the connected EtherCAT environment.

The EtherCAT master as a software device in TwinCAT:

• can assemble Ethernet telegrams with EtherCAT datagrams from the process data supplied by the PLC/NC/task and send them via the assigned Ethernet port.
• can unpack process data received from the I/O environment and return them to the tasks.
• deals with the construction of cyclic and acyclic telegrams.
• controls the distributed clock synchronization.
• analyses the diagnostic information of the EtherCAT slaves.
• carries out event-oriented diagnostics or responds to modified topologies.
• can only manage one EtherCAT system with up to 65,535 slaves and is linked with one Ethernet interface (“RJ45 port”) for this purpose. A second port can be allocated to the EtherCAT master for the purpose of cable redundancy.
• manages the communication with other EtherCAT masters in the same TwinCAT system, if several masters are present in the configuration.
• is the sole generator of EtherCAT telegrams in an EtherCAT system
• ....

EtherCAT communication consists of cyclic and acyclic Ethernet telegrams.

The cyclic telegrams form the normal process data and can usually not be modified during system runtime. A known configuration, i.e. the number of connected EtherCAT slaves, always results in the same minimum quantity of process data, which have to be sent with the master for cyclic communication between the devices. The cyclic (i.e. at constant intervals triggering task, e.g. a PLC task with a 10 ms runtime) triggers the communication with the EtherCAT field. Once the communication is complete the EtherCAT master returns the process data. On IPC/embedded systems TwinCAT generally operates with constant cycle times between 50 µs and > 100 ms. The arithmetic operations of the task must be completed within this cycle time. The high communication performance of EtherCAT (high 100 Mbit/s data throughput) enables the sent EtherCAT telegrams to return to the controller before the start of the next cycle, even in large configurations containing more than 1000 devices. Task execution and bus communication is therefore configured as a synchronous task in TwinCAT. A key factor for high-quality execution is low jitter, i.e. the tasks should be executed and restarted with high time precision.

In Fig. Synchronous execution of task and EtherCAT communication, the communication starts after the task. It is also possible to send frames at the same time as the task start time (“I/O at task begin”).

The acyclic telegrams are created by the EtherCAT master as required and sent or received in the intervals between the cyclic data. These telegrams are used for gathering diagnostic information and mailbox communication with individual devices (e.g. for firmware updates) or subordinate fieldbuses. Acyclic telegrams are sent from a pipeline without real-time claim in the order they are requested, depending on space, and are therefore also referred to as “queues frames”.

The TwinCAT System Manager also maps this time relationship in every configuration created. In Fig. Configuration-dependent time division in the System Manager, a 100 µs task can be seen that communicates with about 20 slaves and needs an Ethernet frame (red) with several datagrams for the cyclic communication.

The real-rime environment

The EtherCAT master itself “only” controls the construction and interpretation of the EtherCAT telegrams. A TwinCAT-based controller is based on cyclic execution of a task with constant repeat rate (cycle time). Usual cycle times in a TwinCAT environment range from 50 µs over 1 ms to several 100 ms. The cycle time is selected during configuration setup depending on the processing power of the controller, the bus devices, the executed programs, the application requirements and other factors.

Cyclically executed task may include NC calculations, PLC code, visualizations or R3 applications created and triggered by the customer. The tasks may have different cycle times, but have to be weighted in terms of priority. Higher priority tasks may interrupt/pause lower priority tasks. The lower priority task continues as soon as the priority list permits this. If more than one CPU core is used (only possible with TwinCAT 3), several tasks can be executed in parallel.

In a correctly dimensioned and parameterized TwinCAT system all configured tasks can be executed within the specified cycle time once during the whole cycle, even if they have different priorities. The settings automatically applied by the System Manager during configuration setup usually ensure stable operation of the configuration. The whole cycle is defined by the slowest task. For example, with a 1 ms and a 100 ms task on the same system, the fast task is executed 100 times before the slow task is executed.

The real-time characteristics of TwinCAT in Windows-based systems (2000, NT, XP, 7, CE; WES, WEC) ensure low jitter and therefore high constancy and exact timing, even with very short cycle times of 50 µs and without dedicated timing hardware.

In principle each task can have its own I/O image and therefore control its own fieldbus cycle and devices. In Fig. 2 Tasks with own Ethernet frames (Task 1 ms: "red" frame, task 10 ms: "yellow" frame), two tasks (1 + 10 ms) can be seen that each trigger their own I/O cycles and thus cause their own Ethernet frames.

The Ethernet interface

EtherCAT is currently (2011) standardized based on ISO/OSI layer 2 with Fast Ethernet = 100 Mbit/s down to the slave layer. The interface therefore has to support Fast Ethernet as a minimum. See also notes regarding EtherCAT infrastructure.

The Ethernet interface allocated to the EtherCAT master must meet the requirements of the application:

• external requirements: temperature, vibration, pull-out protection, buckling protection, contamination.
• An RJ45, M12 or M8 link is usually used for the connection to the controller/IPC.
• real-time capability
  The time-critical properties of the Ethernet interface must meet the requirements of the application and should not delay telegrams sent by the EtherCAT master at the correct time. This applies to the software implementation (driver, stack management) and the electronic configuration (PCI or USB connection, DMA, NDIS management, upstream switch).

EtherCAT Slaves

The following factors should be considered for the configuration:

• the properties of an EtherCAT slave are defined for the EtherCAT master in the device description file ESI (EtherCAT Slave Information). This XML file is provided by the respective device manufacturer.
  By default the TwinCAT System Manager looks for these ESI files under C:\TwinCAT\IO.
  An ESI file may contain several device descriptions and revisions.
• For EL/ES terminals connected in the terminal strand (LVDS configuration) the E-bus current consumption must be considered. The System Manager keeps track of the power demand specified in the ESI description and issues a warning if there is a risk of overload of the previous coupler. The usual capacity is 2 A. Negatives values in column “E-bus” are not allowed and may lead to errors that are difficult to reproduce.



• the maximum cable lengths and attenuation values between devices in the FX/TX layer (Ethernet cable, glass fiber, POF) specified in the physical layer may not be exceeded.
• the number and configuration of the EtherCAT slaves (max. 65,535) has influence on the cycle time of the EtherCAT telegrams.
• the functional reliability of the screen connection of the couplers/terminals and the earthing of the overall application must be ensured.
• supply lines/sensor cables may have to be screened separately.