EtherCAT Distributed Clocks

Prinzip der Distributed Clocks

Der Begriff "Distributed Clocks" bezeichnet in der EtherCAT-Terminologie einen logischen Verbund aus verteilten Uhren. Mit den Distributed Clocks ist es bei dem Echtzeit-Ethernet-Protokoll EtherCAT möglich, in allen Busteilnehmern lokal eine in einem sehr engen Bereich gleiche Uhrzeit vorzuhalten. Falls ein EtherCAT-Slave die Distributed Clocks-Funktionalität unterstützt, beinhaltet er eine eigene Uhr, die nach dem Einschalten zunächst lokal arbeitet, basierend auf einem eigenen Taktgeber im EtherCAT-Slave (Quarz, Oszillator, ...). Im EtherCAT-Strang existiert ein ausgewählter EtherCAT-Slave, der die Referenzuhr/Reference Clock (M, siehe Abb. Distributed Clocks im EtherCAT-System) darstellt, auf die sich die Slave Clocks (S) der anderen Teilnehmer und der Steuerung synchronisieren. Diese Reference Clock stellt somit die Systemzeit/System Time dar. Diese Abstimmung und Synchronisierung wird automatisch und fortlaufend vom EtherCAT-Master vorgenommen, wenn dieser die Distributed Clocks Funktionalität unterstützt - wie z. B. der Beckhoff TwinCAT EtherCAT-Master. Dazu sendet der EtherCAT-Master in kurzen Abständen (so häufig, dass die Slave-Clocks innerhalb der spezifizierten Grenzen nicht auseinander laufen) ein spezielles EtherCAT-Datagramm, in das der EtherCAT-Slave mit der Reference Clock seine aktuelle Uhrzeit einträgt. Diese Information wird dann von allen anderen EtherCAT-Slaves mit Slave-Clock aus demselben umlaufenden Datagramm gelesen. Dies ist auf Grund der Ringstruktur von EtherCAT möglich, wenn die Reference Clock topologisch vor allen anderen Slave-Clocks angeordnet ist. Deshalb wird standardmäßig der erste Distributed Clocks fähige EtherCAT-Slave vom EtherCAT-Master als Reference Clock ausgewählt.

In einer EtherCAT-Konfiguration gibt es also einen EtherCAT-Master, der den Bus mit den angeschlossenen EtherCAT-Slaves betreibt und verwaltet. Von diesen EtherCAT-Slaves beinhaltet ein Teilnehmer die Reference Clock, alle anderen EtherCAT-Teilnehmer (also auch der EtherCAT-Master) stellen Slave-Clocks dar.

Das Handling der EtherCAT-Kommunikation und insbesondere der Distributed Clocks Funktionalität in einem EtherCAT-Slave übernimmt der EtherCAT-Slave-Controller (ESC). Dies ist ein elektronisches Bauteil (Chip), das als ASIC oder programmierbares FPGA o.ä. ausgeführt sein kann. Jeder EtherCAT-Slave verfügt über solch einen ESC, damit zyklische und azyklische Prozessdaten vom Master mit dem Slave über den EtherCAT-Feldbus ausgetauscht werden können. Dieser ESC kann direkt einfache Funktionen wie digitale Ein-/Ausgänge verwalten, er kann aber auch über serielle/parallele Interfaces an einen weiteren Prozessor im EtherCAT-Slave angeschlossen werden, der komplexere Aufgabe wie z. B. eine Antriebsregelung übernimmt. Insbesondere aber verwaltet der ESC die lokale Distributed Clocks Funktionalität mit den zugehörigen Aktionen, wenn der EtherCAT-Slave dieses Feature unterstützen soll.

In Abb. Beispielhafter Funktionsumfang eines ESC und seine Einbettung in einen typischen EtherCAT-Slave sei das Schema eines EtherCAT-Slaves dargestellt. Dazu die Einbettung des ESC in diesen mit einer Auswahl seiner Grundfunktionen.

Von der RJ45-Buchse werden die elektrischen Signale über den Trafo zum PHY (PHYsikalische Schnittstelle) geleitet. Er extrahiert aus dem codierten Ethernet-Signal die Nutzdaten und leitet sie dem ESC zur Verarbeitung weiter. Minimal verzögert (da im Durchlauf verarbeitet) wird das EtherCAT-Telegramm dann wieder über PHY und Buchse zum nächsten EtherCAT-Slave weitergeleitet. Der ESC parametriert sich beim Slave-Start selbsttätig mit Konfigurationsdaten aus einem EEPROM. Falls eine weitere CPU im Slave existiert, kann er mit dieser über Schnittstellen kommunizieren.

Folgende Features bietet die Distributed Clocks Einheit des ESC im Vollausbau (geräteimplementierungsabhängig):

• Clock Synchronisierung zwischen den EtherCAT-Slaves und dem Master
• synchrone Erzeugung von Output Signalen (Sync Signale)
• synchrones Einlesen von Input Signalen
• präzise Zeitstempelung von Eingangssignalen (Latch Signale)
• Erzeugung synchroner Interrupts

In Abb. Distributed Clocks im EtherCAT-System ist die Reference Clock (M) der erste Slave im EtherCAT-Strang mit Distributed Clocks Funktionalität nach dem EtherCAT-Master-IPC. Da jeder Slave auf dem Hin- und Rückweg eine geringe Verzögerung – sowohl im Teilnehmer (S) selbst als auch durch die dazwischen liegende Übertragungsstrecke – verursacht, sind die Laufzeiten (∆t) zwischen Reference Clock und jeweiliger Slave Clock bei der Synchronisierung der Slave Clocks zu berücksichtigen. Es ist also nicht zweckmäßig, einfach die lokale Uhrzeit der Reference Clock in alle nachfolgenden Slave-Uhren zu kopieren, sondern für jeden Slave ist ein eigener Offset-Wert in Abhängigkeit von mehreren Parametern zu berechnen.

Zur Messung der Offset-Zeiten sendet der EtherCAT-Master in der Startphase ein Broadcast-Read-Datagramm auf eine spezielle Adresse in allen ESC's, womit jeder Slave veranlasst wird, den Empfangszeitpunkt des Telegramms (bezüglich seiner lokalen Uhr) sowohl auf dem Hin- als auch auf dem Rückweg zu speichern. Diese gespeicherten Zeitpunkte werden dann vom Master eingelesen und entsprechend verrechnet. Diese Messzyklen finden für alle EtherCAT-Slaves mehrmals statt. Dadurch kann der EtherCAT-Master ein sehr exaktes Abbild der Topologie erstellen, bezogen auf die Frame-Verzögerungen zwischen den EtherCAT-Slaves.

Mit den bisher beschriebenen Aktionen ist ein synchroner Betrieb aller Distributed Clocks im EtherCAT-Verbund gegeben, z. B. in einer Produktionsanlage - hochgenaue relative Zeitangaben sind damit innerhalb der Applikation möglich. Der absolute Bezug zur globalen Realität wird über die Master Clock hergestellt - sie trägt i.d.R. eine Ausprägung der globalen Weltzeit (DCF77, GPS, Internetzeitserver, ...) oder eine andere, als systemübergreifend gültig bezeichnete Zeit (Netzwerkserver, PC-Uhr, BIOS-Uhr, IEEE1588, ...). So startet ein Beckhoff TwinCAT EtherCAT-Master mit den Angaben der lokalen PC-Uhr als Master Clock, um damit die Reference Clock zu initialisieren. Sowohl beim Systemstart als auch im weiteren Betrieb ist allerdings die Nachregelung der Reference Clock (M) nach einer Master Clock möglich, entweder über direkten Kontakt der Master Clock zur Steuerung (z. B. Netzwerkserver) oder über Einspeisung in einen speziellen EtherCAT-Slave (z. B. Beckhoff EL6692, EtherCAT-Bridge-Klemme).
Diese übergeordnete Master Clock verletzt nicht das Primat der Reference Clock, da die kurzfristige und für Echtzeitsteuerungen kritische Synchronisierung im sub-Millisekundenbereich allein von der Reference Clock bestimmt wird - die Synchronisierung der gesamten EtherCAT-Applikation inkl. Steuerungs-PC mit der Master Clock verläuft dagegen in längeren Intervallen.

Folgende Effekte müssen somit von der Distributed-Clocks-Regelung im EtherCAT-Master berücksichtigt werden:

• Offset-Kompensation jedes Slaves zur Reference Clock - nach dem Systemstart beginnen die lokalen Uhren ggf. mit unterschiedlichen Startwerten zu arbeiten.
• Offset-Kompensation der Reference Clock zur Master Clock - berücksichtigt beim Aufstart des Systems.
• Propagation Delay Measurement/Messung der Offset-Zeiten - abhängig von der Teilnehmeranzahl, Kabellängen, dynamischen Konfigurationsänderungen, usw.
• Drift compensation/Driftkorrektur - da jede Slave-Clock üblicherweise ihre eigene Taktquelle besitzt (Quarz, PLL, ...), bleiben Offset-Zeiten über einen längeren Zeitraum (Minuten, Tage) nicht konstant. Die Driftkorrektur fängt diesen Missstand ab.

Wenn bei einer Busunterbrechnung ein EtherCAT-Slave nicht mehr mit Synchronisierungsdatagrammen versorgt wird, kann er dennoch weiterhin durch seine lokale Uhr alle Aufgaben erfüllen. Die Distributed Clocks Regelung erfolgt ruckfrei - im Normalbetrieb und auch beim Wiedereinsetzen des EtherCAT-Verkehrs.

Zusammenfassung Technische Daten

Die Distributed Clock Funktion im EtherCAT-Slave-Controller (ESC) hat folgenden Eigenschaften:

• Einheit 1 ns
• universaler Nullpunkt 1.1.2000 00:00
• Umfang bis zu 64 Bit (ausreichend für 584 Jahre); manche EtherCAT-Slaves unterstützen jedoch nur einen Umfang von 32 Bit, d.h. nach ca. 4,2 Sekunden läuft das Register lokal über und beginnt wieder bei 0.
• Jede lokale Uhr wird vom EtherCAT-Master automatisch mit der Reference Clock im EtherCAT-System mit einer Genauigkeit < 100 ns synchronisiert, unabhängig von der Entfernung zwischen einzelnen EtherCAT-Slaves
• Beim Start des EtherCAT-Systems übernimmt der EtherCAT-Master i.d.R. die aktuelle Uhrzeit von einer Master Clock, z. B. der hardwarebasierten BIOS-Uhr des eigenen PCs. Dadurch ist der Zeitbezug zur aktuellen Weltzeit hergestellt. Mit dieser Zeit wird beim EtherCAT-Start die gewählte Reference Clock geladen, die diese Zeit dann i.d.R. selbsttätig auf der Basis ihres lokalen Taktgebers fortführt. Eine fortlaufende Synchronisierung der Reference Clock mit der Master Clock ist aber möglich.
• Die effektive Schrittweite der lokalen Uhr beträgt üblicherweise 10 ns - die verbleibende Stelle ("Einer") wird zur Regelung der Distributed Clocks benutzt.

Bis jetzt wurde die Distributed Clocks Funktion im ESC ohne Interaktion zur Umgebung betrachtet. Auf der Basis dieser lokalen/globalen Uhrzeit können nun aber zusätzliche Funktionen im EtherCAT-Slave realisiert werden.

Nutzbare Zusatzfunktionen des ESC

Die hochgenau synchronisierte Distributed Clocks Zeit wird vom ESC genutzt, mittels einer Capture/Compare-Einheit auf vorgebbare Zeiten oder Signale von außerhalb des ESC zu reagieren. Wie sich der ESC verhält, wird während des Startups durch die Konfiguration des EtherCAT-Slaves definiert und ist vom Anwender i.d.R. nicht veränderbar.

Aktion nach Zeitvorgabe: Compare - Sync0/1

Die Distributed Clock Einheit im ESC verfügt i.d.R. über 2 Interrupts, die zeitgesteuert ausgelöst werden können. Diese Interrupts heißen SYNC0 und SYNC1. In diesem Fall wäre die Compare-Einheit im ESC aktiv: stimmt die lokale Distributed Clocks Zeit mit einer vom Anwender definierten Vorgabezeit überein, löst der ESC einen Interrupt und die damit verbundenen Vorgänge aus. Dabei kann diese Vorgabezeit einmalig gesetzt werden, was dann auch eine einmalige Aktion im ESC zur Folge hat - Verwendung z. B. bei Beckhoff Timestamp Klemmen.
Der ESC kann aber auch selbsttätig neue Vorgabewerte nachladen, was in diesem Fall eine zyklische Abfolge von ESC-Aktionen zur Folge hat - Verwendung z. B. bei Beckhoff Oversampling Klemmen. Durch die beim ESC-Start z. B. aus einem Slave-eigenen EEPROM geladene Konfigurationsdaten ist parametrierbar, welche Aktion ein ESC beim Auftreten eines SYNC0/SYNC1-Signals letztendlich durchführt. Beispielsweise kann er dann Ausgangsdaten schreiben, Eingangsdaten einlesen oder die Kommunikation mit einem angeschlossenen Microcontroller beginnen.

Reaktion auf externes Signal: Capture - Latch 0/1

Wird ein ESC entsprechend konfiguriert, kann er beim Eintreten eines externen Ereignisses die aktuelle lokale Uhrzeit speichern, sie also mit einer Capture-Einheit ohne Zeitverzug in einen Puffer legen. Solche externen Ereignisse können sein: Ankunft des EtherCAT-Frames, Ende des EtherCAT-Frames, Flanke an einem dezidierten Pin des ESC, Kommunikation mit einem angeschlossenen Microcontroller und noch viele andere mehr.

Anschluss an eine externe Logik - SPI/µC parallel/IO/IRQ

Ein ESC ist nicht nur als Stand-Alone-Einheit zu verwenden, sondern verfügt über Schnittstellen, um mit anderen elektronischen Einheiten zu kommunizieren. Das kann z. B. ein Controller sein, der einen Leistungsantrieb regelt, oder eine Auswertungselektronik eines Drehgebers, s. Abb. Beispielhafter Funktionsumfang eines ESC und seine Einbettung in einen typischen EtherCAT-Slave. Auch die Kommunikation über diese Schnittstellen kann Distributed Clocks gesteuert erfolgen. Damit ist z. B. die Positionsabfrage an eine Drehgeberelektronik zeitlich im ns-Bereich äquidistant.

In Abb. Schnittstellen der Distributed Clocks Unit ist die Distributed Clocks Unit mit Ihren Schnittstellen und dem Zusammenwirken mit dem EtherCAT Bus schematisiert.

Anwendung der Distributed Clocks und Synchronität mit der Steuerung im PC

Durch den Distributed Clocks Verbund werden alle EtherCAT-Slaves, die dieses Feature unterstützen, mit einer Abweichung von <100 ns synchron betrieben. An einer Beispielanwendung mit Eingangskanälen soll dieses Prinzip verdeutlicht werden. Auf die Anwendung auf Ausgangskanäle wird im Anschluss eingegangen.

Im Folgenden wird an einem Beispiel mit drei Beckhoff EL1202-0010 die synchrone Erzeugung von SYNC-Signalen zum gleichzeitigen Lesen der Eingänge beschrieben. Andere Funktionen des ESC (Latch-Signale, Anschluß externer Logik) werden ausführlich in den entsprechenden Slave Dokumentationen beschrieben.

Distributed Clocks mit Eingangskanälen

In Abb. Beispielanwendung Distributed Clocks, Zykluszeit 100 µs betreibt der Master PC mit seiner PLC an einem EtherCAT-Master eine EtherCAT-Konfiguration mit 3 digitalen zweikanaligen Eingangsklemmen EL1202-0100 mit Distributed Clocks Unterstützung (die Distributed Clocks-Unterstützung wird durch Umstellung der EL1202 auf die EL1202-0100 im System Manager erreicht, siehe die entsprechende Dokumentation). Welche EtherCAT-Slaves noch eingesetzt werden und welche Entfernungen zwischen den Slaves liegen, spielt dabei keine Rolle. Die steuernde PLC und damit der EtherCAT-Feldbus werden mit 1 ms Zykluszeit betrieben, das heißt alle 1 ms werden die Eingangsklemmen EL1202-0100 nach ihren Eingängen abgefragt. In der EL1202-0100 wird nun die lokale Distributed Clock zum Samplen der beide Eingangskanäle verwendet: mit jedem SYNC-Interrupt liest der ESC direkt den anliegenden Eingangswert (0 oder 1) ein. Passiert dann kurz darauf der EtherCAT-Frame die Klemmen, legt jede EL1202-0100 ihre beiden Bits an der vorgesehenen Stelle im Frame ab. Durch die Verwendung der Distributed Clock erfolgt so das Samplen der Eingänge hochkonstant im fortlaufend gleichen Abstand mit einer Abweichung von < 100 ns. Außerdem lesen alle EL1202-0100 im gesamten EtherCAT-Verbund in der Standardeinstellung ihre Eingänge zum gleichen globalen Zeitpunkt ein, unabhängig von ihrer Anordnung. In einem Zeitdiagramm sieht das wie folgt aus:

In Abb. Zeitdiagramm Einlesen der EL1202-0100 ist der Ablauf von 4 kompletten I/O-Zyklen am Beispiel einer EL1202-0100 (vgl. Abb. Beispielanwendung Distributed Clocks, Zykluszeit 100 µs) dargestellt. Die Vorgänge während eines solchen Zyklus' lassen sich wie folgt aufschlüsseln:

• A, B: Abb. Zeitdiagramm Einlesen der EL1202-0100 ist grau unterteilt in eine Master- und eine Slave-Seite - dazwischen bewegen sich als Transportschicht die Ethernet-Frames.
• C: die nach rechts verlaufende Zeitachse ermöglicht eine zeitliche Zuordnung des Ablaufs der beschriebenen Aktionen.
• D: Die PC-eigene Echtzeituhr startet einen neuen Verarbeitungszyklus, die Zykluszeit sei 1 ms. Die Berechnung dauere hier 400 µs. Aus dem vorliegenden Eingangsprozessabbild wird durch den vorgegebenen Programmcode das Ausgangsprozessabbild berechnet.
• E: Nach der Berechnung stehen neue Ausgabedaten für den Feldbus zur Verfügung. Der EtherCAT-Frame (bzw. die EtherCAT-Frames, wenn mehrere) wird mit den Prozessdaten abgeschickt. Ein Ethernet-Frame ist je nach Datenumfang zwischen 7 und 128 µs lang. Es dauert also eine gewisse Zeit, bis er komplett auf dem Feldbus unterwegs ist, alle Slaves durchlaufen hat und dann wieder vollständig von der Netzwerkkarte empfangen wurde.
• F: Der EtherCAT-Frame durchläuft nun alle EtherCAT-Slaves, die vor der betrachteten EL1202-0100 liegen.
• G: Abhängig von der Anzahl der EtherCAT-Slaves, kommt nach einer gewissen Verzögerung von einigen µs der Frame an der EL1202-0100 vorbei, um die Eingangsdaten abzuholen (genauer: er wird vom ESC im Durchlauf verarbeitet). Diese Daten müssen nun bereits abholbereit zur Verfügung stehen.
• H: danach durchläuft der Frame noch alle nachfolgenden Slaves bis er wieder komplett vom Netzwerkport des PCs empfangen wurde.
• J: wird der nächste PLC-Berechnungszyklus von der Echtzeituhr gestartet, stehen somit aktuelle Eingangsdaten aus dem Feldbus zur Verfügung.

Es folgen nähere Erläuterungen zu den Vorgängen in der beispielhaften EL1202-0100:

• K: Damit die bei (G) in den Frame übertragenen Eingangsdaten rechtzeitig im ESC bereitstehen um in den Frame zu gelangen, müssen durch eine sinnvolle Vorlaufzeit (Lead Time, grün) vor der erwarteten Frame-Passage die Eingänge gelesen werden. Ansonsten würden ggf. veraltete Daten in den Frame eingeblendet. Das Lesen der physikalischen Eingänge wird von der Distributed Clocks Unit im ESC durch das SYNC-Signal ausgelöst.
  Diese Zeit kann als Sicherheitsabstand gewertet werden: je kürzer dieser Sicherheitsabstand ist, desto aktueller sind die Eingangsdaten. Wird diese Zeit zu kurz gewählt, besteht die Möglichkeit, dass die Eingangsdaten noch nicht zur Verfügung stehen, da der EtherCAT Frame die Klemme zu früh erreicht - es werden dann keinen neuen Prozessdaten in den Frame gekoppelt! Deshalb wird die Berechnung dieser Vorlaufzeit standardmäßig automatisch vom EtherCAT-Master durchgeführt.
• L: Vom Master mit seiner eigenen Echtzeituhr aus gesehen findet der klemmenlokale SYNC-Puls somit um eine globale Shift Time nach dem Echtzeit-Tick statt. Diese globale Shift Time wird einmalig beim EtherCAT-Aufstart berücksichtigt, denn ab dann laufen sowohl der Echtzeit-Tick im PC als auch die SYNC-Pulse in den EtherCAT-Slaves mit der konstanten Zykluszeit von (hier) 1 ms.
• Die globale Shift Time wird automatisch vom Beckhoff TwinCAT EtherCAT-Master nach den Randbedingungen wie Konfiguration, max. Programmrechendauer, Zykluszeit u.a. so berechnet, dass ein möglichst sicherer, aber dennoch aktueller Betrieb aller EtherCAT-Slaves gewährleistet wird.
• Die automatisch berechnete, globale Shift Time ist vom Anwender durch eine manuelleShift Time veränderbar, und zwar sowohl auf globaler Ebene für alle EtherCAT-Slaves, als auch Slave-lokal für jeden EtherCAT-Slave einzeln.

Nachführung der PC-Echtzeit

In Abb. Zeitdiagramm Einlesen der EL1202-0100 arbeiten 2 Zeiträume nebeneinander: der PC mit seinem Echtzeit-Tick und das Distributed Clocks System mit seinen verteilten Uhren in den EtherCAT-Slaves und dem EtherCAT-Master (der gleichwohl im PC sitzt) - dargestellt durch die grauen Trennlinien A//B.
Der Hintergrund für die Einführung einer zweiten Zeitbasis für die EtherCAT-Slaves mit den daraus abgeleiteten SYNC-Interrupts liegt in dem Jitter, mit dem die EtherCAT-Frames die einzelnen EtherCAT-Slaves passieren. Durch den Durchlauf durch die Slaves, die evtl. variable PLC-Laufzeit und die Qualität des Echtzeit-Ticks kann der Zeitpunkt, wann ein Frame vom PC abgeschickt wird und er dann endlich einen Slave passiert, im µs-Bereich variieren. Wenn Slave-lokale Ereignisse z. B. allein durch die Passage des Kommunikationsframes gestartet werden würden, ergäben sich so gleichermaßen variante Aktionen im Slave. Dies ist für hochgenaue Anwendungen nicht tolerabel. Durch die Einführung von Slave-lokalen geregelten Uhren besitzt nun jeder entsprechende EtherCAT-Slave ein hochgenaue lokale Zeitbasis mit einer Abweichung von < 100 ns zu allen anderen Uhren, was die Qualität aller zeitbasierten Aktionen um mehrere Größenordnungen verbessert.

Durch die beiden unterschiedlichen Zeitbasen würde jedoch schon nach kurzer Zeit die "Feldzeit" (Distributed Clocks/System Time) von der "PC-Zeit" (Betriebssystem/BIOS Uhr) abweichen - und der Abstand würde fortlaufend größer.

Deshalb greift der TwinCAT EtherCAT-Master in die Uhr des PCs ein und stellt diese zyklisch der EtherCAT Reference Clock nach - so bleiben dauerhaft der Echtzeit-Tick der Steuerung und die klemmenlokalen SYNC-Interrupts synchron mit der eingestellten/berechneten globalen Shift Time (Abb. Zeitdiagramm Einlesen der EL1202-0100, blau)

Abgleich auf eine externe Master Clock Soll ein solcherart geregeltes Automatisierungssystem auf Dauer mit einer äußeren Referenzuhr übereinstimmen (z. B. Weltzeit oder Netzwerk-lokale Zeit), sind z. B. entsprechende EtherCAT-Slaves zu verwenden, die den EtherCAT-Master über die Uhrzeit der Master Clock informieren oder die Master Clock ist direkt an der Steuerung anzuschließen. Der EtherCAT-Master unternimmt dann die entsprechenden Schritte zur Einhaltung einer dauerhaft konstant geringen Regeldifferenz zwischen Master und Reference Clock.

Berechnung der globalen Shift Time

In Abb. Zeitdiagramm Einlesen der EL1202-0100 ist eine blaue "globale Shift Time" angeben. Deren Wert bestimmt, wann in Relation zum Gesamtsystemverhalten der ESC z. B. eine SYNC0/1-Aktion lokal im Slave startet. Die globale Shift Time setzt sich aus verschiedenen, mitunter auch vom Anwender veränderbaren Elementen zusammen, s. Abb. Zeitliche Festlegung des Slave-lokalen SYNC-Pulses in Bezug auf den Echtzeit-Tick des Master-PCs.

Die Elemente der globalen Shift Time nach Abb. Zeitliche Festlegung des Slave-lokalen SYNC-Pulses in Bezug auf den Echtzeit-Tick des Master-PCs sind

• Application
  Die maximal erwartete Berechnungszeit für den Programmcode - nicht manipulierbar.
• Frame
  Die Framelänge des Ethernet-Frames (7..128 µs, auch mehrere Frames) - nicht manipulierbar.
• D
  Summe der Verzögerungen, die durch den Durchlauf des/der Frames durch die EtherCAT-Slaves generiert werden, inklusive der Jitter-Kalkulation.
• U
  User Shift Master - Shift Time die vom EtherCAT-Master je nach Baugruppe mit Standardwerten vorbelegt wird - vom Anwender manipulierbar.
  Ein- und Ausgabebaugruppen haben hier unterschiedliche Werte eingetragen
• S0
  User Shift Time im Slave - gewöhnlich 0, wird aber bei manchen EtherCAT-Slaves bereits standardmäßig mit Werten <>0 belegt, vom Anwender manipulierbar (s. jew. Slave Dokumentation)

Da sich die o.a. Elemente zur globalen Shift Time aufaddieren lassen, kann es u.U. sinnvoll sein, in den entsprechenden Dialogen negative Werte einzutragen - etwa um mit einer negativen Slave Sync0 Shift Time (s. Abb. Zeitliche Festlegung des Slave-lokalen SYNC-Pulses in Bezug auf den Echtzeit-Tick des Master-PCs) ein früheres Einlesen von Eingangssignalen auszulösen als vom EtherCAT-Master standardmäßig vorgesehen.

Distributed Clocks mit Ausgangskanälen

Im Wesentlichen unterscheidet sich die Logik die bei Ausgangskanälen angewendet wird nicht von der bereits beschriebenen bei Eingangskanälen. Der einzige Unterschied ist, dass der Slave-lokale SYNC-Takt nun meist zweckmäßigerweise nach der Passage eines datenbringenden EtherCAT-Frames zu erfolgen hat, statt wie bei den Eingangskanälen vor dem Frame. Deshalb findet die Berechnung der oben angegebenen globalen Shift Time (Abb. Zeitdiagramm Einlesen der EL1202-0100, blau) für Ein- und Ausgangs-Slaves getrennt statt. Die standardmäßig ermittelte globale Shift Time für die Gruppe der Ausgangsbaugruppen ist damit größer als die, die für die Gruppe der Eingangsbaugruppen berechnet wird. Beide liegen jedoch in dem sinnvollen Bereich von 0..100% der EtherCAT-Zykluszeit.

In den folgenden Abschnitten wird nun der Zugriff auf die Distributed Clocks-Einstellungen aus dem TwinCAT System Manager heraus erklärt.