Mehrachsige Bewegungssteuerung via Echtzeit-Netz

Für mehrachsige Bewegungen mit hoher Präzision und Dynamik gewährleistet das hier vorgestellte Verfahren die durchgängige Synchronisation vom Netzwerk-Master bis zu den Motorklemmen über mehrere Achsen hinweg.

Echtzeitfähige, deterministische Ethernet-Protokolle wie EtherCAT ermöglichen den synchronisierten Betrieb von Mehrachsen-Bewegungssteuerungen. Hierbei gibt es zwei verschiedene Aspekte: Erstens muss die Übertragung von Befehlen und Sollwerten zwischen den verschiedenen Knoten zu einem gemeinsamen Takt synchronisiert werden. Zweitens sind die Ausführung der Steuerungsalgorithmen und die Rückmeldungen zum selben Takt abzugleichen. Gerade die zweite Art von Synchronisation wurde in der Vergangenheit häufig vernachlässigt.

Die Beschreibung eines Problems

In Bild 1 ist eine zweiachsige Bewegungssteuerung abgebildet. Der Master des Systems sendet über ein Echtzeit-Netzwerk seine Befehle und Sollwerte an zwei Servoregler, die im Netzwerk jeweils als Slave-Knoten fungieren. Eine häufig verwendete Methode zur Synchronisation der Slave-Knoten zum Master ist es, in jedem Knoten einen lokalen und synchronisierten Takt vorzuhalten, sodass alle an das Echtzeit-Netzwerk angeschlossenen Netzwerk-Controller zueinander harmonisiert sind.

Bildergalerie

Meist gibt es zwei Interrupt-Leitungen zwischen Netzwerk- und Motor-Controller. Die erste weist den Motor-Controller an, Eingabewerte zu erfassen und in das Netzwerk zu geben, während die zweite Interrupt-Leitung den Motor-Controller veranlasst, Daten aus dem Netzwerk einzulesen. So wird ein synchronisierter Datenaustausch zwischen Motion-Controller und Motor-Controller erreicht, wobei eine sehr hohe zeitliche Genauigkeit erzielbar ist. Zusätzlich ist es aber notwendig, dass die Motor-Controller synchronisiert auf die simultan übertragenen Daten reagieren.

Hier erweisen sich die I/Os der Motor-Controller als das Problem, denn die dabei verwendeten PWM-Timer und ADCs arbeiten mit jeweils eigenen Laufzeiten und Quantisierungen. In Bild 2 sind die Gate-Treibersignale zu sehen, die ein PWM-Timer für den Wechselrichter erzeugt. Hierzu wird das Bezugssystem M_x mit einem Auf-/Abwärts-Zähler verglichen. Wird M_x vom Steuerungsalgorithmus geändert, kommt das neue Tastverhältnis erst in der nächsten PWM-Periode zum Tragen.

Ganz gleich, wie eng der Datenaustausch im Echtzeit-Netzwerk auch synchronisiert sein mag, bestimmt die zeitliche Quantisierung des PWM-Timers doch stets die Harmonisierung. In jedem Fall entsteht eine zeitliche und bis zu einer PWM-Periode betragende Unsicherheit, die meist im Bereich zwischen 50 und 100 µs liegt.

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 Synchronisation, und die variable Unsicherheit beträgt bis zu einer PWM-Periode.

Einfluß der Sync-Unsicherheit auf die Applikation

In mehrachsigen Servosystemen (beispielsweise bei Robotern oder Maschinen) hat der wechselnde zeitliche Versatz unmittelbare, messbare Auswirkungen auf die dreidimensionale Positioniergenauigkeit. Das einfache Bewegungsprofil in Bild 3 verdeutlicht dies. Die Solldrehzahl des Motors (rote Kurve) wird angehoben und wieder reduziert. Kommt es im System zu Verzögerungen, hinkt die Ist-Drehzahl (blaue Kurve) hinter dem Sollwert her, was zu einem Positionsfehler (Δ) führt.

In Bild 4 wird der Soll-Bewegungsverlauf durch entsprechende X/Y-Koordinaten vorgegeben, jedoch führt eine Verzögerung zu einem Zeitfehler bei den Koordinaten für die Y-Achse. Die Auswirkungen einer konstanten Verzögerung mögen sich durch entsprechende Kompensation noch minimieren lassen. Bei variablen Verzögerungen ist dies jedoch nicht möglich, zumal dann auch die Regelkreisverstärkung variabel ist, was die Abstimmung des Regelkreises erschwert.

Die Synchronisation und neue Regelungstopologien

Im Bild 5 ist oben das traditionelle Bewegungskonzept dargestellt. Der Motion-Controller (meist eine speicherprogrammierbare Steuerung) schickt Soll-Positionen über ein Echtzeit-Netzwerk an einen Motor-Controller, welcher aus drei verschachtelten Regelkreisen besteht. Der innere Regelkreis verantwortet das Drehmoment und den Strom (T/i), der mittlere die Drehzahl (w) und der äußere die Position. Bei dieser Topologie erfolgt die Synchronisation der Achsen durch den Austausch von Positions-Sollvorgaben zwischen Motion- und Motor-Controllern. Die Synchronisation der einzelnen Knoten mithilfe der Sollwertvorgaben ergibt meist ein akzeptables Performance-Resultat, auch wenn das Netzwerk und die I/Os verschiedenen Synchronisationsbereichen angehören.

Neuerdings geht der Trend dahin, die Regelkreise aus den Motor-Controllern auszulagern und in einen leistungsstarken Motion-Controller auf der Master-Seite des Netzwerks zu übertragen, wie es in Bild 5 unten zu sehen ist. Im Echtzeit-Netzwerk werden dann Soll-Spannungen (v*) für den Motor-Controller und Ist-Werte für den Motion-Controller übertragen. Der erste Vorteil dieser Architektur ist die gute Skalierbarkeit: Achsen können nach Belieben hinzugefügt oder entfernt werden, ohne dass die Verarbeitungsleistung des Motor-Controllers wichtig ist.

Zweitens ist eine höhere Genauigkeit möglich, da die Planung der Bewegungsbahn und die Bewegungssteuerung an einem zentralen Ort erfolgen. Nachteilig ist hingegen, dass durch die Auslagerung der Regelungsalgorithmen aus dem Motor-Controller die enge Synchronisation von Code-Ausführung und I/O verloren geht. Dies ist umso problematischer, je größer die Bandbreite des Regelkreises ist. Insbesondere der Drehmoment/Strom-Regelkreis ist hinsichtlich der Synchronisation höchst sensibel.

Ein Vorschlag zur Problemlösung

Werden die I/Os sämtlicher Achsen zum Netzwerk synchronisiert, gibt es nur noch einen Synchronisationsbereich. Hierzu wird das Konzept des „I/O Event Schedulers“ (Bild 6) eingeführt, der sich zwischen Netzwerk- und Motor-Controller befindet und Sync/Reset-Impulse für alle Peripheriefunktionen erzeugt, die damit synchron zum Netzwerk-Traffic gehalten werden.

Der I/O Event Scheduler berücksichtigt dabei die individuellen Besonderheiten der einzelnen I/Os beim Erzeugen der jeweiligen Trigger-Signale. Erstens werden alle Trigger-Signale auf ein gemeinsames Frame-Sync-Signal bezogen. Zweitens 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 I/O-Funktion einkalkuliert (Bild 7). Der Frequenzvervielfacher ist vorhanden, weil der Scheduler in den meisten Systemen mehrere Trigger-Impulse pro Frame generieren muss. In Bild 7 ist unten ein exemplarisches Timing-Diagramm für die PWM-Synchronisation zu sehen.

Die Implementierung der Lösung

Implementiert und getestet wurde das geschilderte Synchronisationsverfahren mit dem in Bild 8 dargestellten vernetzten Bewegungssteuerungssystem. Hauptbestandteile sind der Netzwerk-Master, eine speicherprogrammierbare Steuerung des Typs Beckhoff CX2020, und 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 I/O-Funktionen eines einzelnen Slave-Knotens synchronisieren, sondern auch Slave-Knoten im gesamten Netzwerk. 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 PHYs (PHY1 und PHY2) angeschlossen, sodass er sowohl für lineare als auch für ringförmige Netzwerke geeignet ist.

Der auf einem ARM-M4F-Kern basierende applikationsspezifische Prozessor ADSP-CM408 implementiert Steuerungs- und Applikationsfunktionen. 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 Trigger-Signale 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 9 verdeutlicht das zum Synchronisieren der I/Os verwendete Prinzip.

Der Versuchsaufbau ist in Bild 10 zu sehen. Die speicherprogrammierbare Steuerung wurde hier für eine Task Time von 200 µs eingerichtet, die auch die Frame-Rate des EtherCAT-Netzwerks festlegt. Der Motor-Controller arbeitet mit einer PWM- und Aktualisierungsrate von 100 µs (10 kHz), weshalb auch die Synchronisationsimpulse diese Rate aufweisen müssen. Das Ergebnis ist in Bild 11 dargestellt.

Das Data Ready-Signal zeigt an, wann der FIDO5200 Netzwerkdaten für die Motor-Control-Applikation bereitstellt. Es wird alle 200 µs gesetzt, was der EtherCAT-Frame-Rate entspricht. Das ebenfalls vom FIDO5200 erzeugte Signal PWM SYNC sorgt für die Synchronität der I/Os im Motor-Controller zum Netzwerk-Traffic. Wegen der 100 µs betragenden PWM-Periode entfallen zwei PWM SYNC-Impulse auf ein EtherCAT-Frame.

Die beiden unten in Bild 11 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 hinzufügen, und die Synchronisation ist auf den jeweiligen Motor-Controller abstimmbar.