Synchronisierung TwinCAT PLC / EtherCAT

[fampy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen.

Ich beschäftige mich gerade ganz neu mit der SPS-Programmierung sowie mit EtherCAT. Leider hat sich die ganze Thematik mir bisher noch nicht ganz erschlossen. Aber nun zu meiner Frage:

Ist es möglich, eine TwinCAT PLC-Task mit den EtherCAT-Frames zu synchronisieren? D.h. meine Task soll immer ausgeführt werden sobald ein neuer EtherCAT-Frame empfangen wurde. Oder kann ich vielleicht innerhalb einer Task auf den Empfang von neuen Daten triggern?
Der Zusammenhang zwischen Task und Frame ist für mich noch irgendwie verwirrend...

Viele Grüße

 

[RobiHerb]

synchron

Ich überblicke zwar nicht das System aber im Prinzip müsste der PC und mindestens 1 Busteilnehmer über DC (Distributed Clock) synchronisiert sein. Der Busteilnehmer muss eine Klemme, die DC unterstützt, oder ein "Intelligenter" Antrieb sein.

Dann im Konfigurator DC aktivieren. Ich gehe davon aus, dass der PC die EtherCAT Telegramme sendet, somit sind die Teilnehmer mit der PLC Task synchronisiert, die das Senden durchführt.

(Ich kenne mehr den ACONTIS/Hilscher EtherCAT Stack als das Beckhoff System, somit hier nur das Prinzip erklärt)

 

[Neals]

Zuviel Werbung?
-> Hier kostenlos registrieren

Keine Garantie, das ich richtig liege...

... aber ich meine, die PLC stößt doch EtherCAT an und nicht umgedreht.
Nach jedem PLC-Zyklus, wird ein EtherCAT-Telegramm durchlaufen, dann der nächste PLC-Zyklus und daraufhin wieder EtherCAT.

Wenn du die Zykluszeit der PLC auf 100ms setzt, gibt der EtherCAT-Watchdog fehler, da der Bus nicht oft genug getriggert wird.

 

[bonatus]

... aber ich meine, die PLC stößt doch EtherCAT an und nicht umgedreht.
Nach jedem PLC-Zyklus, wird ein EtherCAT-Telegramm durchlaufen, dann der nächste PLC-Zyklus und daraufhin wieder EtherCAT.

Auf welche der 4 möglichen Tasks wird den geschaut? Auf die schnellste?

 

[brcc]

Prinzipiell läuft der EtherCAT-Zyklus immer synchron mit den Tasks, asynchron/freilaufend ist unter TwinCAT nicht vorgesehen. Das ist auch unabhängig davon ob DC aktiv/im System ist oder nicht.
In der Standardeinstellung wird der IO-Update nach der PLC/NC ausgelöst, es sei denn "IO am Taskanfang" wird in der Task aktiviert. Sind mehrere unterschiedlich schnelle Tasks vorhanden (und ihre IO-Variablen auch im SysMan den unterschiedlichen Tasks zugeordnet [default sind sie das nämlich nicht!]) werden mehrere EtherCAT-Telegramme erzeugt, die in entsprechenden Abständen gesendet werden. Spätestens dann empfiehlt sich aber die Einstellung "Automatic Priority Management", damit schnellere Tasks die langsameren unterbrechen können.
Gruß
brcc

 

[fampy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute. Danke für die bisherigen Antworten. Habe jetzt endlich mal wieder Zeit mich mit dem Thema zu beschäftigen.
Die Tasksynchronität verwirrt mich aber immer noch ein bißchen. Ich fasse mal in meinen eigenen Worten zusammen was ich bisher gelernt habe:
Ich konfiguriere eine Task (Intervall z.B. 250us). Der System Manager bzw. EtherCAT-Master verschickt daraufhin alle 250us einen EtherCAT-Frame.
Wenn meine Task aufgerufen wird, stehen mir die Prozessdaten des letzen Frames zur Verfügung. Nach der Bearbeitung der Task (letzte Codezeile)wartet der Master bis die 250us verstrichen sind und triggert daraufhin den Versand. Die im jeweiligen Taskzyklus bestimmten Ausgangdaten erreichen die Slaves somit frühestens nach 250us und spätestens 500us.
Ein EtherCAT-Slave kann nun auf die Prozesswerte reagieren. Beim nächstem einkommenden Frame (zwischen 500 und 750 us) fügt dieser die veränderten Daten dem Frame hinzu. Auf diese Daten kann dann im darauffolgenden PLC-Zyklus (also nach 750us) zugegriffen werden.

Bin ich soweit noch richtig?

Ich muss das Timing so genau betrachten, weil ich die Antwortzeit (Reaktionszeit) in meinem System bestimmen will. Hierzu will ich einen Wert auf einem EtherCAT-Slave setzen. Dieses "spiegelt" den Wert und überträgt ihn zurück.

Danke und viele Grüße

 

[RobiHerb]

Im Prinzip JEIN

Hallo Leute. Danke für die bisherigen Antworten. Habe jetzt endlich mal wieder Zeit mich mit dem Thema zu beschäftigen.
Die Tasksynchronität verwirrt mich aber immer noch ein bißchen. Ich fasse mal in meinen eigenen Worten zusammen was ich bisher gelernt habe:
Ich konfiguriere eine Task (Intervall z.B. 250us). Der System Manager bzw. EtherCAT-Master verschickt daraufhin alle 250us einen EtherCAT-Frame.
Wenn meine Task aufgerufen wird, stehen mir die Prozessdaten des letzen Frames zur Verfügung. Nach der Bearbeitung der Task (letzte Codezeile)wartet der Master bis die 250us verstrichen sind und triggert daraufhin den Versand. Die im jeweiligen Taskzyklus bestimmten Ausgangdaten erreichen die Slaves somit frühestens nach 250us und spätestens 500us.
Ein EtherCAT-Slave kann nun auf die Prozesswerte reagieren. Beim nächstem einkommenden Frame (zwischen 500 und 750 us) fügt dieser die veränderten Daten dem Frame hinzu. Auf diese Daten kann dann im darauffolgenden PLC-Zyklus (also nach 750us) zugegriffen werden.

Bin ich soweit noch richtig?

Ich muss das Timing so genau betrachten, weil ich die Antwortzeit (Reaktionszeit) in meinem System bestimmen will. Hierzu will ich einen Wert auf einem EtherCAT-Slave setzen. Dieses "spiegelt" den Wert und überträgt ihn zurück.

Danke und viele Grüße

Zwischen den einzelnen Implementationen können Welten liegen!!!!

Im Prinzip kann in das laufende Telegramm "gleichzeitig" gelesen und geschrieben werden! Wenn der Master sein eigenes Telegramm wieder empfängt, (wir haben zumindest logisch einen Ring) können da schon die Antworten der anderen drin sein!

Das wäre zumindest technisch mit schnellen Klemmen machbar, ob der spezielle Hersteller das implementiert hat, muss man ab besten selber überprüfen.

1. Verzögerung: Die Teilnehmer sind per DC synchronisiert, dann kommt das Telegramm (wenn optimiert implementiert und parametriert) erst beim nächsten Tick zu Ausgabe und im übernächsten Tick kommt die Rückmeldung zurück. Zu beachten ist, dass der Tick und das Telegramm mindestens 20% im Zyklus gegeneinander versetzt sein sollten, sonst ist keine saubere Synchronisation (Jitter ca < 100 nsec) möglich.

2.Verzögerung: EtherCAT ist etwas recht kompliziertes und so kommt das System nicht zwangsweise "aus einer Hand". Sprich im System können Fremdmodule (beispielsweise Hilscher) eingeflossen sein, die Schnittstellen zu den Antriebsreglern z.B. implementieren und eigene Prozessoren mit Verarbeitungs Zeiten benötigen.

Da kann es dann so sein:

Tick1 SPS sendet und Modul emfängt,
Tick2 Modul sendet interpretiertes Telegramm an den Regler
Tick3 Regler regelt auf im Tick1 gesendeten Sollwert und
Tick4 gibt die Modul die Korrekturwerte, welche
Tick5 vom Modul an die SPS weitergegeben wird ...

3.Verzögerung: manche Einheiten können gar nicht so schnell, die ignorieren z.B. einfach jedes 2. Telegramm!

 

[Neals]

Ich konfiguriere eine Task (Intervall z.B. 250us). Der System Manager bzw. EtherCAT-Master verschickt daraufhin alle 250us einen EtherCAT-Frame.

Das ist meines erachtens so nicht richtig.

Der Echtzeit-Kernel triggert alle 250us das PLC Programm, welches dann die Hardware-Eingänge ausließt, den Code abarbeitet, Hardware-Signale beschreibt und dann wird ein EtherCAT-Frame versendet. Wenn der Frame bis zum nächsten 250us Tick bereits wieder angekommen ist, arbeitet der nächste PLC-Zyklus bereits mit den neuen Werten.

Nehmen wir mal an, du hast nen längeren Bus und das Telegramm braucht 400us bis es wieder beim Master ankommt. Dein PLC Code braucht gerade mal 150us bis es abgearbeitet ist.

0us: 1. Tick -> PLC start
150us: PLC fertig -> EtherCAT-Frame 1 start
250us: 2. Tick -> PLC start
400us: PLC fertig -> EtherCAT-Frame 2 start
500us: 3. Tick -> PLC start
550us: EtherCAT-Frame 1 zurück
650us: PLC fertig -> EtherCAT-Frame 3 start
750us: 4. Tick -> PLC start, Daten von EtherCAT-Frame 1
800us: EtherCat-Frame 2 zurück
900us: PLC fertig -> EtherCAT-Frame 4 start
1s: 5. Tick -> PLC start, Daten von EtherCAT-Frame 2

Es kann also schon länger brauchen, bis die Daten da sind, wenn du eine so schnelle Zykluszeit wählst.

Wie RobiHerb geschrieben hat, heißt das sogar, das für komplexere EtherCAT-Slaves, das diese eventuell erst im 4. Frame eine Antwort geben. Von standard Eingangs-Klemmen bekommst meistens jeden Zyklus den aktuellen Wert.

Kennst du den Test von Beckhoff: "EtherCAT nachgemessen"? Ist auf Seite 12.