Flow Control
The flow control has to accept the application, i.e. the EL6695 does not employ a handshake mechanism. However, in both PDO modes a counter can be displayed, which is incremented with each write access from the other side: CoE object 0xF640. To ensure that this counter can be mapped as cyclic PDO, it should be mapped as follows via a startup entry:
In order to be able to map the CoE object 0xF640, first all online CoE objects should be displayed, as described in chapter “Basics communication”/ “CoE Interface”, section “Online/offline list”. The PDO data of the device can then be reloaded via the Process Data tab, so that the PDO list shows the entry Active TX PDOs Map. If the entry Inputs is now selected under Sync Manager, the object 0x1A04 can be ticked under PDO assignment, and the counter of CoE object 0xF640 is mapped into the process image.
Data throughput (example)
The following diagram illustrates the data throughput of the EL6695 in standard configuration and with two optimization methods, i.e. optimization through synchronization and optimization through a separate IO update, including synchronization:
The time it takes to transport the configured process data from one EtherCAT side to the other depends on the data quantity.
The internal data transport is triggered by reading on one side. The figure “EL6695 data transport sequence” below illustrates the sequence:
- The SyncManagers 2 and 3 operate in 3-buffer mode,
- if an EtherCAT master fetches data from SyncManager 3, buffer 3, via an EtherCAT frame (A), immediately after this read process is complete (B) the EL6695 starts copying new data from the other side into the next free buffer, in this case buffer 1. The “Copy Time” this process takes can be read online.
The names “my”/ “remote” refers to the “I” side, depending on whether the current online CoE is that of the primary side or the secondary side. - The data remain there until they are retrieved by EtherCAT A.
- If the cycle time is long, relatively old data may remain there for nearly a whole EtherCAT cycle. The transport timing can be shifted through a CoE setting. Through this delay the system can be optimized such that data stored by system B in SM2 are transferred internally shortly afterwards to side A, SM3, in which case the data which the passing EtherCAT frame A then fetches are relatively fresh.
It is important to ensure minimum system jitter on sides A and B.
The shifting can be set via
- CoE 0x1C33:03 ShiftTime in ns
- CoE 0xF830:01 in online CoE available only, delay in µs
The example below illustrates a measurement with the following configuration:
- PLC on the primary side sends a PDO set
- EL6695 transports the set to the other side
- PLC on the primary side fetches the data and may resend it in modified form
- EL6695 transports the data to the other side
- PLC of the primary side fetches the data and counts the PLC cycles up to now
In this example no optimizations were carried out (PDO delay, DC synchronization).
Number of PDO bytes | Task cycle time | Number of task cycles for both directions (Average values) | Resulting transfer time (one direction) | Copying times for the input and output data within the EL6695; from CoE object 0xFA20 Device Diag. (Average values) |
|---|---|---|---|---|
200 | 50 µs | 4.4 | 141.1 µs | 14.3 µs |
100 µs | 3.03 | 151.5 µs | 14.3 µs | |
1400 | 150 µs | 8.9 | 667.5 µs | 42.9 µs |
200 µs | 6.0 | 600 µs | 42.3 µs |
To realize hard-coupled cyclic data transfer, distributed clocks coupling of the two EtherCAT sides is advisable, in order to avoid beat effects during the data transport.
Notice: In practice, the EL6695 always involves two fieldbuses with their cycle times. Optimum timing is required (DC synchronization, shift times adjusted) in order to realize a PC A → PC B transport time that is as short as that of a direct Realtime Ethernet link with publisher/subscriber. Even then, optimization is only possible for one direction, and in addition there is a delay due to the internal transport time.