Kontext
Praktikum des Automatisierungsmoduls im ersten Masterjahr (MESI), im Zweierteam mit Leroy Makita Loubaki, betreut von Herrn Pierre Paul Zeil. Das System ist eine Tauchanlage, zwei motorisierte Wagen A und B bewegen sich auf einer gemeinsamen Schiene über fünf Bädern. Ziel war es, die Behälter von der Beladezone CDA bis zur Entladezone CDB durch die fünf Bäder zu befördern, wobei jeder Tauchvorgang mindestens zwei Sekunden dauert. Die zentrale Randbedingung ergab sich aus der gemeinsamen Schiene, jede Kreuzung der beiden Wagen musste vermieden werden. Wir haben das Ganze zu zweit entworfen und programmiert, ohne formale Aufteilung der Arbeit.
Ansatz / Lösung
Wir haben das System in 7 unabhängige Grafcets zerlegt, einen pro Wagen, einen pro Bad und einen pro Transferzone, koordiniert über ganzzahlige Austauschvariablen statt über einen zentralen Verwalter. Alles ist in der Sprache GRAPH unter TIA Portal programmiert. • Kollisionsfreie Synchronisation. Da die Schiene geteilt wird, rückt ein Wagen nur dann zur nächsten Position vor, wenn der Grafcet des Zielbads bestätigt, dass sie frei ist. Konkret halten Warteschritte (S4, S24, S76 für Wagen A) den Ablauf an, solange die Verfügbarkeitsbedingungen (#S50.X, #S60.X, #Step15.X und PRB) nicht erfüllt sind. Diese dezentrale Logik vermeidet jeden einzelnen Kontrollpunkt und macht das System leicht erweiterbar. • WinCC-Bedienoberfläche auf einem SIMATIC-Touch-Panel. Die Übersichtsansicht spiegelt den Systemzustand in Echtzeit wider. Die Farbe der Behälter folgt der ganzzahligen Variable MB*_Etat über die Appearance-Animation im Range-Modus (frei, im Tauchen, fertig), die Fahr- und Hakenpfeile erscheinen anhand der Aktorbits (Visibility im Single-bit-Modus), die Position jedes Wagens wird über ein symbolisches Feld mit verknüpfter Textliste im Klartext angezeigt, und zwei SetBit-Schaltflächen (DCA, DCB) bilden den einzigen Bedienereingang. Zwei VBScript-Skripte bewegen die Wagen horizontal auf dem Bildschirm gemäß X_chariot_A und X_chariot_B. • Node-RED-Webüberwachung. Ergänzend fragt ein Node-RED-Flow die S7-1500-Steuerung über das S7-Protokoll ab, ein JavaScript-Parsing-Knoten bereitet die Zustände auf, und ein Webdashboard zeigt die Wagenpositionen, den Zustand der Behälter und die Zyklus-Start-Schaltflächen. Es bleibt von jedem Browser im lokalen Netz aus einsehbar, ohne WinCC-Client.
Ergebnisse
Die vollständige Steuerung funktioniert, die beiden Wagen befördern die Behälter von Anfang bis Ende, ohne sich auf der gemeinsamen Schiene jemals zu kreuzen. Die 7 kommunizierenden Grafcets bewältigen die Komplexität gut, und die Trennung der Zustandslogik (in der Steuerung) von ihrer Darstellung (an die Bedienoberfläche delegiert) hält den Code lesbar. Meine wichtigste Erkenntnis ist, dass eine Synchronisation über Austauschvariablen und Warteschritte, ohne zentrale Sperre, leichter zu durchdenken ist und sich besser erweitern lässt als ein einzelner Ressourcenverwalter. Die doppelte Überwachung hat mich zudem den Wert einer leichten Webschicht wie Node-RED spüren lassen, änderbar ohne Neukompilieren des TIA-Portal-Projekts, neben einer starreren proprietären Bedienoberfläche. Die Grenzen stehe ich offen ein. Das System wurde am Lehrstand validiert, nicht an einer realen Industrielinie. Die Wagenbewegung auf dem Bildschirm beruht auf von Hand kalibrierten Pixelpositionen, was bricht, sobald man das Panel wechselt. Mehrere Sensoren teilen sich dieselbe physische Adresse zwischen den beiden Wagen, was Sorgfalt bei den Übergangsbedingungen erfordert. Und auf den Node-RED-Aufnahmen erscheint die S7-Verbindung als offline, das Dashboard war verdrahtet, aber zum Zeitpunkt der Aufnahmen nicht mit der Steuerung verbunden. Was ich noch tun könnte, mehr als zwei Wagen auf derselben Schiene verwalten, eine Sicherheits- und Alarmschicht ergänzen (Not-Halt, Sensorfehler, Überwachungszeitglieder), die Pixelkalibrierung durch eine berechnete Position ersetzen, die Node-RED-Verbindung robuster machen und das Ganze an einem physischen System validieren.