How-To: Implementing PackML (ISA-TR88.00.02) State Machines in Modern PLCs
How-To: Implementing PackML (ISA-TR88.00.02) State Machines in Modern PLCs
Learning%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
---
title: PackML State Machine Implementation
---
flowchart LR
classDef default fill:#1f2937,stroke:#4b5563,color:#f3f4f6
classDef active fill:#2563eb,stroke:#1d4ed8,color:#ffffff
classDef holding fill:#d97706,stroke:#b45309,color:#ffffff
classDef stopped fill:#ef4444,stroke:#b91c1c,color:#ffffff
A["Stopped"]:::stopped -->|Start| B["Starting"]:::active
B --> C["Execute"]:::active
C -->|Hold| D["Holding"]:::holding
D -->|Unhold| E["Unholding"]:::active
E --> C
For decades, OEMs and systems integrators built custom, proprietary state machines for every packaging line they deployed. This resulted in fragmented codebases, operator confusion, and integration nightmares when trying to link an unwrapper from Vendor A with a filler from Vendor B. The ISA-TR88.00.02 standard, commonly known as PackML (Packaging Machine Language), solves this by defining a universal state model and standard data interface.
Key Takeaways
- Universal Vocabulary: Standardizes states like Execute, Held, Suspended, and Aborted.
- Acting vs. Wait States: Clearly separates transient execution logic from steady-state waiting.
- Standardized OEE: Native PackTags provide a unified structure for calculating Overall Equipment Effectiveness.
- Cross-Vendor Integration: Drastically reduces handshake programming between discrete machines.
The PackML State Model Structure
The core of PackML is a robust state machine consisting of 17 defined states. A common misconception is that a machine must use all 17 states. In reality, the standard is flexible; simple machines can omit states like Suspended or Held if the physical mechanics do not support those operational modes.
The genius of PackML lies in its division of states into two categories: Acting States (transient) and Wait States (steady). For example, Starting is an acting state where initialization code runs. Once complete, the machine automatically transitions to Execute, a wait state where continuous production occurs until an external command or internal fault triggers a change.
---
title: The Core Acting/Wait Transition
---
flowchart TD
classDef transient fill:#8b5cf6,stroke:#6d28d9,color:#ffffff
classDef steady fill:#10b981,stroke:#059669,color:#ffffff
A["Idle (Wait State)"]:::steady -->|Start Command| B["Starting (Acting State)"]:::transient
B -->|Initialization Complete| C["Execute (Wait State)"]:::steady
C -->|Stop Command| D["Stopping (Acting State)"]:::transient
D -->|Motion Halted| E["Stopped (Wait State)"]:::steady
Implementation in PLC Code (IEC 61131-3)
While PackML defines the states, it does not dictate the programming language. However, implementing PackML in Ladder Logic often leads to unreadable, sprawling routines. The most effective way to architect PackML is by using a combination of Structured Text (for state transition logic) and SFC / Sequential Function Charts (for the acting state sequences).
Recommended Code Architecture
| Architecture Layer | Recommended IEC Language | Function |
|---|---|---|
| State Manager | Structured Text (ST) | Evaluates commands (Start, Stop, Hold) and sets the active state integer. |
| Acting States | Sequential Function Chart (SFC) | Handles multi-step sequences like homing axes or purging lines during Starting. |
| Equipment Modules | Ladder Logic / FBD | Direct hardware control (valves, motors) driven by the current PackML state. |
PackTags: The Real Value for OEE
A standard state machine is helpful for operators, but the true ROI of PackML comes from PackTags. PackTags are a standardized set of data structures (Command, Status, and Admin) that every PackML-compliant machine must expose.
Instead of an SCADA engineer hunting for custom memory addresses to calculate downtime, they simply read the Status.StateCurrent and Admin.MachSpeed PackTags. Because every machine exposes the exact same data structure over OPC UA or Ethernet/IP, calculating plant-wide OEE becomes a plug-and-play exercise.
Conclusion
Adopting PackML requires an initial investment in re-architecting your PLC templates. However, the payoff is immense. By standardizing machine states and data interfaces, engineering teams reduce commissioning time, simplify SCADA integration, and deliver a consistent, highly professional operator experience across the entire plant floor.
To explore more tools for modern PLC architectures, visit the AutomationView Store.
FAQ
Do I have to use PackML only for packaging machines?
No. Despite the name, the ISA-TR88.00.02 standard is successfully applied to assembly lines, discrete manufacturing, and even process skids. The state model applies universally to almost any automated equipment.
What is the difference between Suspended and Held?
Suspended is typically triggered automatically by the machine (e.g., downstream is blocked, or upstream is starved of material). Held is usually a deliberate operator command or an internal logic condition that pauses production without aborting the cycle.
Stay Updated with Learning
Get the latest articles and news delivered directly to your inbox.
You must be registered and logged in to manage subscriptions.
Recommended for you
How-To: Architecting a Bulletproof PLC State Machine for Industrial Sequences
Learning%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
classDef init fill:#3b82f6,stroke:#1d4ed8,stroke-width:2px,color:#fff;
classDef process fill:#10b981,stroke:#047857,stroke-width:2px,color:#fff;
classDef error fill:#ef4444,stroke:#b91c1c,stroke-width:2px,color:#fff;
S0["Init State (S0)"]:::init -->|"Start Cmd"| S1["Process Step 1 (S1)"]:::process
S1 -->|"Done"| S2["Process Step 2 (S2)"]:::process
S2 -->|"Complete"| S0
S1 -->|"Fault"| SE["Fault State (SE)"]:::error
S2 -->|"Fault"| SE
SE -->|"Reset"| S0
How-To: Architecting a Bulletproof PLC State Machine for Industrial Sequences
TL;DR: Procedural logic breaks down as complexity grows; a PLC state machine strictly defines operational phases to eliminate race conditions. Decoupling transition rules from output actions is the secret to scalable, maintainable sequencers. Always design for failure: implement dedicated fault states and strict step timeouts to catch mechanical jams before they cause damage. Anyone who […]
Essential ISA-101 HMI Standard Tips for Amazing Screens
HMI%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
A[Legacy HMI] -->|Apply ISA-101| B(High-Performance Screens)
B --> C[Grayscale]
B --> D[Redundant Alarms]
B --> E[Simplified P&IDs]
C & D & E --> F[Safe & Efficient Operations]
Essential ISA-101 HMI Standard Tips for Amazing Screens
When operators first look at an ISA-101 HMI standard compliant screen, their most common complaint is that it looks “boring” or “broken.” The vibrant 3D pumps and spinning cooling fans of legacy SCADA systems are gone, replaced by flat, muted shapes on a gray background. But that dullness is entirely intentional. The goal isn’t to […]
Mastering HMI Faceplates: 5 Proven Strategies
HMI%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
classDef main fill:#0ea5e9,stroke:#0284c7,stroke-width:2px,color:#fff
classDef block fill:#1e293b,stroke:#334155,stroke-width:2px,color:#f8fafc
A["PLC Data Block"]:::block -->|Tag Binding| B["HMI Faceplate"]:::main
B -->|Reusable Instance| C["Pump 1"]:::block
B -->|Reusable Instance| D["Pump 2"]:::block
B -->|Reusable Instance| E["Pump 3"]:::block
Mastering HMI Faceplates: 5 Proven Strategies
Walk into any legacy control room, and you’ll likely see operators squinting at screens packed with flashing red pumps and scattered data values. Without standardized HMI faceplates, interpreting plant floor conditions becomes a memory test rather than an intuitive process. Building a reusable faceplate isn’t just about saving development time; it’s about eliminating cognitive load […]