PackML in practice: keeping modular machine software in sync

Customers start asking for PackML. You have heard the name. It sounds like a full 17-state project and a rewrite of software that already runs the machine.

The requirement is usually more modest. They want start, stop, reset and recovery to mean the same kind of thing from one module to the next, and from one machine to the next on their line. PackML is a framework for that. Process logic, motion and safety stay. The modules get shared states.

You also do not need every state on every module. ANSI/ISA-TR88.00.02-2022 allows a subset for PackML machine and unit modes, and names a minimum set. Nested equipment modules can be smaller. Empty states that nothing in the application uses only add noise.

The work that actually takes time is coordination: who waits, who may Reset, what happens when one station is still aborting. That is where machines drift, and where a BOOL list usually grows.

Five stations on one machine. One faults. The others keep running or stop on their own timing. The HMI says the machine is ready for Reset because the top program finished. One station is still moving. An operator presses Reset while recovery is still running.

In PackML that looks like this. Infeed, Transport, Process, Inspection and Outfeed are in Execute when a child raises Abort. Infeed reaches Aborted in a few cycles. Transport still has to stop motion. Process stays in Aborting while a station empties or an axis decelerates. The other modules are already Aborted.

If Main treats 'my Aborting code finished' as 'the machine is aborted', Reset starts against a module that has not finished the last step.

That is how the BOOL list grows: ProcessReady, AxisHomed, InfeedResetDone, OutfeedStopped, plus handshakes that only one person remembers. Diagnosis then means hunting bits instead of reading a state. Different modules need different transition times. That is legitimate. The failure is hiding those times in private flags instead of shared states the hierarchy can wait on.

PackML, in ANSI/ISA-TR88.00.02, is a shared vocabulary for unit and machine states and modes. It came out of packaging through OMAC. The same states are used on other automated machinery when start, stop and recovery have to mean one thing across modules. For a custom machine the origin matters less than this: Stopped, Resetting, Idle, Starting and Execute mean the same kind of thing on Infeed as they do on Process.

Resetting is the acting state that brings a stopped module to a known ready condition. Depending on the application, that may include enabling drives, establishing references or homing axes where the machine safety concept allows this without hazardous motion, returning a mechanism to a known position, and resetting local sequences. On another machine Resetting barely moves anything, because the machine is already at a known ready condition. Those actions are application examples. PackML does not mandate them.

Idle means ready, waiting for Start. Starting is the acting state from ready to running. Typical work includes applying the active job, establishing axis or module sync, starting auxiliaries, and ramping transport. Again, examples. Execute is the defined production behaviour for the active mode.

Stopping is a controlled stop. Aborting is a rapid path to a safe stop after a fault or an Abort command. Clearing leaves Aborted after the cause has been handled and faults have been acknowledged. Completing finishes a cycle from Execute when the mode uses a complete path. Hold and Suspend pause production; they are not the same as Stop or Abort. Abort can be issued from every state except Aborting and Aborted. Stop cannot be issued from Aborting, Aborted, Clearing, Stopping or Stopped. Complete can be issued from Execute, Held and Suspended.

The opening poster is the allowed set. Day to day, production usually runs Stopped, Resetting, Idle, Starting and Execute. Implement the states this machine actually uses. Those states need agreed meaning, so a parent can wait for Resetting to complete instead of a private bit name.

PackML will not fix modules cut in the wrong places, unclear ownership of signals and faults, a weak process, or application motion and sequence logic. It does not replace functional safety. Aborting is a control-state path. An e-stop still trips the safety system.

PackML defines the shared machine states. The parent/child hierarchy described below is a practical modular software architecture for applying those states across a machine. The standard does not require that hierarchy. Real machines with several modules do.

A Main that shows Idle while Process is still Resetting is a misleading dashboard. The machine is the hierarchy, not the top function block.

A typical line is Machine, then Infeed, Transport, Process, Inspection and Outfeed. Each module has local behaviour: sensors, motion, sequences. Each also takes part in those shared states. If only Main speaks PackML, children still finish Abort and Reset on private timing, and you are back to BOOLs.

Nesting is the same rule one level down. Process may own an axis module. Inspection may own a camera station. Those children complete their own transitions and report when they are actually done.

The child runs its own transition. When the local work is actually done, it signals State Complete. The parent stays in the acting state until the relevant children have completed.

Relevant means children that are in the active hierarchy and configured to take part in that command. A deactivated optional station should not block Reset. A branch that is intentionally left out of sync should not either.

Children will not finish together. Infeed may already be Idle while Process is still Resetting because an axis is referencing. The useful diagnostic is explicit: Main Waiting for Process. Process: Axis reference in progress. Commissioning and service can see the block without opening a cross-reference of flags.

If the parent does not wait, Main will show Idle while a child is still moving. Operators then start a machine that is not ready.

Commands need a direction, or every module invents one.

Some commands belong at the parent. Start and Reset are typically issued from above so the hierarchy enters the acting state together. A child that starts itself while siblings are still Idle produces a race.

Some events must travel up. A local Abort on Process should become a machine Abort. Stop often should too. Complete, Hold and Suspend may escalate, depending on the machine.

Children also need a rule for following the parent. If Main goes to Aborting, Process should react even if its own code did not request Abort.

Some PackML libraries name these rules Override, ReactTo and Escalate. The names matter less than the consequences. Override: the parent owns this command; local requests are blocked, though escalation can still occur. ReactTo: the child follows the parent transition. Escalate: a local command is raised to the parent. If a child is neither ReactTo nor Override for a command, it is out of sync and the parent should not wait for it.

Keep one software architecture and change which modules are active. Main, Infeed and Outfeed are always present. Printing and Inspection are optional. Printing may itself contain PrintAxis, InkSystem and Dryer.

Machine A marks only. Machine B inspects only. Machine C does both. The optional module still exists in the project. It is not deleted from the code for the short machine. It is either in the active hierarchy or it is not.

If participation is a scatter of IF Config.HasPrinter in Infeed, Main, HMI and the abort handler, every new variant reopens those files.

An explicit activation path is cleaner. The module can sit Deactivated: present in software, not part of the active machine. When the configuration includes it, it goes Activating, then Stopped, and from there into the normal PackML states. The parent does not wait for a deactivated child. Children under Printing follow that branch.

Activating, Deactivating and Deactivated are implementation extensions. They are not states in ISA-TR88.00.02. They exist because Stopped and 'not part of this machine today' are different questions. Should the parent wait? Should it react to Reset? Is the station installed but unused on this order?

Our PackML library uses that Deactivated path so an optional station can exist in the project without sitting in the active machine. The standard names the states. Configuration decides who takes part.

A poster of 17 states does not finish the architecture. Take one Abort or Reset you shipped. If you cannot answer the questions below from that event, the waits are still informal, and the next variant will grow another BOOL list.