Eventkalender für IO
Werden die IO sämtlicher Achsen zum Netzwerk synchronisiert, gibt es nur noch einen Synchronisationsbereich. 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 Netzwerk-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 bezogen. Außerdem erhält jedes Triggersignal 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 einkalkuliert. 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 Synchronisations-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 beiden 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 hinzufügen, und die Synchronisation ist auf den jeweiligen Motor-Controller abstimmbar.