Technology

Introduction

As a port multiplier that is as transparent as possible, the CU2508 extends one Gbit Ethernet port on the controller to 8 FastEthernet ports in the field. It transports IEEE802.3 conformant Ethernet frames with arbitrary contents.

Each port of the CU2508 sends and receives FastEthernet frames (100 Mbit, 100BASE-TX) over up to 100 m of copper cable/RJ45. The CU2508 does not generate or process the contents of any frames itself; instead, it exclusively forwards frames sent to it by a special software driver to the field selectively via its 8 ports or forwards frames received from the field to the driver. The highly precise time information regarding when the frames are sent or received is thereby optional.

To this end, the CU2508 has at its disposal

• the Uplink Gbit Master Port (X9) to the driver in the controller, which needs a Gbit connection at the opposite end
• 8 equivalent 10/100 Mbit downlink ports (X1-X8) for the real-time traffic to the connected field devices

A CU2508 system thus consists of the CU2508 device and the CU2508 driver, e.g. integrated in TwinCAT 2.11R2 or TwinCAT 3.

The CU2508 system does not replace master implementations of Ethernet based field buses; instead, it tunnels specified data telegrams via the Gbit connection and then sends the frames at the specified time. It behaves transparently for the protocols fed across it, with exception of the EtherCAT protocol – in this case a CU2508 device is visible as the first slave in the configuration. Each materially existent I/O system on the field side must therefore match a logical master component in the controller.

Several CU2508s can be used in each TwinCAT system.

Downlink Port characteristics

The default setting of the CU2508 is optimized for use with EtherCAT downlinks, especially for EtherCAT IO redundancy operation. Therefore the 8 downlinks up to and including FW11 in the factory setting had the function to mirror incoming 100 Mbit frames back to the transmitter if the 1 GBit uplink is missing, called "Auto Link Close".

In non-EtherCAT operation this feature can be a problem and might disrupt the underlying network. Therefore it is deactivated globally for all downlink ports starting from FW12, so that in case of an uplink loss no return of incoming 100 Mbit frames takes place but the frames in the CU2508 "percolate". The electrical link is not changed.

ESL protocol

The software driver in the controller/control device/IPC forms the counterpart to the CU2508. It works on a Gbit port in the controller and "packs" the user data into the EtherCAT Switch Link Protocol (ESL) or unpacks the ESL protocol from the CU2508 and forwards the user data to the application. Therefore, no extra telegram containing control data is sent to/from the CU2508 for the handling of the user data; instead, the user data generated by user programs are supplemented by several bytes of control and information data for the connection between controller and CU2508.

The CU2508 driver is integrated in TwinCAT from version 2.11R2 onwards; pay attention to the specifications in the Technical data. The ESL protocol is disclosed, see the Description page. In addition, it has been included in the Wireshark-Installation since version 1.4.2.

EtherCAT systems and CU2508

The CU2508 can be used to operate several FastEthernet EtherCAT systems on one port of the IPC, i.e. quasi as port-multiplier. Hence the term "port multiplier”.

When operating several EtherCAT systems on the ports of a CU2508, temporal effects may occur that may be relevant for the application. Some explanations are provided below.

The CU2508 essentially supports the following three operation modes. To understand this, basic knowledge of the EtherCAT operation modes and synchronization methods is helpful.

1. Standard mode: no frame influence, no DistributedClocks
• The CU2508 forwards incoming frames via Gbit-ESL to the desired FastEthernet port, also in the opposite direction. There is no time control for the Ethernet frames.
• The EtherCAT slaves of the lower-level systems therefore operate on a frame-triggered basis (also referred to as FreeRun mode), and the output times are essentially dependent on frame delays/jitter, for example.
2. Time-controlled sending/time-stamped receiving: with frame influence, no DistributedClocks
• The CU2508 forwards incoming frames via Gbit-ESL to the desired FastEthernet port at the requested time. Time stamping takes place in the opposite direction. In other words, the Ethernet frames are time-controlled.
• Frame-triggered EtherCAT slaves thus operate with "low jitter", and "synchronized" between the EtherCAT systems.
• In order for the frames to be forwarded on a time-controlled basis, buffering in the CU2508 is required, which may cause considerable delays. For short cycle times the feasibility should be verified!
• This operation mode is not yet supported (as of 2019).
3. DistributedClocks mode, no frame influence
• The forwarded EtherCAT frames are subject to temporal influence by the transmitting IPC, the CU2508 and the EtherCAT slaves.
• The ports X1..8 are parameterized as DistributedClocks - ReferenceClocks
• Thus, the EtherCAT slaves of the lower-level systems that support DistributedClocks also operate DC-synchronously. This means that the input/output operations in these slaves can be synchronized, even at the "same" time between the EtherCAT systems on ports X1..8.
  In this case the overall system is essentially independent of frame delays/jitter, as long as these are not significant enough to impair the DistributedClocks control.
• With regard to EtherCAT operation, this method is essentially the most sensible, because
  • it offers the best temporal definition for the input/output operations of the EtherCAT devices
  • no time buffers are necessary in the CU2508

The following aspects must be taken into account in order to be able to estimate temporal effects in operation modes 1 and 3:

• Depending on the data content, Ethernet frames have a time length of
• X1..8 FastEthernet: 7..128 µs, InterFrameGap (IFG) 9.6 µs
• X9 Gbit: 0.7..12 µs, IFG 0.96 µs
• 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
  



• In the uplink
  FastEthernet X1..X4 to Gbit X9: tGE = 0.7 µs
  FastEthernet X5..X8 to Gbit X9: tGE = 1.1 µs
  



• These delays are therefore relatively insignificant compared to the other factors mentioned above. What immediately catches the eye, however, is the importance of the frame length and the required buffering in the uplink.

CU2508 as EtherCAT slave

Each downlink port of the CU2508 can be configured as a separate "EtherCAT device", see chapter EtherCAT device setup. In this case the CU2508 port represents the first EtherCAT device in the system. It is capable of Distributed Clocks and can therefore operate as a reference clock in the strand.

The combination of EtherCAT cable redundancy and Distributed Clock function is possible by combining two such EtherCAT ports using the "TwinCAT cable redundancy" supplement (subject to charge).

Time-controlled send/receive (in preparation)

The frame forwarding in the CU2508 can be subjected to precise time control by the local clock:

• the driver or the user application specifies the downlink port via which the frame is to be sent by the CU2508 and when.
  These data are added by the driver to each frame as additional information.
• each frame received by the CU2508 at a Downlink port is supplemented by receipt information (receiving port, time) and forwarded to the controller via the uplink.

The local hardware-based clock in the CU2508 then controls the sending of the frames with a high temporal quality. In this way, the CU2508 permits the construction of a real-time Ethernet network (TwinCAT Publisher/Subscriber, Profinet etc.), even if the control device cannot guarantee hard real-time when sending the protocol data. However, the control device must be able to deliver or accept the data with sufficient speed.

The time controller uses the 64-bit time format familiar from the EtherCAT Distributed Clocks system: resolution 1 ns, starting from 1.1.2000 00:00 and thus adequate for ~584 years

The time stamp information (sending and receiving) is for the time being only evaluated by the CU2508 driver and is not available to the user application.

As the start of an Ethernet frame, the SFD (Start of Frame Delimiter) is evaluated according to the IEEE802.3 standard.

EoE and TCP/IP

The CU2508 is connected to the IPC via the Gbit interface. This Ethernet interface appears in the operating system/Windows of the IPC with its properties (IP address, IP mask etc.). From the point of view of the operating system, therefore, there is “only” this network connection via which telegrams can be sent or received. The CU2508 driver can now either convey data traffic from the operating system level to a dedicated CU2508 port or feed it into the virtual EtherCAT EoE “switch”. Also compare the documentation for the EL6601/EL6614 here. The selection is made in the settings in the System Manager. Either the specific CU2508 port or generally EoE can be selected via "TCP/IP Port".

Refer in particular to the TCP/IP notes here.

Applications

The above-described functions permit the use of the CU2508 for the following applications, among others:

• Multi EtherCAT adapter
  Up to 8 independent EtherCAT systems can be created.
• Synchronized EtherCAT systems
  If the CU2508 is selected as the ReferenceClock, the EtherCAT systems connected to the CU2508 are operated with the same synchronized time base.
• EtherCAT cable redundancy
  2 downlink ports of each CU2508 can be combined into a cable-redundant EtherCAT system. Hence, fewer Ethernet ports are occupied on the controller; only one Gbit Ethernet port is required for the uplink. Up to 4 cable-redundant EtherCAT systems are possible. The CU2508 is placed next to the controller in the control cabinet; I/O cable connections that are in danger of being disconnected are then fed redundantly out of the control cabinet in the ring closure.



• EtherCAT cable redundancy with Distributed Clocks
  The common time base of the CU2508 ensures that EtherCAT slaves that require Distributed Clocks are still subject to synchronization in the case of redundancy.
  The CU2508 is currently the only way to operate Distributed Clocks compatible slaves in a cable-redundant ring.
• Use of TCP/IP without real-time
  A downlink port on the CU2508 can be configured as a non-real-time Ethernet port, or the CU2508 works in the Ethernet over EtherCAT (EoE) network and forwards TCP/IP frames from the connected EtherCAT systems.



• Real time fieldbus on non-real-time controller
  If an Ethernet-based fieldbus requires a reliable constancy with respect to the sending of communication telegrams, low jitter is demanded in the cyclic operations of the controller. If a high-performance controller is able to process the cyclic operations with sufficient frequency (= demanded short cycle time), but the jitter, i.e. the regular interval between the cycles is inadmissibly high, then the CU2508 system, as a real-time frame handler, can provide the constant interval in frame sending, provided the new data are available early enough in the CU2508.

There are currently still restrictions (TwinCAT 2.11/3.1, FW10) with regard to

• external synchronization of the CU2508
  The influence on the internal CU2508 clock is still in preparation.
• Profinet
• BACNet
• time stamp-controlled sending/receiving of frames

The implementation of these and further protocols is in preparation.

Data traffic in the lower-level EtherCAT segments

From FW07 and ESI revision -0018, Ports 1 and 5 have a larger data buffer of 16 kbyte (instead of 8 kbyte) for EtherCAT segments with particularly high data transfer rates.

"High data traffic" is generated by IO systems with many cyclical data, e.g. when many subscribers (over 100) and/or subscribers with large data requirements (e.g. analog oversampling terminals) are used.

If a "large" IO system is operated in EtherCAT redundancy mode, it is advisable to use ports 1 and 5.

The memory situation found is occasionally reported by TwinCAT with "Cu2508 fifo sizes...":