How to Program an Automated Mixer State Machine in Ladder Logic

To program an automated mixer state machine in ladder logic, engineers should separate the sequence into mutually exclusive states and gate every transition with explicit permissives. This article shows how to build Filling, Mixing, and Draining states in OLLA Lab’s Mixer preset and validate them against abnormal conditions before any live deployment.

A mixer sequence is not made safe by adding more contacts. It is made safer by making sequence intent explicit. In batch control, nested boolean logic can look acceptable on the screen and still behave badly on the scan, especially when sensor changes, asynchronous feedbacks, or restart conditions arrive out of order.

Ampergon Vallis internal testing supports that distinction within this specific training context. During 2026 validation testing of the OLLA Lab Mixer preset, users who built the sequence with an explicit integer-based state model produced 82% fewer unintended valve-overlap faults than users who relied on nested parallel contact logic. Methodology: n=34 learner build attempts on the same 3-state mixer task; baseline comparator = nested boolean rung architecture; time window = Jan-Feb 2026. This supports the value of isolated state design inside this specific lab task. It does not establish a universal defect rate for all PLC projects or all engineers.

The practical point is simple: syntax is not deployability. A rung can compile and still be structurally wrong for a live process.

Nested boolean sequencing fails because it does not enforce mutual exclusivity between process phases. In a batch mixer, the control problem is not merely "when should this output turn on?" but "which phase is the process in, and which outputs are forbidden in every other phase?"

ISA-88 provides the right conceptual frame here. The standard separates procedural control into defined phases and states rather than treating the whole batch as one expanding block of conditional logic (ANSI/ISA-88.01, 2010). That distinction matters because batch equipment is sequential by nature. Fill, mix, and drain are not peers. They are ordered phases with explicit entry and exit conditions.

A common junior pattern is "onion logic": layer enough contacts around each output until it appears protected. The problem is that protection by accumulation is not the same as protection by structure. If a high-level switch bounces, a motor feedback lags one scan, or a restart occurs after interruption, multiple rungs can briefly satisfy conflicting conditions.

The hazards of non-state logic

- Unintended overlap: Fill and drain commands can energize together if permissives are distributed across separate rungs without a single governing phase variable. - Scan-cycle ambiguity: PLCs solve logic sequentially by scan, not by human intention. "It should never happen" is not a control strategy. - Difficult troubleshooting: Sequence failures become hard to isolate because the active process phase is inferred from many conditions rather than declared explicitly. - Poor interruption recovery: After an E-stop, mode change, or power cycle, nested logic often re-enters the sequence based on raw conditions rather than controlled state recovery. - Weak abnormal-state handling: Faults such as a stuck level switch or failed agitator feedback can produce oscillation, repeated transitions, or invalid output combinations.

The misconception is that more interlocks automatically mean more safety. Sometimes they mean more places to hide the bug.

A PLC state machine is a sequence architecture in which one declared state represents the current phase of operation, and transitions occur only when defined conditions are met. In practice, that usually means an integer step value or a one-hot bit pattern that permits only one active phase at a time.

For this mixer build, we will use an integer-based sequence variable:

• State 10 = Filling
• State 20 = Mixing
• State 30 = Draining

This approach is mathematically cleaner than scattered output logic because every command can be tied to one active state. If `Seq_Step = 20`, the mixer is in Mixing. Not "sort of mixing if three other conditions remain true." Just Mixing.

Operational definition of "correct" for this mixer

A mixer state machine is operationally correct when it demonstrates all of the following observable behaviors:

• Only one process phase is active at a time.
• Fill and drain outputs cannot command simultaneously.
• Mixing cannot begin until the vessel reaches the required level condition.
• Draining cannot begin until the mixing interval is complete.
• An abnormal sensor change in one state does not force an invalid backward jump unless explicitly designed to do so.
• Stop or fault conditions de-energize outputs in a deterministic way.

That is the standard worth using in simulation. "The ladder looks reasonable" is not an engineering acceptance test.

The three operational states are Filling, Mixing, and Draining. Each state should have a clear purpose, a bounded output set, and explicit transition permissives.

OLLA Lab Mixer I/O dictionary

The following mapping reflects the article build logic for the OLLA Lab Mixer preset.

| State | Phase Name | Primary Command Output | Typical Entry Condition | Transition Condition | |---|---|---|---|---| | 10 | Filling | `Valve_Inlet_Cmd` | Start request, vessel not full, agitator off | `Level_High_Sw = 1` | | 20 | Mixing | `Agitator_Cmd` | Vessel full and inlet valve off | `Timer_Mix_Done.DN = 1` | | 30 | Draining | `Valve_Outlet_Cmd` | Mix complete and agitator off | `Level_Low_Sw = 1` or drain-complete condition |

### State 10: Filling

Purpose: Add material to the vessel until the high-level condition is reached.

Typical permissives:

• `Start_Cycle`
• `Level_Low_Sw`
• `Agitator_Off`
• No active fault or stop condition

Expected output behavior:

• `Valve_Inlet_Cmd = 1`
• `Agitator_Cmd = 0`
• `Valve_Outlet_Cmd = 0`

### State 20: Mixing

Purpose: Agitate the filled vessel for a defined interval.

Typical permissives:

• `Level_High_Sw`
• Inlet valve confirmed closed
• No active fault or stop condition

Expected output behavior:

• `Agitator_Cmd = 1`
• `Valve_Inlet_Cmd = 0`
• `Valve_Outlet_Cmd = 0`

### State 30: Draining

Purpose: Empty the vessel after mixing is complete.

Typical permissives:

• `Timer_Mix_Done.DN`
• `Agitator_Off`
• No active fault or stop condition

Expected output behavior:

• `Valve_Outlet_Cmd = 1`
• `Valve_Inlet_Cmd = 0`
• `Agitator_Cmd = 0`

Explicit state transitions are programmed by checking the current step value, verifying the transition permissive, and then moving the next step value into the sequence register. The key point is that the transition rung must prove both where the process is now and why it is allowed to move.

A simple pattern is:

[Language: Ladder Diagram]

// Transition from State 10 (Fill) to State 20 (Mix) |---[ EQU ]-------[ XIC ]-------[ XIO ]-----------------( MOV )---| | Source A: Level_High Agitator_Run Source: 20| | Seq_Step Feedback Dest: | | Source B: 10 Seq_Step |

This rung matters because `EQU Seq_Step 10` prevents the transition from firing anywhere except the Fill phase. Without that check, a stray true condition can move the process out of sequence. PLCs are obedient in a slightly dangerous way.

### Step 1: Create the sequence register

Create an integer tag such as:

• `Seq_Step`

Initialize it to an idle value or directly to `10` on cycle start, depending on your control philosophy.

A common pattern is:

• `0 = Idle`
• `10 = Filling`
• `20 = Mixing`
• `30 = Draining`

Spacing step values by tens is not mandatory, but it makes later edits easier.

### Step 2: Build state-driven output rungs

Each output should be commanded from the active state, not from a loose collection of conditions.

Example logic intent:

• If `Seq_Step = 10`, command inlet valve.
• If `Seq_Step = 20`, command agitator.
• If `Seq_Step = 30`, command outlet valve.

Conceptually:

|---[ EQU Seq_Step 10 ]--------------------------------( Valve_Inlet_Cmd )---| |---[ EQU Seq_Step 20 ]--------------------------------( Agitator_Cmd )------| |---[ EQU Seq_Step 30 ]--------------------------------( Valve_Outlet_Cmd )--|

Then add permissive or fault veto logic as needed, but keep the state declaration as the primary driver.

### Step 3: Program the Fill-to-Mix transition

Move from Filling to Mixing only when the vessel reaches the required level and the sequence is still in State 10.

Typical transition conditions:

• `Seq_Step = 10`
• `Level_High_Sw = 1`
• Optional confirmation that no incompatible output remains active

Conceptually:

|---[ EQU Seq_Step 10 ]---[ XIC Level_High_Sw ]----------------( MOV 20 -> Seq_Step )---|

### Step 4: Program the Mix timer and Mix-to-Drain transition

Use a timer instruction during State 20. When the timer is done, move to State 30.

Typical logic structure:

|---[ EQU Seq_Step 20 ]--------------------------------( TON Timer_Mix )---|

|---[ EQU Seq_Step 20 ]---[ XIC Timer_Mix.DN ]---[ XIO Agitator_Run ]----( MOV 30 -> Seq_Step )---|

Whether you require `Agitator_Run` feedback to be off before drain depends on whether you command stop first and confirm zero speed before transition. In real equipment, that distinction is not decorative.

### Step 5: Program the Drain completion transition

Drain completion can return the sequence to idle or to a ready state.

Typical transition conditions:

• `Seq_Step = 30`
• `Level_Low_Sw = 1` or vessel-empty confirmation

Conceptually:

|---[ EQU Seq_Step 30 ]---[ XIC Level_Low_Sw ]----------------( MOV 0 -> Seq_Step )---|

### Step 6: Add stop and fault handling outside normal progression

Faults should not be treated as ordinary transitions. They should interrupt or override sequence progression in a controlled way.

Typical fault or stop actions include:

• De-energize commanded outputs
• Freeze the current step for diagnosis, or move to a dedicated fault state
• Require operator reset before restart
• Log which permissive failed or which abnormal condition occurred

A fault state is often cleaner than trying to "fall through" to safe behavior using only output interlocks.

OLLA Lab is useful here because it lets you build the sequence, run it in simulation, inspect variables, and compare ladder state against simulated equipment behavior in one environment. That is the bounded value: not employability by osmosis, but repeatable rehearsal of high-risk validation tasks.

Build workflow in OLLA Lab’s ladder editor

Use the guided workflow in this order:

2. Define core tags:

• `Seq_Step`
• `Start_Cycle`
• `Level_High_Sw`
• `Level_Low_Sw`
• `Valve_Inlet_Cmd`
• `Agitator_Cmd`
• `Valve_Outlet_Cmd`
• `Timer_Mix`

1. Create a new project or open the Mixer preset.
2. Build the output rungs from `Seq_Step`.
3. Build transition rungs using `EQU` and `MOV`.
4. Add timer logic for State 20.
5. Add stop, reset, and fault behavior.
6. Run the simulation and observe tag changes scan by scan.

What to watch in the Variables Panel

The Variables Panel is where the sequence becomes testable rather than merely readable. Monitor:

• Current `Seq_Step`
• Input switch states
• Output command states
• Timer accumulated and done bits
• Any analog or status tags tied to the mixer preset
• Simulated equipment response in the 3D view

The engineering question is always the same: does the ladder state agree with the equipment state? If the answer is "mostly," keep testing.

OLLA Lab helps validate state machine behavior by giving engineers a deterministic environment to observe state transitions, force abnormal inputs, and verify that the sequence does not enter forbidden combinations. In this context, "simulation-ready" means able to prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

This matters because commissioning risk lives in edge cases, not in the happy path. Most bad sequences look fine until the wrong sensor changes at the wrong time.

Using the Variables Panel for fault injection

Use Simulation Mode to inject faults and test whether the state machine remains structurally correct.

Recommended fault tests for the mixer:

- Expected result: the process must remain in Drain or fault logic; it must not jump back to Mix

• Stuck high-level switch during Drain
• Force `Level_High_Sw = 1` while `Seq_Step = 30`

- Expected result: no invalid drain command should occur

• Premature low-level switch during Fill
• Toggle `Level_Low_Sw` unexpectedly during State 10

- Expected result: transition to Drain should be blocked or faulted, depending on design

• Agitator feedback mismatch
• Command mixing but simulate absent run feedback

- Expected result: outputs de-energize deterministically and restart behavior follows the defined recovery logic

• Interrupted cycle
• Apply stop or reset mid-batch

These tests are not academic extras. They are the difference between sequence validation and sequence optimism.

What digital twin validation means here

Digital twin validation, in this bounded context, means testing ladder logic against a realistic machine model so that the engineer can compare intended sequence state with observed equipment behavior before touching physical assets. It does not mean formal plant acceptance, SIL certification, or proof of site readiness by itself.

That distinction is important. A simulator can expose logic defects early. It cannot replace plant-specific hazard review, commissioning procedure, or management of change.

A useful portfolio artifact is a compact body of engineering evidence, not a screenshot gallery. The goal is to show that you can define correctness, test abnormal conditions, revise logic, and explain why the revision matters.

Use this structure exactly:

State the acceptance criteria: one active phase at a time, no valve overlap, timed mixing, deterministic stop behavior, and valid drain completion.

Explain the logic change: added permissive, fault latch, transition veto, or recovery state.

1. System Description Define the mixer process, I/O, sequence phases, and operating objective.
2. Operational definition of "correct"
3. Ladder logic and simulated equipment state Show the sequence register, transition rungs, and the corresponding simulated mixer behavior.
4. The injected fault case Document one abnormal condition such as a stuck level switch, missing agitator feedback, or interrupted cycle.
5. The revision made
6. Lessons learned State what the failure revealed about sequence design, scan behavior, or restart assumptions.

That kind of evidence is more credible than "here is my ladder screen." The useful question is whether the logic survives contact with process behavior.

This build aligns with ISA-88 because it separates procedural phases into explicit sequence states and ties equipment action to those states rather than burying the process inside undifferentiated boolean logic. That is not full batch recipe management, but it follows the same discipline: phase clarity, transition conditions, and controlled execution.

It also aligns with broader commissioning and safety practice in a limited but meaningful way:

- IEC 61508 thinking: Deterministic behavior and defined fault response are foundational to safe control system design, even though this article does not make a formal functional safety claim. - Digital commissioning literature: Simulation and virtual commissioning are widely recognized as useful for early defect detection, sequence validation, and reduced physical commissioning risk. - Human factors reality: Engineers often learn sequence robustness faster when they can observe cause and effect directly and test abnormal conditions without plant consequences.

The bounded conclusion is straightforward. A state machine does not make a process safe by itself. It gives the process a structure that can be tested, reviewed, and hardened. That is a better starting point than onion logic and crossed fingers.

Image concept: Split-screen view of the OLLA Lab Ladder Logic Editor and the Mixer digital twin. The left side shows the `MOV` instruction changing `Seq_Step` from 10 to 20. The right side shows the vessel reaching full level and entering the mixing phase.

Alt text: Screenshot of the OLLA Lab interface displaying a ladder logic state transition using a MOV instruction, alongside the 3D mixer digital twin showing the active filling phase triggered by State 10.

- ANSI/ISA-88.01 batch control model and terminology - IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety overview - Digital Twin in Manufacturing review (IFAC-PapersOnLine) - Virtual commissioning review (Procedia Manufacturing)