Antworten auf häufig gestellte Fragen

Welche Zeitbasis eignet sich zur Synchronisation verteilter Systeme?

PTP/IEEE1588 ist so konzipiert, dass TAI als Zeitquelle verteilt wird und bei Bedarf in den jeweiligen Endgeräten mit Hilfe des „UTC Offset“ die UTC-Zeit berechnet werden kann.

Um Zeitsprünge zu vermeiden (die zu ungewünschten Effekten innerhalb einer Anlage führen können), ist es ratsam, eine konstant ansteigende Zeit (z. B. ohne Schaltsekunden) zu verwenden und zu verteilen, wie beispielsweise die internationale Atomzeit [französisch Temps Atomique International (TAI)].

Die koordinierte Weltzeit [englisch Coordinated Universal Time (UTC)] hingegen birgt die Gefahr von Zeitsprüngen (durch Schaltsekunden) ist dafür jedoch synchron zur Sonnenzeit und somit für viele Prozesse "alltagstauglicher".

Trotzdem wird von der unmittelbaren Nutzung der UTC abgeraten, da (für die Steuerung unvorhersehbare) Zeitsprünge den ordnungsgemäßen Betrieb einer Anlage erheblich stören können. Sollte UTC für die Anwendung dennoch erforderlich sein, so sollte der indirekte Weg über das UTC Offset gewählt werden. Die TAI kann mithilfe des UTC Offset in der Applikation in UTC umgerechnet werden.

Die EL6688 hat als Basiszeit diejenige Basiszeit, welche vom Grandmaster bereitgestellt wird! Diese Basiszeit wird fast immer die TAI sein (weil andere Zeitquellen/-basen sprungbehaftet sein können). Ggf. wird von handelsüblichen Grandmastern im Display zwar UTC angezeigt, im Netzwerk wird jedoch TAI verteilt (wenn das Gerät nicht verstellt wurde).

Worauf ist zu achten, wenn Sonnenzeiten (z. B. UTC) verwendet werden sollen?

Es sollte stets der indirekte Weg über TAI und das UTC offset gewählt werden. Die TAI kann mithilfe des UTC Offset in der Applikation in UTC umgerechnet werden. Sofern der Grandmaster Informationen zum aktuellen UTC Offset bereitstellt, werden diese im CoE der EL6688 vorgehalten, so dass diese sich in der Steuerung verarbeiten lassen. Die aktuelle Anzahl an Schaltsekunden (CoE: CurrentUtcOffset (0xFA80.0B)) sowie Ankündigungen möglicher weiterer Schaltevents (CoE: Leap61 (0xFA80.0D) für plus 1s und Leap59 (0xFA80.0E) für minus 1s) werden übermittelt und können vom Anwender ausgewertet werden.

Konkret: Sofern der Grandmaster z. B. via GPS einen korrekten UTC-offset ermittelt hat, wird er diesen Wert im Netzwerk bereitstellen:

• 0xFA80:0A Timescale, vom Grandmaster übermittelt: für TAI steht der Wert „1“
• 0xFA80:0B CurrentUtcOffset, vom Grandmaster übermittelt: Offset zur UTC Zeit in Sekunden
• 0xFA80:0C CurrentUtcOffsetValid, vom Grandmaster übermittelt:
• TRUE wenn Offset bekannt/gültig,
• FALSE wenn ungültig
• 0xFA80:0D Leap61, vom Grandmaster übermittelt: Schaltsekundenereignis steht an: 1 Sekunde wird hinzugefügt um 23:59:60 (kein Einfluss auf TAI)
• 0xFA80:0E Leap59, vom Grandmaster übermittelt: Schaltsekundenereignis steht an: 1 Sekunde wird abgezogen um 23:59:59 (kein Einfluss auf TAI)

Die Schaltsekundenereignisse „leap59“ bzw. „leap61“ wirken sich nicht auf TAI bzw. auf ein mit TAI Zeitquelle synchronisiertes Gerät aus. Diese Informationen dienen lediglich der Applikation, welche damit die UTC Zeit vollständig abbilden bzw. berechnen und ggf. geeignete Schutzmaßnahmen im Schaltsekundenfall ergreifen kann.

Wie berechnet sich eine absolute Zeit, wie beispielsweise die UTC?

Sofern eine externe Zeitquelle (z. B. ein GPS-gestützter PTP-Master) über die EL6688 mit TwinCAT verbunden ist, lässt sich die UTC Zeit über folgende Formel berechnen (siehe Beispiel Projekt für TC2 bzw. TC3) (Verweis Beispiel PLC-Projekt):

UTCabsolut :=F_GetCurExtTime64 (DcToExtTimeOffset, DcToTcTimeOffset) – UTC_Offset_NSec

oder

UTCabsolut :=F_ ConvTcTimeToExtTime64 (GetCurDcTaskTime64(), DcToTcTimeOffset, DcToExtTimeOffset) – UTC_Offset_NSec

• UTCabsolut - Task aktuelle UTC Zeit als Abstand in Nanosekunden vom 1.1.2000 00:00.
• F_GetCurExtTime64() - liefert die Startzeit (ExtTime, als T_DCTIME64 alias ULINT) der Task in der sie aufgerufen wurde.
• F_GetCurDcTaskTime64() - liefert die Startzeit (TcTime, als T_DCTIME64 alias ULINT) der Task in der sie aufgerufen wurde.
• F_ConvTcTimeToExtTime64()- konvertiert TcTime in ExtTime.

(GetCurExtTime64, GetCurDcTaskTime64 sowie ConvTcTimeToExtTime64 sind Teil der SPS Bibliothek Tc2_EtherCAT.lib)

• DcToTcTimeOffset - während des TwinCAT-System-Starts wird die TC Zeit durch die Windowsuhr initialisiert. Sofern die externe Uhr während des Systemstarts auch zur Verfügung steht, werden Abweichungen zwischen diesen Uhren hiermit ausgeglichen.
• UTC_Offset_NSec - da TwinCAT intern mit der TAI Zeit arbeitet müssen bisher eingeführte Schaltsekunden abgezogen werden (Stand 2017: 37 Sekunden) (siehe auch EL6688-CoE: CurrentUtcOffset (0xFA80.0B)).
• DcToExtTimeOffset - um größere Abweichungen, die während des Betriebs (z. B. durch Verlust der Verbindung zur externen Uhr) zwischen der externen Uhr und der DC Zeit entstehen, zu händeln, welche sich nicht mehr automatisch ausregeln lassen, nutzt TwinCAT diese Offset-Variable.

Wieso ist mal DcToTcTimeOffset = 0 und mal DcToExtTimeOffset = 0?

Während der Entwicklungsphase einer Steuerung ist die Einstellung "Auto Boot" unter "Boot Settings" des TwinCAT-Systems möglicherweise noch auf "Config Mode". Sofern dies der Fall ist, kann TwinCAT während der Startphase (selbst bei physikalischer Verbindung zwischen PTP Master und EL6688) nicht auf die externe Uhr zugreifen - somit bleibt DcToTcTimeOffset = 0 und der Unterschied wird von TwinCAT in DcToExtTimeOffset eingetragen.
Erst durch Setzen der Einstellung "Auto Boot" auf "Run Mode (Enable)" kann TwinCAT während der Startphase auch auf die externe Uhr zugreifen und somit den Offset verarbeiten und in der Variable "DcToTcTimeOffset" speichern.

Wie wird aus einer T_DCTIME64 Variable etwas Menschenlesbares?

sXXX := DCTIME64_TO_STRING(tXXX)

• tXXX - 503764149978700026 - DCTIME64 alias ULINT: Zeit als Abstand in Nanosekunden vom 1.1.2000 00:00
• sXXX - '2015-12-18-14:29:09.978700026' - STRING(29):
• DCTIME64_TO_STRING() - Verwandelt eine T_DCTIME64 zu einem 29 Zeichen langen String. Teil von SPS Bibliothek: Tc2_EtherCAT

Fehler in PTP Diagnose: PTP State wechselt nicht von „LISTENING“ zu „SLAVE“

• Kontrollieren Sie die Übereinstimmung der PTP Settings zwischen PTP Master und EL6688 (CoE: 0xF882).
• Kontrollieren Sie die Netzwerkeinstellungen zwischen dem PTP Master und der EL6688 (CoE: 0xF8E0). IP-Adresse muss ungleich Null sein.

Fehler in PTP Diagnose: „Offset From Master“ schwingt sich nicht um „0“ herum ein

• Kontrollieren Sie, ob der "Auto Boot" auf "Run Mode" eingestellt ist und starten Sie das System neu.
• Entsprechend der verwendeten Hardware und deren Genauigkeit (beispielsweise: kleiner ±1000 ns = 1 µs bei einem GPS gestützten System) schwingt der Wert „Offset From Master“ entsprechend dieser Genauigkeit.
  Eine Erhöhung des Sync Intervals (CoE: OxF882.3) kann die Genauigkeit verbessern, erhöht jedoch auch den netzwerkseitigen Traffic.