PackML in der Praxis: modulare Maschinensoftware synchron halten

Kunden fragen nach PackML. Den Namen kennen Sie. Es klingt nach einem 17-Zustands-Projekt und nach einer Neuprogrammierung von Software, die die Maschine schon fährt.

Die Anforderung ist meist schlichter. Start, Stop, Reset und Recovery sollen von einem Modul zum nächsten dasselbe bedeuten, und von einer Maschine zur nächsten auf ihrer Linie. PackML ist eine gemeinsame Sprache dafür. Prozesslogik, Motion und Safety bleiben. Die Module bekommen gemeinsame Zustände.

Sie brauchen auch nicht jeden Zustand auf jedem Modul. ANSI/ISA-TR88.00.02-2022 erlaubt eine Teilmenge für PackML-Machine- und Unit-Modes und nennt ein Minimum. Geschachtelte Equipment Modules können kleiner sein. Leere Zustände, die die Anwendung nicht nutzt, erzeugen nur Rauschen.

Die Arbeit, die Zeit kostet, ist die Koordination: wer wartet, wer darf Reset, was passiert, wenn eine Station noch in Aborting ist. Dort laufen Maschinen auseinander, und dort wächst meist die BOOL-Liste.

Fünf Stationen an einer Maschine. Eine Station stört. Die anderen laufen weiter oder halten nach eigenem Timing. Das HMI sagt, die Maschine sei bereit für Reset, weil das Hauptprogramm fertig ist. Eine Station fährt noch. Ein Bediener drückt Reset, während die Recovery noch läuft.

In PackML sieht das so aus. Infeed, Transport, Process, Inspection und Outfeed sind in Execute, als ein Child Abort auslöst. Infeed erreicht Aborted in wenigen Zyklen. Transport muss zuerst die Motion stoppen. Process bleibt in Aborting, während eine Station leert oder eine Achse abbremst. Die anderen Module sind bereits Aborted.

Wenn Main "mein Aborting-Code ist fertig" als "die Maschine ist aborted" behandelt, startet Reset, obwohl ein Modul den letzten Schritt nicht beendet hat.

So wächst die BOOL-Liste: ProcessReady, AxisHomed, InfeedResetDone, OutfeedStopped, plus Handshakes, die nur eine Person kennt. Diagnose heißt dann Bits jagen statt einen Zustand zu lesen. Unterschiedliche Module brauchen unterschiedliche Übergangszeiten. Das ist legitim. Der Fehler ist, diese Zeiten in privaten Flags zu verstecken statt in gemeinsamen Zuständen, auf die die Hierarchie warten kann.

PackML in ANSI/ISA-TR88.00.02 ist ein gemeinsames Vokabular für Unit- und Maschinenzustände und Modes. Es kommt aus Packaging über OMAC. Dieselben Zustände nutzen andere automatisierte Anlagen, wenn Start, Stop und Recovery über Module hinweg dasselbe bedeuten sollen. Für eine Sondermaschine zählt weniger der Ursprung als dies: Stopped, Resetting, Idle, Starting und Execute bedeuten auf Infeed dasselbe wie auf Process.

Resetting ist der Übergang, der ein gestopptes Modul in einen bekannten Bereitzustand bringt. Je nach Anwendung kann das Antriebe einschalten, Referenzen setzen oder Achsen referenzieren, wo das Sicherheitskonzept der Maschine das ohne gefährliche Bewegung zulässt, eine Mechanik zurückfahren und lokale Sequenzen rücksetzen bedeuten. Auf einer anderen Maschine bewegt Resetting die Mechanik kaum, weil sie schon bereit steht. Das sind Anwendungsbeispiele. PackML schreibt sie nicht vor.

Idle heißt bereit und wartet auf Start. Starting ist der Übergang von bereit nach laufend. Typische Arbeit: aktiven Job anwenden, Achs- oder Modulsync herstellen, Hilfsaggregate starten, Transport hochfahren. Wieder Beispiele. Execute ist das definierte Produktionsverhalten des aktiven Mode.

Stopping ist ein kontrollierter Halt. Aborting ist ein schneller Weg zu einem sicheren Halt nach einem Fehler oder einem Abort-Kommando. Clearing verlässt Aborted, wenn die Ursache behandelt ist und Störungen quittiert wurden. Completing beendet einen Zyklus aus Execute, wenn der Mode einen Complete-Pfad nutzt. Hold und Suspend halten die Produktion an. Sie sind nicht dasselbe wie Stop oder Abort. Abort kann in jedem Zustand außer Aborting und Aborted ausgelöst werden. Stop nicht aus Aborting, Aborted, Clearing, Stopping und Stopped. Complete aus Execute, Held und Suspended.

Das Poster im ersten Abschnitt zeigt die zulässigen Zustände. Im Betrieb läuft der Weg meist Stopped, Resetting, Idle, Starting und Execute. Implementieren Sie die, die diese Maschine wirklich braucht. Diese Zustände brauchen eine vereinbarte Bedeutung, damit ein Parent auf abgeschlossenes Resetting warten kann statt auf einen privaten Bitnamen.

PackML repariert keine falsch geschnittenen Module, unklare Zuständigkeit für Signale und Störungen, einen schwachen Prozess oder die Motion- und Sequenzlogik der Anwendung. Es ersetzt keine Functional Safety. Aborting ist ein Control-State-Pfad. Ein E-Stop löst weiterhin das Safety-System aus.

PackML definiert die gemeinsamen Maschinenzustände. Die Parent/Child-Hierarchie unten ist eine praktische modulare Softwarearchitektur, um diese Zustände über die Maschine anzuwenden. Die Norm verlangt diese Hierarchie nicht. Echte Maschinen mit mehreren Modulen schon.

Ein Main, der Idle zeigt, während Process noch Resetting ist, zeigt einen irreführenden Maschinenzustand. Die Maschine ist die Hierarchie, nicht der oberste Function Block.

Eine typische Linie ist Machine, dann Infeed, Transport, Process, Inspection und Outfeed. Jedes Modul hat lokales Verhalten: Sensoren, Motion, Sequenzen. Jedes Modul nimmt auch an den gemeinsamen Zuständen teil. Spricht nur Main PackML, beenden Children Abort und Reset weiter nach privatem Timing, und Sie sind wieder bei BOOLs.

Schachtelung ist dieselbe Regel eine Ebene tiefer. Process kann ein Achsmodul besitzen. Inspection kann eine Kamerastation besitzen. Diese Children führen ihre eigenen Übergänge aus und melden, wenn sie wirklich fertig sind.

Das Child führt den eigenen Übergang aus. Wenn die lokale Arbeit wirklich fertig ist, signalisiert es State Complete. Der Parent bleibt im Übergang, bis die relevanten Children abgeschlossen haben.

Relevant heißt: Children in der aktiven Hierarchie, die an diesem Kommando teilnehmen sollen. Eine deaktivierte optionale Station darf Reset nicht blockieren. Ein bewusst nicht synchronisierter Zweig auch nicht.

Children werden nicht gleichzeitig fertig. Infeed kann schon Idle sein, während Process noch Resetting ist, weil eine Achse referenziert. Die nützliche Diagnose ist explizit: Main Waiting for Process. Process: Axis reference in progress. Inbetriebnahme und Service sehen die Blockade, ohne eine Kreuzreferenz von Flags zu öffnen.

Wartet der Parent nicht, zeigt Main Idle, während ein Child noch fährt. Bediener starten dann eine Maschine, die nicht bereit ist.

Kommandos brauchen eine Richtung, sonst erfindet jedes Modul eine eigene.

Manche Kommandos gehören zum Parent. Start und Reset kommen typisch von oben, damit die Hierarchie gemeinsam in den Übergang geht. Ein Child, das selbst startet, während Geschwister noch Idle sind, erzeugt ein Race.

Manche Ereignisse müssen nach oben. Ein lokaler Abort auf Process soll ein Maschinen-Abort werden. Stop oft ebenfalls. Complete, Hold und Suspend können eskalieren, je nach Maschine.

Children brauchen auch eine Regel, dem Parent zu folgen. Geht Main nach Aborting, soll Process reagieren, auch wenn der eigene Code kein Abort angefordert hat.

Manche PackML-Bibliotheken nennen diese Regeln Override, ReactTo und Escalate. Die Namen zählen weniger als die Folgen. Override: der Parent besitzt das Kommando; lokale Requests werden blockiert, Eskalation bleibt möglich. ReactTo: das Child folgt dem Parent-Übergang. Escalate: ein lokales Kommando wird zum Parent gehoben. Ist ein Child für ein Kommando weder ReactTo noch Override, ist es nicht synchronisiert, und der Parent soll nicht darauf warten.

Behalten Sie eine Softwarearchitektur und ändern Sie, welche Module aktiv sind. Main, Infeed und Outfeed sind immer da. Printing und Inspection sind optional. Printing kann selbst PrintAxis, InkSystem und Dryer enthalten.

Maschine A markiert nur. Maschine B inspiziert nur. Maschine C macht beides. Das optionale Modul bleibt im Projekt. Es wird für die kurze Maschine nicht aus dem Code gelöscht. Es ist entweder in der aktiven Hierarchie oder nicht.

Liegt überall IF Config.HasPrinter in Infeed, Main, HMI und Abort-Behandlung, öffnet jede neue Variante diese Dateien erneut.

Ein expliziter Aktivierungspfad ist sauberer. Das Modul kann Deactivated sein: in der Software vorhanden, nicht Teil der aktiven Maschine. Gehört es zur Konfiguration, geht es nach Activating, dann Stopped, und von dort in die normalen PackML-Zustände. Der Parent wartet nicht auf ein deaktiviertes Child. Children unter Printing folgen diesem Zweig.

Activating, Deactivating und Deactivated sind Implementierungserweiterungen. Sie sind keine Zustände in ISA-TR88.00.02. Es gibt sie, weil Stopped und "heute nicht Teil dieser Maschine" verschiedene Fragen sind. Soll der Parent warten? Soll er auf Reset reagieren? Ist die Station verbaut, aber in diesem Auftrag ungenutzt?

Unsere PackML-Bibliothek nutzt diesen Deactivated-Pfad, damit eine optionale Station im Projekt existieren kann, ohne in der aktiven Maschine zu sitzen. Die Norm benennt die Zustände. Die Konfiguration entscheidet, wer teilnimmt.

Ein Poster mit 17 Zuständen macht die Maschine nicht fertig. Nehmen Sie ein Abort oder Reset, das Sie geliefert haben. Wenn Sie die Fragen unten aus diesem Ereignis nicht beantworten können, sind die Wartezeiten noch informell, und die nächste Variante bekommt wieder eine BOOL-Liste.