Answers to frequently asked questions
- What time base is suitable for the synchronization of distributed systems?
- What needs to be considered if sun times (e. g. UTC) are to be used?
- How is an absolute time, e. g. UTC, calculated?
- Why is DcToTcTimeOffset sometimes 0 and DcToExtTimeOffset other times 0?
- How is a T_DCTIME64 variable turned into something user readable?
- Error in PTP diagnosis: PTP state should change from "LISTENING" to "SLAVE"
- Error in PTP diagnosis: "Offset From Master" does not settle around "0"
What time base is suitable for the synchronization of distributed systems?
PTP/IEEE1588 is designed in such a way that TAI is distributed as a time source and, if required, the UTC time can be calculated in the respective end devices using the "UTC Offset".
In order avoid time jumps (which can lead to undesired effects within a plant), it is advisable to use and distribute a constantly advancing time (e. g. without leap seconds), such as the international atomic time [French Temps Atomique International (TAI)].
Coordinated Universal Time (UTC), on the other hand, involves the risk of time jumps (due to leap seconds), but is synchronous with solar time and thus more "suitable for everyday use" for many processes.
Nevertheless, the direct use of UTC is not recommended, since (for the control unpredictable) time jumps can considerably disturb the proper operation of a plant. If UTC is still required for the application, the indirect way via the UTC offset should be chosen. The TAI can be converted to UTC using the UTC Offset in the application.
The base time provided by the grandmaster is used as the base time of the EL6688! This base time will almost always be the TAI (because other time sources/bases can be jumpy). If necessary, commercially available grandmasters show UTC in the display, but TAI is distributed in the network (if the device has not been adjusted).
What needs to be considered if sun times (e. g. UTC) are to be used?
The indirect way via TAI and the UTC offset should always be chosen. The TAI can be converted to UTC using the UTC Offset in the application. If the grandmaster provides information about the current UTC offset, this information is stored in the CoE of the EL6688 so that it can be processed in the controller. The current number of leap seconds (CoE: CurrentUtcOffset (0xFA80.0B)) as well as announcements of possible further leap events (CoE: Leap61 (0xFA80.0D) for plus 1 s and Leap59 (0xFA80.0E) for minus 1 s) are transmitted and should be evaluated by the user.
Concretely: if the Grandmaster has determined a correct UTC offset e. g. via GPS, it will provide this value in the network:
- 0xFA80:0A Timescale, transmitted by the grandmaster: for TAI the value "1" is given
- 0xFA80:0B CurrentUtcOffset, transmitted by the grandmaster: offset to UTC time in seconds
- 0xFA80:0C CurrentUtcOffsetValid, transmitted by the grandmaster:
- TRUE if offset is known/valid,
- FALSE if invalid
- 0xFA80:0D Leap61, transmitted by the Grandmaster: leap second event pending: 1 second added at 23:59:60 (no effect on TAI)
- 0xFA80:0E Leap59, transmitted by the grandmaster: leap second event pending: 1 second subtracted at 23:59:59 (no effect on TAI)
The leap second events "leap59" or "leap61" do not affect TAI or a device synchronized with TAI time source, this information is only used by the application, which can use it to completely map or calculate the UTC time and, if necessary, take suitable protective measures in the event of a leap second.
How is an absolute time, e. g. UTC, calculated?
If an external time source (e. g. a GPS-assisted PTP master) is connected with TwinCAT via the EL6688, the UTC can be calculated using the following equation (see example project for TC2 resp. TC3) (reference example PLC project):
UTCabsolut :=F_GetCurExtTime64 (DcToExtTimeOffset, DcToTcTimeOffset) – UTC_Offset_NSec
or
UTCabsolut :=F_ ConvTcTimeToExtTime64 (GetCurDcTaskTime64(), DcToTcTimeOffset, DcToExtTimeOffset) – UTC_Offset_NSec
- UTCabsolute - task current UTC time expressed as a distance from 1/1/2000 00:00. in nanoseconds.
- F_GetCurExtTime64() - supplies the start time (ExtTime, as T_DCTIME64 alias ULINT) of the task in which it is called.
- F_GetCurDcTaskTime64() – supplies the start time (TcTime, as T_DCTIME64 alias ULINT) of the task in which it is called.
- F_ConvTcTimeToExtTime64()- converts TcTime to ExtTime.
(GetCurExtTime64, GetCurDcTaskTime64 as well as ConvTcTimeToExtTime64 are part of the PLC library Tc2_EtherCAT.lib)
- DcToTcTimeOffset - during the TwinCAT system start the TC time is initialized by the Windows clock. If the external clock is also available during the system startup, deviations between these clocks are thus compensated.
- UTC_Offset_NSec - since TwinCAT works internally with the TAI time, any leap seconds introduced up to now must be subtracted (status 2017: 37 seconds) (see also EL6688-CoE: CurrentUtcOffset (0xFA80.0B)).
- DcToExtTimeOffset - TwinCAT uses this offset variable to handle larger deviations between the external clock and the DC time that occur during operation (e. g. due to loss of the connection to the external clock) and can no longer be automatically compensated.
Why is DcToTcTimeOffset sometimes 0 and DcToExtTimeOffset other times 0?
During the development phase of a controller, the "Auto Boot" setting in "Boot Settings" in the TwinCAT system may still be set to "Config Mode". If this is the case, TwinCAT cannot access the external clock during the startup phase (even with a physical connection between PTP master and EL6688) - thus DcToTcTimeOffset = 0 and the difference is entered by TwinCAT in DcToExtTimeOffset.
Only by setting "Auto Boot" to "Run Mode (Enable)" TwinCAT can also access the external clock during the startup phase and thus process the offset and store it in the variable "DcToTcTimeOffset".
How is a T_DCTIME64 variable turned into something user readable?
sXXX := DCTIME64_TO_STRING(tXXX)
- tXXX - 503764149978700026 - DCTIME64 alias ULINT: time as distance in nanoseconds from 1/1/2000 00:00
- sXXX - '2015-12-18-14:29:09.978700026' - STRING(29):
- DCTIME64_TO_STRING() - transforms a T_DCTIME64 to a 29 character-string. Part of PLC library: Tc2_EtherCAT
Error in PTP diagnosis: PTP state should change from "LISTENING" to "SLAVE"
- Check the correspondence of the PTP Settings between PTP Master and EL6688 (CoE: 0xF882).
- Check the network settings between the PTP master and the EL6688 (CoE: 0xF8E0). The IP address must not be zero.
Error in PTP diagnosis: "Offset From Master" does not settle around "0"
- Check that "Auto Boot" is set to "Run Mode" and restart the system.
- Depending on the hardware used and its accuracy (for example: less than ±1000 ns = 1 µs for a GPS-supported system), the "Offset From Master" value oscillates according to this accuracy.
Increasing the Sync Interval (CoE: OxF882.3) can improve the accuracy, but also increases the network-side traffic.