Distributed Clocks settings in the Beckhoff TwinCAT System Manager (2.11)

System Manager - display of the time of action

In the System Manager, from TwinCAT 2.11 on, an optional display allows the online offsetting when outputs are set from the point of view of the controller, or the time from when read inputs originate. The following information applies exclusively to Distributed Clocks slaves.

For basic understanding, a complete EtherCAT update cycle is explained here by way of an example – in the example a digital input will be read and output to a digital output. These are in both cases DC-based slaves, therefore an EL1202-0100 (input, yellow) and an EL2202-0100 (output, red) are used.

Introductory remarks:

• EtherCAT is configured correctly and executes a fieldbus cycle at EtherCAT ‘IoUpdate’ with a cycle time in this example of 100 µs after each PLC ‘calc’ cycle.
  SeperateInputUpdate or "IO on task start" is not used in this example.
• In the EtherCAT cycle, the input data is collected from the slaves whilst at the same time the output data is written to the slaves.
• The slave clocks are synchronized to the EtherCAT master by the DC system.
• An external synchronization of TwinCAT to a higher-level reference clock does not take place in this example.

New in TwinCAT 2.11 is the possibility to determine the time of CurTaskTime in the PLC online at runtime by calling the function F_GetCurDcTaskTime. The time at which the EtherCAT frame arrives at the first DC-capable device (Fig. Topology and principle of operation used in the example, B) is the central time to which the entire system is regulated. It corresponds to the CurTaskTime of the preceding cycle, which means: If the function F_GetCurDcTaskTime is called in PLC cycle A, it reports time B. This value remains constant even after repeated determination within this task cycle. From the point of view of the running PLC program this is the "now" time. From this "now" perspective the controller sees

• its input data: these were obtained x time ago in the field.
• its output data: these will become effective y time later in the field

The x or y times respectively are constant in each cycle if the EtherCAT system with Beckhoff TwinCAT EtherCAT Master is running stably.

However, this approach is only permissible because the DC system determines exactly when input data is read and output data is output; therefore, it cannot be used for slaves without DC functionality (such as EL200x or EL100x).

The x and y times are now available as pre-calculated values in the System Manager in TwinCAT 2.11 for linking to the controller:

• DcInputShift: so ‘old’ is the input data from the point of view of the ‘now’ time
• DcOutputShift: so much later will the output data become effective in the field.

Note

Based on the internal real-time, TwinCAT triggers the task/NC/PLC/... The aim of the control is to always let the (first) EtherCAT frame arrive at the first DC-capable EtherCAT slave at the cycle interval (e.g. 1 ms). This is made more difficult or impossible, if the PLC/task has a very irregular/fluctuating execution time, resulting in synchronization problems at the fieldbus. Appropriate buffer can be provided through the TwinCAT setting "percent of cycle time".

Die TwinCAT Echtzeitregelung versucht durch entsprechendes Triggern/Starten der PLC/NC/sonstige Task, trotz der evtl. schwanken Ausführungszeit

Sample

Let us consider the EL1202-0100 in the above example at a cycle time of 100 µs (100,000 ns) in the configuration.

Since it is configured like this, the terminal informs about the following in the online state:

• DcOutputShift = 90.000 [ns]
• DcInputShift = 110.000 [ns]

Comments

• Both time values consist of 32 bits [1 digit = 1 ns] and are therefore sufficient for approx. 4.2 seconds
• Both are to be considered ‘logically’:
• positive values for outputs point to the future
• positive values for inputs point to the past
• Each slave displays both values; which value needs to be taken into account must be judged by the presence of input and/or output variables.

The EL1202-0100 is an input terminal and thus in the ‘InputBased’ DC group - it works in a standard fashion, i.e. in sync with all of the DC input modules, the yellow symbols in Fig Topology and principle of operation used in the example. In addition, it has only input variables. Thus, especially useful is the consideration of the DcInputShift value:
From the point of view of the ‘now’ time of the controller, the input value Input= 1 i.e. 110,000 ns is ‘old’.

Note: The EL1202-0100 also provides the exact latch time as the NextLatchTime process parameter, a feature that not all DC slaves support.

Sequence by way of an example

In this example, the digital input B is to be read and immediately output again on a digital output J. We follow the sequence (blue):

• A: the DC unit in the EL1202-0100 initiates the ‘latching’ of the inputs with Sync_In - this point in time is fixed and is defined by the shift times in the master/slave.
  this ‘latching’ must take place in such a timely manner that the data are securely available before the collecting frame despite any fluctuations.
• B: the inputs are read and a device depending delay occurs - the data is ready to be picked up at time C.
  Note: the delay in the EL 1202 is approx. 0 µs.
• D: The data are collected by the EtherCAT telegram and stored in the input process image of the controller.
  The EtherCAT frame successively passes through the slaves, at successive points in time. The FIRST DC-capable slave, the so-called reference clock, plays a special role: the time at which the (first) EtherCAT frame arrives at this slave is the central point in time CurTaskTime
• The real-time control is aligned to this time: since the central, fixed reference time runs in this slave, the real-time is adjusted based on early/late arrival of the frame.
• It is the time that is also used in the PLC as a reference point for all shift times DcInputShift/DcOutputShift.
  Sample: In the PLC cycle "Calc X", the function F_GetCurDcTaskTime returns the time P (although from the perspective of Calc X it is slightly in the future). On this basis, DcInputShift and DcOutputShift can then be taken into account accordingly.
• After the calculation E, the output data is output with the next IO cycle or EtherCAT update to the field: F, G.
• With a sufficient safety margin to the fieldbus cycle, the data is output, triggered by the Sync_Out of the DC unit in the EL2202-0100.
• H, J: Depending on the device, a device delay is still to be taken into account until the data is output.
  Note: the delay in the EL2202 is < 1 µs.

The tasks B and J, which are critical for the user, can always be set by the specifications DcInputShift (M) and DcOutputShift (N) in relation to the now-time (P).

Note: The function SeparateInputUpdate currently (2015-06, TwinCAT 3.1 b4018) has no automatic effect on the calculation of DcInputShift/DcOutoutShift. The (input) shift times of the corresponding terminals should be adjusted manually, as applicable.

Checking the effectiveness of DC from the point of view of the controller

The above-mentioned values DcInputShift and DcOutputShift are theoretical values which are valid if the EtherCAT system is running stably. The default settings in the System Manager are defined such that these values are reliably adhered to in virtually all cases.

Typical reasons why they are occasionally or systematically not complied with in the application are:

• poor quality real-time e.g. when using third-party hardware
• cycle timeout due to program errors
• incorrect task prioritization
• LostFrames or otherwise incorrect Ethernet frames, for example, due to faulty wiring
• the SYNC pulses at the slave come at the wrong time due to manual DC setting

Nevertheless, it can be useful in the field to check the actual number of read/write operations that have taken place, for example, during commissioning or the manual optimization of DC slaves. As a check, the following are recommended:

• for input slaves
• CycleCounter:
  Some slaves (see documentation) such as the EL37xx or the EL12xx offer a continuous CycleCounter that is incremented in each slave cycle. This can be monitored in the controller.
• InputToggle:
  Some slaves offer this input variable, which toggles in every successful slave cycle.
• WorkingCounter, status:
  Monitoring this status information is obligatory
• for output slaves
• WorkingCounter, status:
  Monitoring this status information is obligatory
• local error counters:
  Some slaves (see documentation) expect on their part an incremented CycleCounter from the controller and increment an error counter locally if the controller does not follow this. This error counter in the slave can be read back by the controller. The EL2262 or EL47xx have this mechanism.

System Manager – Shift Time settings

With respect to the shift time, very similar dialogues can be found in the advanced dialogue of EtherCAT masters and slaves, for which reason they are discussed here together.

The term ‘shift time’ in the settings dialogs differs in meaning from the above-mentioned DcInput/OutputShift; compare with Figs. EtherCAT Update (schematic) und Local slave shift time!

• In the TwinCAT settings dialogues, the shift time is specified from the time of the IoUpdate and, logically, originates from the range [-cycle time … 0 … +cycle time]
  The internal SYNC pulse in the slave is triggered this much earlier in the case of inputs (Fig. Local slave shift time, yellow, "A") or this much later in the case of outputs (Fig. Local slave shift time, red, "B") in relation to the time of the IoUpdate.
  However, this does not take into account that some time may be needed to transport the data from/to the slaves! This is only done by
• DcInput/OutputShift according to Fig. EtherCAT Update (schematic), which also takes into account SeperateInputUpdate or "IO on task start".

The following applies for setting: effective shift time = master shift time + slave shift time

In the EtherCAT master:

Among other things, on the basis of the cycle time, TwinCAT has shifted the group of output modules from the point of view of CurTaskTime by 37.6 µs into the future here; the input modules, conversely, will read their inputs 10 µs before the CurTaskTime. These two times correspond to A/B from Fig. Local slave shift time. If necessary, they can be modified by means of additional entries.

In the EtherCAT slave:

The shift time is displayed from the (default) point of view of the output modules in the slave dialogue - the EL1202-0100 shown here is an input module; it will therefore be automatically specified to BasedOnInputReference and its SYNC signal will thus be (-37.6 - 10 µs) ahead of the output modules.

When a slave is to be ‘shifted’ manually, consistent values can be entered in the UserDefined field.

• Values in the range 10 – 30 % of the cycle time are consistent.
• Changes in the DC entries will become effective only after the activation of the configuration and a restart of the EtherCAT system.

Displaying the shift time

The display of the individual slave shift times is possible via the advanced settings of the slave.

Advanced Settings

• Continuous Runtime Measuring

If activated, TwinCAT cyclically measures the runtimes between the EtherCAT devices. It is recommended to retain this setting. Deactivation can create space for cyclic data in the case of a very short cycle time, because the NOP datagram is then dispensed with.

• SyncWindowMonitoring
  
  If activated, EtherCAT DevState shows in bit 12 whether all DC devices are maintaining their local clocks within the specified window.

A cyclic BRD command on 0x092C (system time difference) is used for this.
The information is only usable if the first EtherCAT device also contains the master clock.

• Show DC System Time
  
  If activated, the current DC time is displayed in the inputs of the EtherCAT master as a copy from the master clock. Since the read out process is subject to the fieldbus transport, preference should be given to the PLC blocks in order to obtain the current DC system time.

Distributed Clocks diagnosis

The TwinCAT System Manager offers the possibility in an online state to make a preliminary statement about the quality of the current real-time.

Sequence:

• If a task is called, it calculates the time of the next call with the current time and its own cycle time.
• If it is then called on in the next cycle, it compares this expected value with the actual time.
• The deviation is illustrated as shown below.

A system according to Fig. Online DC diagnosis - adjustment required, for example, is not suitable for fast EtherCAT applications with a cycle time of, say, 100 µs and may require adjustments.