Einstellungen Distributed Clocks im Beckhoff TwinCAT System Manager (2.11)

System Manager - Anzeige Wirkzeitpunkt

Im System Manager ab TwinCAT 2.11 erlaubt eine optionale Anzeige die Onlineverrechnung, wann Ausgänge aus Sicht der Steuerung gesetzt werden bzw. von wann gelesene Eingänge stammen. Die nachfolgenden Informationen gelten ausschließlich für Distributed Clocks-Slaves.

Zum Grundverständnis wird hier ein vollständiger EtherCAT-Update-Zyklus an einem Beispiel erklärt - es wird im Beispiel ein digitaler Eingang eingelesen und auf einen digitalen Ausgang ausgegeben. In beiden Fällen handelt es um DC basierte Slaves, deshalb wird eine EL1202-0100 (Eingang, gelb) und eine EL2202-0100 (Ausgang, rot) verwendet.

Einleitende Bemerkungen:

• EtherCAT ist korrekt konfiguriert und führt nach jedem PLC-Zyklus "calc" einen Feldbuszyklus auf EtherCAT "Io-Update" mit der Zykluszeit "cycletime" (im Beispiel: 100 µs) durch.
  SeperateInputUpdate oder "IO am Taskanfang" werden in diesem Beispiel nicht verwendet.
• Im EtherCAT-Zyklus werden zugleich die Eingangsdaten von den Slaves eingesammelt wie auch die Ausgangsdaten zu den Slaves geschrieben.
• Die Slaves-Uhren sind durch das DC-System synchronisiert zum EtherCAT-Master.
• Eine externe Synchronisation von TwinCAT gegenüber einer übergeordneten Referenzuhr findet in diesem Beispiel nicht statt.

Neu in TwinCAT 2.11 ist die Möglichkeit, in der PLC den Zeitpunkt CurTaskTime durch Aufruf der Funktion F_GetCurDcTaskTime online zur Laufzeit zu ermitteln. Der Zeitpunkt, an dem der EtherCAT Frame beim ersten DC-fähigen Teilnehmer ankommt (Abb. Im Beispiel verwendete Topologie und Arbeitsprinzip, B), ist der zentrale Zeitpunkt, auf den das gesamte System geregelt wird. Er entspricht der CurTaskTime des vorangehendes Zyklus', das bedeutet: wird im PLC-Zyklus A die Funktion F_GetCurDcTaskTime aufgerufen, meldet sie die Zeit B zurück. Dieser Wert bleibt auch bei mehrmaliger Ermittlung innerhalb dieses Taskzyklus konstant. Aus der Sicht des ablaufenden PLC-Programms ist das der "Jetzt"-Zeitpunkt. Von diesem "Jetzt"-Standpunkt aus sieht die Steuerung

• ihre Eingangsdaten: diese wurden vor x Zeit im Feld gewonnen.
• ihre Ausgangsdaten: diese werden y Zeit später im Feld wirksam werden

Die Zeiten x bzw. y sind bei einem einwandfreien und stabil laufenden EtherCAT-System mit Beckhoff TwinCAT EtherCAT-Master in jedem Zyklus konstant.

Diese Betrachtungsweise ist aber nur zulässig, da durch das DC-System exakt bestimmt wird, wann Eingangsdaten gelesen bzw. Ausgangsdaten ausgegeben werden und ist deshalb für Slaves ohne DC-Funktionalität (wie EL200x oder EL100x) nicht anwendbar.

In TwinCAT 2.11 stehen nun die Zeiten x und y als vorberechnete Werte im System Manager zur Verknüpfung mit der Steuerung zur Verfügung:

• DcInputShift: so "alt" sind die Eingangsdaten aus Sicht des "Jetzt"-Zeitpunktes
• DcOutputShift: soviel später werden die Ausgangsdaten im Feld wirksam.

Hinweis

TwinCAT triggert auf Basis der internen Echtzeit die Task/NC/PLC/... Ziel der Regelung ist dabei, den (ersten) EtherCAT Frame immer im Zyklus-Abstand (z. B. 1 ms) am ersten DC-fähigen EtherCAT Slave ankommen zu lassen. Dies wird erschwert bzw. wird sogar unmöglich, falls die PLC/Task eine extrem ungleichmäßige/schwankende Ausführungszeit aufweist. Dann kommt es zu Synchronisierungsproblemen am Feldbus. Durch die TwinCAT Einstellung "percent of cycle time" kann hier entsprechender Puffer vorgehalten werden.

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

Beispiel

Betrachten wir die EL1202-0100 aus obigem Beispiel bei einer Zykluszeit von 100 µs (100.000 ns) in der Konfiguration.

Da so konfiguriert, informiert die Klemme im Online-Zustand über

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

Anmerkungen

• Beide Zeitwerte umfassen 32 Bit [1 digit = 1 ns] und sind damit ausreichend für ~4.2 Sekunden
• Beide sind "logisch" zu sehen:
• positive Werte für Outputs weisen in die Zukunft
• positive Werte für Inputs deuten in die Vergangenheit
• Jeder Slave zeigt beide Werte an, es ist nach Vorhandensein von In- und/oder Ausgangsvariablen zu beurteilen welcher Wert berücksichtigt werden muss.

Die EL1202-0100 ist eine Eingangsklemme und damit in der DC-Gruppe "InputBased" - sie arbeitet standardmäßig also im Gleichtakt mit allen DC-Eingangsbaugruppen, in Abb. Im Beispiel verwendete Topologien und Arbeitsprinzip die gelben Symbole. Außerdem verfügt sie nur über Eingangsvariablen. Besonders zweckmäßig ist also die Betrachtung des Wertes DcInputShift:
Aus Sicht des "Jetzt"-Zeitpunktes der Steuerung ist der Eingangswert Input=1 also 110.000 ns "alt".

Anmerkung: die EL1202-0100 gibt zusätzlich auch noch den exakten Latch-Zeitpunktes als Prozessdatum NextLatchTime an, ein Feature das nicht alle DC-Slaves unterstützen.

Ablauf an einem Beispiel

In diesem Beispiel soll der digitale Eingang B eingelesen und umgehend auf einem digitalen Ausgang J wieder ausgegeben werden. Wir folgen dem Ablauf (blau):

• A: die DC-Unit in der EL1202-0100 stößt mit dem Sync_In das "Latchen" der Eingänge an - dieser Zeitpunkt ist fix und wird durch die Shiftzeiten im Master/Slave definiert.
  Dieses "Latchen" muss so rechtzeitig erfolgen, dass die Daten trotz etwaiger Schwankungen sicher vor dem abholenden Frame bereit stehen.
• B: die Eingänge werden gelesen, je nach Gerät tritt noch eine geräteseitige Verzögerung auf - zum Zeitpunkt C stehen die Daten zur Abholung bereit.
  Anmerkung: in der EL1202 ist die Verzögerung ~ 0 µs.
• D: Die Daten werden vom EtherCAT-Telegramm abgeholt und in das Eingangsprozessabbild der Steuerung abgelegt.
  Der EtherCAT Frame durchläuft die Slaves nacheinander, kommt also zu aufeinander folgenden Zeitpunkten an den Slaves vorbei. Eine besondere Rolle nimmt dabei der ERSTE DC-fähige Slave, die sog. Refernz-Uhr ein: der Zeitpunkt, zu dem bei diesem Slave der (erste) EtherCAT Frame ankommt, ist der zentrale Zeitpunkt CurTaskTime
• auf den die Echtzeitregelung ausgerichtet ist: da in diesem Slave die zentrale fixe Refernzzeit läuft, wird aus dem zu frühen/späten Ankommen des Frames die Echtzeit nachgeregelt.
• die Zeit, die auch in der PLC als Bezugszeitpunkt für alle Shift-Zeiten DcInputShift/DcOutputShift Verwendung findet.
  Beispiel: Im PLC-Zyklus "Calc X" ergibt die Funktion F_GetCurDcTaskTime als Rückgabe die Zeit P (obwohl diese von Calc X aus gesehen leicht in der Zukunft liegt). Davon ausgehend können dann DcInputShift und DcOutputShift entsprechend verrechnet werden.
• Nach der Berechnung E erfolgt mit dem nächsten IO-Zyklus bzw. EtherCAT-Update die Ausgabe der Ausgangsdaten an das Feld: F, G.
• Mit genügend Sicherheitsabstand zum Feldbuszyklus erfolgt, getriggert durch das Sync_Out der DC-Unit in der EL2202-0100 die Ausgabe der Daten.
• H, J: Je nach Gerät ist noch eine geräteseitige Verzögerung zu berücksichtigen, bis die Daten ausgegeben werden.
  Anmerkung: in der EL2202 ist die Verzögerung < 1 µs.

Die für den Anwender entscheidenden Vorgänge B und J können jederzeit durch die Angaben DcInputShift (M) und DcOutputShift (N) in Bezug zur Jetzt-Zeit (P) gesetzt werden.

Hinweis: Die Funktion SeparateInputUpdate hat derzeit (2015-06, TwinCAT 3.1 b4018) keine automatische Auswirkung auf die Berechnung der DcInputShift/DcOutoutShift. Im Anwendungsfall sollten manuell die (Input-) Shiftzeiten der betreffenden Klemmen angepasst werden.

Überprüfung der DC-Wirksamkeit aus der Steuerungssicht

Die o.a. Werte DcInputShift und DcOutputShift sind theoretische Werte die gültig sind, wenn das EtherCAT-System stabil läuft. Die Default-Einstellungen des System Manager sind so definiert, dass diese Werte in den allermeisten Fällen zuverlässig eingehalten werden.

Typische Gründe warum sie in der Applikation gelegentlich oder systematisch nicht eingehalten werden können sein:

• qualitativ schlechte Echtzeit z. B. bei Verwendung von Fremd-Hardware
• Zykluszeitüberschreitungen durch Programmfehler
• falsche Taskpriorisierung
• LostFrames oder anderweitig fehlerhafte Ethernet-Frames, z. B. durch fehlerhafte Verkabelung
• durch manuelle DC-Einstellung kommen die SYNC-Impulse im Slave zum falschen Zeitpunkt

Dennoch kann eine Überprüfung der tatsächlich erfolgten Lese/Schreiboperationen im Feld sinnvoll sein, z. B. bei der Inbetriebnahme, bei manueller DC-Optimierung von Slaves. Als Überprüfung wird empfohlen:

• bei Input-Slaves
• CycleCounter:
  Manche Slaves (siehe Dokumentation) wie EL37xx, EL12xx bieten einen fortlaufenden CycleCounter an, der in jedem Slave-Zyklus inkrementiert. Dies kann in der Steuerung überwacht werden.
• InputToggle:
  Manche Slaves bieten dies Eingangsvariable an, die in jedem erfolgreichen Slave-Zyklus toggelt.
• WorkingCounter, Status:
  Die Überwachung dieser Statusinformationen ist obligatorisch
• bei Output-Slaves
• WorkingCounter, Status:
  Die Überwachung dieser Statusinformationen ist obligatorisch
• lokale Fehlerzähler:
  Manche Slaves (siehe Dokumentation) erwarten ihrerseits einen inkrementierten CycleCounter aus der Steuerung und zählen lokal einen Fehlerzähler hoch, wenn die Steuerung dem nicht folgt. Dieser Fehlerzähler im Slave kann von der Steuerung rückgelesen werden. Die EL2262 oder EL47xx verfügen über diesen Mechanismus.

System Manager - Einstellungen Shiftzeit

Im Advanced-Dialog von EtherCAT-Master und Slave sind in Bezug auf die Shiftzeit sehr ähnliche Dialoge zu finden, weshalb sie hier zusammen besprochen werden.

Der Begriff "Shiftzeit" in den Einstellungsdialogen unterscheidet sich in der Bedeutung von dem o.a. DcInput/OutputShift, vergleichen Sie dazu Abb. EtherCAT Update (schematisch) und Lokale Slave- Shiftzeit!

• In den TwinCAT-Einstellungsdialogen wird die Shiftzeit angegeben ab dem IoUpdate-Zeitpunkt und stammt sinnvollerweise aus dem Bereich [-Zykluszeit...0...+Zykluszeit].
  Um so viel früher bei Eingängen (Abb. Lokale Slave- Shiftzeit, gelb, "A") bzw. später bei Ausgängen (Abb. Lokale Slave- Shiftzeit, rot, "B") wird in Bezug auf die IoUpdate-Zeit der Slave-interne SYNC -Impuls ausgelöst.
  Das berücksichtigt aber nicht, dass evtl. einige Zeit benötigt wird um die Daten von/zu den Slaves zu transportieren! Dies macht erst
• DcInput/OutputShift nach Abb. EtherCAT Update (schematisch), die auch SeperateInputUpdate oder "IO am Taskanfang" berücksichtigt.

Zur Einstellung gilt: effektive Shiftzeit = ShiftzeitMaster + ShiftZeitSlave

Im EtherCAT-Master :

U.a. auf der Basis der Zykluszeit hat TwinCAT hier die Gruppe der Ausgangs-Baugruppen aus der Sicht der CurTaskTime um 37.6 µs in die Zukunft verschoben, die Eingangs-Baugruppen werden dagegen 10 µs vor der CurTaskTime ihre Eingänge lesen. Diese beiden Zeiten entsprechen A/B aus Abb. Lokale Slave- Shiftzeit. Im Bedarfsfall können sie durch Zusatzeinträge modifiziert werden.

Im EtherCAT-Slave:

Im Slave-Dialog erfolgt die Anzeige der Shifttime aus der (Default)-Sicht der Ausgangsbaugruppen - die hier gezeigte EL1202-0100 ist eine Eingangsbaugruppe, diese wird also automatisch auf BasedOnInputReference gelegt und damit wird ihr SYNC-Signal (-37.6 - 10 µs) vor den Ausgangsbaugruppen liegen.

Wenn ein Slave manuell "geshiftet" werden soll, könne sinnvolle Werte im Feld UserDefined eingetragen werden.

• Werte im Bereich 10..30% der Zykluszeit sind sinnvoll.
• Änderungen in den DC-Einträgen werden erst nach Aktivierung der Konfiguration und Neustart des EtherCAT-Systems wirksam.

Anzeige der Shift-Zeit

Die Anzeige der individuellen Slave Shift-Zeiten ist über die erweiterten Einstellungen des Slaves möglich.

Weitere Einstellungen

• Continuous Runtime Measuring

Wenn aktiviert, misst TwinCAT zyklisch die Laufzeiten zwischen den EtherCAT Teilnehmern. Es wird empfohlen diese Einstellung beizubehalten. Eine Deaktivierung kann bei sehr kurzer Zykluszeit Raum für zyklische Daten schaffen, weil dann das NOP-Datagramm entfällt.

• SyncWindowMonitoring
  
  Wenn aktiviert, wird im EtherCAT DevState in Bit 12 angezeigt, ob alle DC-Teilnehmer ihre lokalen Uhren innerhalb des angegebenen Fensters halten.

Dafür wird ein zyklisches BRD-Kommando auf 0x092C (Systemzeit Differenz) verwendet.
Die Anzeige ist nur verwertbar, wenn der erste EtherCAT-Teilnehmer auch die Masterclock beinhaltet.

• Show DC System Time
  
  Wenn aktiviert, wird in den Eingängen des EtherCAT-Master die aktuelle DC-Zeit als Kopie aus der Masterclock angezeigt. Da der Auslesevorgang dem Feldbustransport unterliegt, sollte zur Gewinnung der aktuellen DC-Systemzeit PLC-Bausteinen der Vorzug gegeben werden.

Distributed Clocks Diagnose

Der TwinCAT System Manager bietet die Möglichkeit, im Online-Zustand eine vorläufige Aussage über die Qualität der aktuellen Echtzeit zu treffen.

Der Ablauf:

• Kommt eine Task zum Aufruf, berechnet sie mit der aktuellen Uhrzeit und der eigenen Zykluszeit den Zeitpunkt des nächsten Aufrufs.
• Wird sie dann zum nächsten Zyklus aufgerufen, vergleicht sie diesen Erwartungswert mit der tatsächlichen Uhrzeit.
• Die Abweichung wird wie u.a. dargestellt.

Ein System nach Abb. Online DC-Diagnose - Anpassungsbedarf ist beispielsweise für schnelle EtherCAT-Applikationen mit z. B. 100 µs Zykluszeit nicht geeignet und verlangt ggf. nach Anpassungen.