A A A
| Sitemap | Kontakt | Impressum | Datenschutz
ETZ Logo VDE Verlag Logo

Synchronisation von mehreren Achsen über Echtzeitnetzwerke

Bei der Synchronisation mehrerer Achsen über deterministische Ethernet-Protokolle, wie Ethercat, sind verschiedene Wege zu beschreiten (Bild: stock.adobe.com_ fotomek)

Bei der Synchronisation mehrerer Achsen über deterministische Ethernet-Protokolle, wie Ethercat, sind verschiedene Wege zu beschreiten (Bild: stock.adobe.com_ fotomek)

Echtzeitfähige, deterministische Ethernet-Protokolle, wie Ethercat, ermöglichen den synchronisierten Betrieb von Mehrachsen-Bewegungssteuerungen. Hierbei sind zwei verschiedene Aspekte zu berücksichtigen. Synchronisiert werden muss erstens die Übertragung von Befehlen und Sollwerten zwischen den verschiedenen Knoten zu einem gemeinsamen Takt sowie zweitens die Ausführung der Steuerungsalgorithmen und die Rückmeldungen zum selben Takt. Gerade die zweite Art der Synchronisation wurde in der Vergangenheit häufig vernachlässigt.

01  Beispielhafter Aufbau eines ­Bewegungssteuerungssystems mit ­mehreren Synchronisationsbereichen

01  Beispielhafter Aufbau eines ­Bewegungssteuerungssystems mit ­mehreren Synchronisationsbereichen

02  Die Auswirkung eines zeitlichen Verzugs auf die Posi­tions­genauigkeit

02  Die Auswirkung eines zeitlichen Verzugs auf die Posi­tions­genauigkeit

03  Traditionelle (oben) und neue (unten) Motion-Control-Topologien

03  Traditionelle (oben) und neue (unten) Motion-Control-Topologien

In einem beispielhaften zweiachsigen Bewegungssteuerungssystem (Bild 1) sendet der Master über ein Echtzeitnetzwerk Befehle und Sollwerte an zwei Servoregler, die im Netzwerk jeweils als Slave-Knoten fungieren. Häufig werden die Slave-Knoten zum Master synchronisiert, indem in ­jedem Knoten ein lokaler, synchronisierter Takt vorgehalten wird. Dadurch sind alle an das Echtzeitnetzwerk angeschlossenen Netzwerk-Controller zueinander synchronisiert.

Meist gibt es zwischen Netzwerk- und Motor-Controller zwei Interrupt-Leitungen. Die erste weist den Motor-Con­troller an, Einga­bewerte zu erfassen und auf das Netzwerk zu ­geben, während die zweite ihm signalisiert, Daten aus dem Netzwerk ­einzulesen. Dies sorgt für einen synchronisierten Datenaustausch zwischen Motion-Controller und ­Motor-Controller mit hoher zeitlicher Genauigkeit. Zusätzlich ist es aber notwendig, dass die Motor-Controller synchronisiert auf die synchron übertra­genen Daten reagieren.

Die IO der Motor-Con­troller ­erweisen sich dabei häufig als Problem, da die dabei verwendeten PWM-Timer und ADC mit jeweils eigenen Laufzeiten und Quantisierungen arbeiten. Ganz gleich, wie eng der Datenaustausch im Echtzeitnetzwerk auch synchronisiert sein mag, die Synchronisation wird stets durch die zeitliche Quantisierung des PWM-Timers bestimmt. In jedem Fall entsteht eine zeitliche Unsicherheit, die meist im Bereich zwischen 50 µs und 100 µs liegt und bis zu einer PWM-Periode betragen kann.

In Bild 1 ist erkennbar, dass es in dem System die drei Synchronisationsbereiche A, B und C gibt, die nicht miteinander verbunden sind. Es gibt zwischen ihnen keine Synchronisa­tion, und die ­variable Unsicherheit beträgt bis zu einer PWM-Periode.

04  Ein IO-Event-Scheduler verbindet die verschiedenen Sync-Bereiche miteinander

04  Ein IO-Event-Scheduler verbindet die verschiedenen Sync-Bereiche miteinander

05  Schema für die Implementierung der Synchronisation

05  Schema für die Implementierung der Synchronisation

06  Prinzip der Erzeugung der Synchronisations-Ereignisse für die IO

06  Prinzip der Erzeugung der Synchronisations-Ereignisse für die IO

Auswirkungen der Synchronisations-Unsicherheit

In Mehrachsen-Servosystemen, wie Robotern oder Maschinen, hat der wechselnde zeitliche Versatz unmittelbare, messbare Auswirkungen auf die dreidimensionale Positioniergenauigkeit. Das verdeutlicht auch ein ein­faches Bewegungsprofil (Bild 2), bei dem die Solldrehzahl des Motors (rote Kurve) angehoben und wieder reduziert wird. Kommt es im System zu Verzögerungen, hinkt die Ist-Drehzahl (blaue Kurve) hinter dem Sollwert her, was zu ­einem Posi­tionsfehler Δθ führt. Die Auswirkungen einer konstanten ­Verzögerung lassen sich durch entsprechende Kompensation noch ­minimieren. Bei variablen Verzögerungen ist dies jedoch nicht möglich, zumal dann auch die Regelkreis­verstärkung variabel ist, was die Abstimmung des Regelkreises erschwert.

Bei einem traditionellen Bewegungskonzept (Bild 3 oben) schickt ein Motion-Controller (meist eine SPS) Soll-Positionen (θ*) über ein Echtzeitnetzwerk an einen Motor-Controller, ­welcher aus drei verschachtelten Regelkreisen besteht. Der innere Regelkreis regelt das Drehmoment sowie den Strom (T/i), der mittlere die Drehzahl (ω) und der äußere die ­Position (θ). Bei dieser Topologie erfolgt die Synchronisa­tion der Achsen durch den Austausch von Positions-Soll­vorgaben zwischen Motion- und Motor-Controllern. Die Synchronisation der einzelnen Knoten mithilfe der Sollwertvorgaben ergibt meist akzeptable Performance-Resultate, auch wenn das Netzwerk und die IO verschiedenen Synchro­nisationsbereichen angehören.

07  Die wesentlichen Hardware-Komponenten im Versuchsaufbau

07  Die wesentlichen Hardware-Komponenten im Versuchsaufbau

08  Anzeige der Generierung der Synchronisations-Ereignisse für die IO

08  Anzeige der Generierung der Synchronisations-Ereignisse für die IO

Neuerdings geht der Trend dahin, die Regelkreise aus den Motor-Controllern auszulagern und in einen leistungsfähigen Motion-Controller auf der Master-Seite des Netzwerks zu übertragen (Bild 3 unten). Im Echtzeitnetzwerk werden dann Soll-Spannungen (v*) für den Motor-Controller sowie Ist-Werte (i, ω, θ) für den Motion-Controller übertragen. Ein Vorteil dieser Architektur ist die gute Skalierbarkeit: Achsen lassen sich nach Belieben hinzufügen oder entfernen, ohne dass die Verarbeitungsleistung des Motor-Controllers wichtig ist. Zudem ist eine höhere Genauigkeit möglich, da die Planung der Bewegungsbahn und die Bewegungs­steuerung an einem zentralen Ort erfolgen. Auf der anderen Seite geht durch die Auslagerung der Regelungsalgorithmen aus dem Motor-Controller die enge Synchronisation von Codeausführung und IO verloren. Dies ist umso pro­blematischer, je größer die Bandbreite des Regelkreises ist. Insbesondere der Drehmoment-Strom-Regelkreis ist hinsichtlich der Synchronisation höchst sensibel.

Eventkalender für IO

Werden die IO sämtlicher Achsen zum Netzwerk synchronisiert, gibt es nur noch einen Synchronisations­bereich. Hierzu wird das Konzept des „IO Event Schedulers“ (Bild 4) eingeführt. Dieser befindet sich zwischen Netzwerk- sowie Motor-Controller und erzeugt Sync/Reset-Impulse für alle Peripheriefunktionen, die damit synchron zum Netz­werk-Traffic gehalten werden. Der IO Event ­Scheduler ­berücksichtigt dabei die individuellen Besonderheiten der einzelnen IO beim Erzeugen der jeweiligen ­Triggersignale. So werden alle Triggersignale auf ein gemeinsames Frame-Sync-Signal bezo­gen. Außerdem erhält jedes Trigger­signal eine bestimmte Verzögerung bzw. einen Offset, um beispielsweise die Umwandlungszeit eines ADC oder die Gruppenlaufzeit eines SINC-Filters zu berücksichtigen. Drittens wird die Reaktionszeit der IO-Funktion einkal­kuliert. Der Frequenzvervielfacher ist vorhanden, weil der Scheduler in den meisten Systemen mehrere Trigger-­Impulse pro Frame generieren muss.

Implementiert und getestet wurde das geschilderte ­Synchronisationsverfahren mit dem in Bild 5 dargestellten vernetzten Bewegungssteuerungssystem. Hauptbestandteile sind der Netzwerk-Master, eine SPS CX2020 von Beckhoff sowie der Motor-Controller bestehend aus dem mehrprotokollfähigen Echtzeit-Ethernet-Switch Fido5200 und einem ADSP-CM408 – beide von Analog Devices.

Der Fido5200 kann nicht nur die IO-Funktionen eines einzelnen Slave-Knotens, sondern aller Slave-Knoten im ­gesamten Netzwerk synchronisieren. Er enthält eine konfigurierbare Timer Control Unit (TCU), die sich zur Implementierung fortschrittlicher Synchronisations-Schemata für verschiedene Industrial-Ethernet-Protokolle eignet. Über seine beiden Ethernet-Ports ist er an zwei PHY ­angeschlossen, sodass er sowohl für lineare als auch für ­ringförmige Netzwerke geeignet ist. Der auf ­einem ARM M4F-Core ­basierende applikationsspezifische Prozessor ADSP-CM408 implementiert Steuerungs- und Applikations-Funktionen. Zu seiner Peripherieausstattung gehört unter anderem eine flexible Trigger Routing Unit (TRU), mit der sich die Synchronisation aller Peripheriefunktionen zum Netzwerk ­sicherstellen lässt. So leitet die TRU die von der TCU des Fido5200 erzeugten Triggersignale an die zeitkritischen Peripheriefunktionen des ADSP-CM408 weiter, also an den Pulsweiten-Modulator, das SINC-Filter für die Messung des Phasenstroms, den ADC und das Absolutencoder-­Interface (Bild 6).

Experimentelle Ergebnisse

Die SPS in dem Versuchsaufbau (Bild 7) wurde für eine Task Time von 200 µs eingerichtet und legt auch die Framerate des Ethercat-Netzwerks fest. Der Motor-Controller ­arbeitet mit ­einer PWM- und Aktualisierungsrate von 100 µs (10 kHz). Deswegen ­müssen auch die Synchroni­sations-Impulse diese Rate aufweisen. Das ­Ergebnis ist in Bild 8 dargestellt.

Das „Data Ready“-Signal zeigt, dass der Fido5200 die Netzwerkdaten alle 200 µs – was der Ethercat-Framerate entspricht – für die Motor-Control-Applikation bereitstellt. Das ebenfalls erzeugte Signal „PWM SYNC“ sorgt für die Synchronität der IO im Motor-Controller zum Netzwerk-Traffic. Wegen der PWM-Periode von 100 µs entfallen zwei „PWM-SYNC“-Impulse auf ein Ethercat-Frame. Die b­eiden unten in Bild 8 dargestellten Signale sind die high- und ­low-seitigen PWM-Signale für eine der Motorphasen. Wie man sieht, sind die PWM-Signale zum Netzwerk-Traffic ­synchronisiert. Somit bewirkt das hier vorgestellte Verfahren eine durchgängige Synchronisation vom Netzwerk-Master bis zu den Motorklemmen, und dies auch über mehrere Achsen hinweg. Zusätzliche Achsen lassen sich leicht hin­zufügen, und die Synchronisation ist auf den jeweiligen Motor-Controller abstimmbar. (no)

www.beckhoff.de
www.analog.com


Autoren:
Jens Sorensen ist Senior Staff Engineer Motor Control bei Analog Devices in San Diego, Kalifornien/USA.
Dara O’Sullivan ist Systems Engineer bei Analog Devices in Cork/Irland.
Christian Aaen ist Software Systems Design Engineer bei Analog Devices in Albuquerque, New Mexico/USA.