Virtuelle Steuerungen für Motion und Robotik

Ein wesentlicher Vorteil virtueller Steuerungen liegt in der Wartbarkeit. Sicherheitsupdates lassen sich zentral und zeitnah ausrollen, wodurch Produktionssysteme leichter gegen gezielte oder zufällige Angriffe abgesichert werden können. Mit der Zertifizierung nach IEC 61508 für SIL3- Anwendungen stehen zudem auch virtuelle Sicherheitssteuerungen wie ‚Codesys Virtual Safe Control SL‘ für entsprechende Aufgaben zur Verfügung. Dennoch bleibt ein Zweifel: Wenn virtuelle Steuerungen auf abgesetzten IPCs nahe der Maschine oder sogar auf entfernten Servern betrieben werden, lassen sich dann weiterhin Echtzeitanwendungen mit hohen Anforderungen an Performance und Jitter realisieren? Vor allem dann, wenn koordinierte Verfahrbewegungen benötigt werden, wie das bei Motion-Controllern, CNC- und Robotiksteuerungen der Fall ist. Wie sieht es aus, wenn größere Distanzen zwischen Steuerung und Antrieben bzw. E/As zu überbrücken sind?

Für koordinierte Verfahrbewegungen in Motion-, CNC- oder Robotikaufgaben werden geeignete Servoantriebe mit digitalen Feldbusschnittstellen benötigt. CANopen und zunehmend EtherCAT haben sich als Echtzeitfähige Bussysteme etabliert und werden von vielen Herstellern implementiert, so dass Anwenderinnen und Anwender die freie Auswahl aus einem breiten Portfolio kompatibler Antriebe verschiedener Hersteller haben. Die in Codesys integrierte Motion-Lösung stellt spezifische Treiber für CANopen- und EtherCAT- Antriebe von mehr als zwei Dutzend Herstellern bereit und unterstützt zudem generische Treiber für CiA402/CoE- und SoE-kompatible Systeme.

Motion, CNC und Robotik auf SPSen

Wurden früher dedizierte Controller eingesetzt, um koordinierte Verfahrbewegungen zu steuern, so lassen sich die Anfahrpunkte der Achsen mit ihren jeweiligen Dynamiken heute auch in der SPS berechnen und per Feldbus übertragen. Daraus ergeben sich Einsparungen bei Hardware- aufwand und Kosten. Voraussetzung ist jedoch eine ausreichende CPU-Leistung und verfügbare Schnittstellen an der SPS. Reicht die Leistungsfähigkeit nicht aus, muss ein leistungsfähigeres Steuerungsmodell gewählt werden, was zusätzlichen Aufwand verursachen kann. Bei der Abschätzung des Leistungsbedarfs seiner Applikation sollte daher frühzeitig geprüft werden, welche Motion Control-, CNC- oder Robotik-Funktionen benötigt werden und die Auswahl geeigneter Steuerungen nach der verfügbaren Leistungsfähigkeit filtern. Dabei fällt auf: Mit SoftSPSen oder virtuellen Steuerungen ist man deutlich flexibler.

Auch die Leistungsreserven von IPCs oder Servern mit mehreren CPU-Kernen sind begrenzt, insbesondere wenn mehrere virtuelle Steuerungen parallel laufen. Im Vergleich zu dedizierten SPSen stehen jedoch größere Ressourcen zur Verfügung, die bei Bedarf abgerufen werden können. Ein Anwendungsfall: Bei der Projektierung wird klar, dass zusätzlich zur Logiksteuerung noch ein Motion Controller nötig wird. Dieser kann über eine Lizenz einfach "aufgerüstet" und aktiviert werden, wodurch komplexe Achsgruppen gesteuert und die benötigten Bibliotheksfunktionen freigeschaltet werden. Physische Geräte erfordern in vielen Fällen einen deutlich höheren Aufwand für Erweiterungen.

Grundsätzlich existieren zwei Architekturansätze für Motion Control, welche die Anforderungen an die Echtzeitkommunikation stark beeinflussen: Beim zentralen Ansatz werden Trajektorien in der Steuerung berechnet, und die Achsen folgen diesen Vorgaben. Dies erfordert eine kontinuierliche, deterministische Kommunikation. Der dezentrale Ansatz hingegen verlagert die Motion-Funktion in intelligente Antriebe oder untergeordnete Steuerungen; die übergeordnete Steuerung sendet nur Befehle. Hier ist keine zyklische, synchronisierte Kommunikation erforderlich. Insbesondere Industrieroboter können somit ohne spezielle Programmiersprachen wie Karel, Inform oder RAPID auskommen. Von der SPS aus werden stattdessen Kommandos über Standard-Feldbussysteme wie Profinet an die Robotersteuerung geschickt. Wurden in der Vergangenheit proprietäre Bibliotheken wie ‚mxAutomation‘ dafür angeboten, so etabliert sich mit ‚Robot Command Interface‘ (SRCI) gerade ein übergreifender Standard mit einem Satz aus 115 Befehlen, z.B. für lineare Bewegungen bis hin zu komplexeren Befehlen wie Kraftsteuerung. Die virtuelle SPS kann diese Kommandos auch räumlich distanziert per Feldbus übertragen, da die Robotersteuerung weiterhin vor Ort verbleibt.

Abgesetzte industrielle Antriebssysteme

Ob virtuelle Steuerungen für zentrale gerechnete Motion-Aufgaben geeignet sind, hängt wesentlich von der Kommunikation zwischen Steuerung und Antrieb ab. In hardwareunabhängigen Systemen wie Codesys werden die Befehle und Services des Protokollstacks in Bibliotheksbausteinen implementiert, abstrahiert von der tatsächlich eingesetzten Hardware. Dieser Code wird mithilfe integrierter Compiler der Entwicklungsumgebung zusammen mit der SPS-Applikation implizit in nativen Maschinencode für die CPU der eingesetzten Steuerung übersetzt. Lediglich bei der Übersetzungsdauer und Codegröße bemerkt man, dass jetzt zusätzlich zum selbst erstellten Logikprogramm auch noch das Feldbus- protokoll im Kompilat enthalten ist. Damit dieser Code zykluskonsistent zur SPS-Applikation ausgeführt werden kann, müssen Antriebssysteme im Programmiertool korrekt konfiguriert werden (siehe Bild 1).