Fig. 13 Cu2508 Downlink Delay - Beckhoff CU2508 Documentation

Product overview
• The CU2508 has an internal delaying data buffer for each port, due to the different transport speed
• TwinCAT sends the Gbit frames for X9 serially (one after another) via the GBIT/ESL connection. The
GBit frame lengths can be of a magnitude that is significant in the context of short TwinCAT cycle
times!
• If several tasks are to be processed in TwinCAT, by default TwinCAT processes them serially (one
after the other). As a result, the ESL frames are sent with a corresponding delay.
The "isolated core" setting in the RealTime tasks provides a remedy so that the tasks can be
processed in parallel.
• The EtherCAT frame length must also be taken into account.
Example: An EtherCAT system is installed at ports X1 and X2, each with an EL2202 as output
terminal. The edges are to be measured with an oscilloscope for demonstration purposes. In system
X1 the bit of the respective output terminal used is in a short 7 µs frame, whereas in system X2 it is in a
long 128 µs frame. This alone causes the signal to be output 121 µs later in system X2.
A remedy is provided by DistributedClocks, see above.
(The position of the output data in the EtherCAT frame is usually irrelevant since output data is only
output after the checksum procedure, once the frame has fully passed the output device.)
• Typical delays caused by the management of the CU2508 are as follows
◦ In the downlink
Gbit X9 to FastEthernet X1..4: tFE = 1 µs
Gbit X9 to FastEthernet X5..8: tFE = 1.6 µs
Fig. 13: CU2508 Downlink Delay
◦ In the uplink
FastEthernet X1..X4 to Gbit X9: tGE = 0.7 µs
FastEthernet X5..X8 to Gbit X9: tGE = 1.1 µs
18 Version: 2.6 Real-time Ethernet port multiplier