How to Program State Machine Logic in a PLC for a 3-Phase Motor

To program state machine logic in a PLC, engineers divide a machine sequence into mutually exclusive states and transition between them explicitly. For a 3-phase motor, that usually means integer-based Off, Starting, Running, Stopping, and Fault states, which are easier to validate, troubleshoot, and harden than nested seal-in logic.

Nested seal-in logic is not "good enough" just because it runs on the first test. In sequential control, Boolean logic that looks tidy on a static screen can still produce race conditions, ambiguous recovery paths, and scan-dependent behavior when inputs chatter or faults arrive mid-sequence.

During internal testing of Ampergon Vallis's 3-phase motor preset in OLLA Lab, replacing nested seal-in contacts with an explicit integer-based finite state machine reduced observed race-condition fault events by 87% during simulated abnormal-stop trials [Methodology: n=30 simulation runs of the same 3-phase motor task, nested seal-in baseline comparator, test window February-March 2026]. This supports a bounded claim about one internal training preset under simulated fault injection. It does not establish a universal defect reduction rate across all PLC architectures, plants, or motor applications.

That distinction matters. Commissioning failures are usually born in edge conditions, not in the happy path.

Finite state machine logic is superior for sequential control because it makes machine behavior explicit, mutually exclusive, and deterministic. A properly built FSM allows the PLC to evaluate the rules for the current state, then transition only when defined conditions are met.

Nested seal-in rungs do the opposite. They often spread sequence memory across multiple bits, permissives, latches, and interlocks that interact indirectly. The result is logic that may still work, but only until timing, feedback loss, or abnormal shutdown exposes the hidden coupling. Syntax is not the same thing as deployability.

IEC 61131-3 does not mandate one universal sequential pattern, but its program organization model strongly supports structured, readable, maintainable control logic for state-based sequencing in PLC applications (IEC, 2013). In practice, FSMs have become a common architecture for machine sequences because they are easier to reason about, test, and recover after faults.

A useful operational definition is this:

- Finite State Machine in ladder logic: a control architecture in which one state variable represents the current machine mode, only one valid state is active at a time, and transitions occur through explicit conditions that assign the next state.

That last clause is the whole game. If the transition is not explicit, the machine is relying on side effects.

Onion Logic vs. State Machine Architecture

| Engineering Factor | Nested Seal-In / "Onion Logic" | Finite State Machine | |---|---|---| | Active sequence memory | Distributed across bits and latches | Centralized in one state variable | | Scan cycle behavior | Can become order-sensitive and ambiguous | Deterministic when transitions are explicit | | Fault recovery | Often inferred from several conditions | Explicit fault state, e.g. `99` | | Troubleshooting | Trace many interacting bits | Read current state integer first | | Sequence expansion | Brittle as branches grow | Easier to insert intermediate states | | Validation in simulation | Harder to isolate failure path | Clear transition-by-transition testing |

Senior controls engineers reject onion logic for the same reason they reject unlabeled field wiring: the system may still run, but nobody should have to guess why.

A 3-phase motor sequence requires more than an On and Off bit because real equipment has transition behavior, feedback timing, and fault handling. Even a simple motor starter usually needs explicit treatment of permissives, start confirmation, stop behavior, and trip recovery.

A practical FSM for a 3-phase motor commonly uses these states:

1. State 0 — Off / Ready Motor is de-energized. Required permissives are healthy. The sequence is waiting for a valid Start command.
2. State 10 — Starting Start output has been issued. The logic is waiting for expected feedback, such as auxiliary contact proof, run status, speed confirmation, or a timed start window.
3. State 20 — Running The motor is in steady-state operation. The logic continues to monitor stop commands, overloads, permissive loss, and abnormal feedback.
4. State 30 — Stopping A stop command or controlled shutdown has been initiated. The logic waits for de-energization confirmation, zero-speed feedback, or timeout completion.
5. State 99 — Fault A trip, failed proof, overload, or invalid sequence condition has occurred. Outputs are driven to the defined safe response, and reset logic is handled explicitly.

Using increments of 10 is a practical engineering habit because it leaves room for later insertion of states such as `15 = Start Verify` or `25 = Coastdown Confirm` without renumbering the entire sequence.

Why transition states matter in real motor control

Transition states exist because motors interact with electrical and mechanical reality, not just ladder symbols. Depending on the application, the control sequence may need to account for:

• contactor pull-in time
• star-delta transfer timing
• VFD acceleration and deceleration
• proof feedback from auxiliary contacts
• permissive loss during operation
• overload relay trips
• downstream process interlocks
• zero-speed or stopped confirmation

This is also where "Simulation-Ready" needs a precise definition.

- Simulation-Ready: able to prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

That means more than writing a rung that compiles. It means validating whether the ladder state, I/O state, and simulated equipment state remain coherent under normal and abnormal conditions.

A ladder-based FSM is built by reading the current state with a comparator and writing the next state with an explicit move. In OLLA Lab, that work happens in the ladder editor, the variables panel, and simulation mode.

OLLA Lab should be understood here as a bounded validation and rehearsal environment. It is useful because it lets engineers practice high-risk commissioning behaviors such as logic validation, I/O observation, fault injection, and revision without using live equipment as a teaching aid.

### Step 1: Define the state integer

Create a tag such as:

- `Motor_State` : `INT`

This integer is the single source of truth for the machine's current sequence state.

Recommended companion tags include:

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Step 2: Build the Off-to-Starting transition

The first transition usually moves the motor from ready state to starting state when permissives and a start request are present.

Example logic concept:

• If `Motor_State = 0`
• and `Start_PB = TRUE`
• and no trip is active
• and required permissives are healthy
• then `MOV 10` into `Motor_State`

This is the basic pattern:

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Step 3: Build the Starting-to-Running transition

The starting state should confirm that the motor actually reached the expected condition. That confirmation may be an auxiliary contact, run feedback, flow proof, rotation proof, or a timing condition depending on the application.

Example logic concept:

• If `Motor_State = 10`
• and `Aux_Run_Proof = TRUE`
• then `MOV 20` into `Motor_State`

If proof is not received within the allowed time, transition to fault instead.

• If `Motor_State = 10`
• and `Start_Timer.DN = TRUE`
• and `Aux_Run_Proof = FALSE`
• then `MOV 99` into `Motor_State`

### Step 4: Build the Running-to-Stopping transition

The running state should monitor both commanded stops and abnormal conditions.

Example logic concept:

• If `Motor_State = 20`
• and `Stop_PB = TRUE`
• then `MOV 30` into `Motor_State`

Also include trip handling:

• If `Motor_State = 20`
• and `OL_Trip = TRUE`
• then `MOV 99` into `Motor_State`

### Step 5: Build the Stopping-to-Off transition

The stopping state should wait for the motor to reach the expected stopped condition.

Example logic concept:

• If `Motor_State = 30`
• and stopped confirmation is true
• then `MOV 0` into `Motor_State`

Where no physical stopped proof exists, a bounded timer may be used, but that should be a conscious design choice rather than a guess dressed as certainty.

### Step 6: Build the explicit fault state

The fault state should de-energize outputs and require a defined reset path. In many applications, that means no automatic restart after overload or failed proof unless the control philosophy explicitly permits it.

Example logic concept:

• If `Motor_State = 99`
• force `Motor_Output = FALSE`
• require `Reset_PB = TRUE`
• require trip cleared
• then `MOV 0` into `Motor_State`

Ladder pattern summary

A clean FSM rung pattern in OLLA Lab typically follows this sequence:

• `EQU` to identify the current state
• one or more `XIC` / `XIO` conditions to validate the transition
• `MOV` to write the next state

Example ladder pattern:

• `EQU Motor_State 10` and `XIC Aux_Run_Proof` then `MOV 20 -> Motor_State`
• `EQU Motor_State 10` and `XIO Aux_Run_Proof` and `XIC Start_Timer.DN` then `MOV 99 -> Motor_State`

Image alt text: Screenshot of the OLLA Lab ladder logic editor showing a finite state machine rung where an EQU block checks whether Motor_State equals 10, an input condition verifies Aux_Run_Proof, and a MOV block transitions Motor_State to 20.

Outputs should be derived from the active state, not used as hidden memory for the sequence. This distinction is easy to miss and expensive to ignore.

A common pattern is:

• energize `Motor_Output` when `Motor_State = 10` or `Motor_State = 20`
• de-energize it in `0`, `30`, and `99` unless the stopping philosophy requires a controlled hold

That gives you a direct relationship between sequence intent and commanded output. It also makes simulation and troubleshooting cleaner because the output becomes a consequence of state, not a second undocumented state machine.

Example output logic

• If `Motor_State = 10` OR `Motor_State = 20`
• then `Motor_Output = TRUE`

• If `Motor_State = 0`, `30`, or `99`
• then `Motor_Output = FALSE`

For more complex motor systems, such as reversing starters, star-delta transitions, or VFD bypass arrangements, each actuator command should still remain state-derived and interlocked explicitly.

The most common FSM failure is a hung state. A hung state occurs when the machine enters a valid state but never satisfies the conditions required to leave it.

That is why simulation matters. It lets you observe causality before hardware, mechanics, and schedule pressure complicate diagnosis.

In OLLA Lab, troubleshooting an FSM should follow a simple sequence:

1. Read the current state integer first Check `Motor_State` in the variables panel. Do not start by guessing which rung looks wrong.
2. Verify the expected transition condition If the motor is in `State 10`, confirm whether `Aux_Run_Proof` actually changes, whether the timer is running, and whether permissives remain true.
3. Check ladder state against simulated equipment state The ladder may command a motor output, but the simulated equipment may still show failed proof, delayed response, or faulted behavior.
4. Inject a fault deliberately Toggle `OL_Trip` during `State 20` and confirm that the sequence transitions immediately to `State 99`.
5. Verify safe response Confirm that motor outputs de-energize as required and that the machine cannot resume operation until reset conditions are met.

This is where OLLA Lab becomes operationally useful. It allows the learner to compare the control-state integer, I/O conditions, and equipment behavior in one place, which mirrors the work commissioning engineers do under pressure.

A practical fault-injection test

Use this bounded test case:

• Start from `State 0`
• Issue a valid start command
• Confirm transition to `State 10`
• Confirm proof feedback and transition to `State 20`
• Force `OL_Trip = TRUE`
• Verify immediate transition to `State 99`
• Verify `Motor_Output = FALSE`
• Clear trip and issue reset
• Verify transition back to `State 0`

If any of those steps fail, the problem is no longer abstract. You now have a reproducible defect case.

Digital twin validation, in this article, means testing ladder logic against a realistic simulated machine model so that sequence behavior can be observed under both normal and abnormal conditions before deployment. It does not mean the simulation is a legal substitute for site acceptance, functional safety verification, or commissioning signoff.

That boundary is important. A digital twin can improve sequence validation, training realism, and fault rehearsal, but it does not eliminate the need for plant-specific review, device verification, and formal safety lifecycle activities under standards such as IEC 61508 where applicable (IEC, 2010; exida, 2024).

In OLLA Lab, digital twin validation is operationally useful when the engineer can do all of the following:

• compare ladder state to simulated equipment behavior
• observe whether I/O transitions occur as intended
• inject faults and verify safe-state response
• revise logic after failure
• rerun the same scenario to confirm the fix

That is the difference between syntax practice and commissioning rehearsal.

A screenshot gallery is not engineering evidence. It is only a partial record.

If you want to demonstrate real control competence, build a compact body of evidence using this structure:

1. System Description Define the machine or process unit, its objective, and the relevant I/O.
2. Operational definition of correct behavior State what the sequence must do, what feedback it must receive, and what constitutes a valid safe response.
3. Ladder logic and simulated equipment state Show the state logic, output logic, and the corresponding simulated behavior.
4. The injected fault case Document the abnormal condition you introduced, such as overload trip, failed start proof, or permissive loss.
5. The revision made Explain what logic changed and why.
6. Lessons learned Record what the failure revealed about sequence design, assumptions, or missing interlocks.

This structure is more credible because it shows reasoning, failure handling, and revision discipline. A clean rung alone does not show whether the logic survives realistic conditions.

Structured sequential control, simulation-based validation, and fault-aware testing are well aligned with established engineering practice, although the exact implementation varies by sector and risk class.

Relevant grounding includes:

• IEC 61131-3 for PLC programming languages and structured control implementation principles (IEC, 2013)
• IEC 61508 for functional safety lifecycle thinking, especially where abnormal conditions and safe-state behavior matter (IEC, 2010)
• exida guidance on safety lifecycle discipline, verification rigor, and the difference between logic intent and validated behavior in industrial systems (exida, 2024)
• research literature across industrial simulation, digital twins, and immersive training environments showing that simulated environments can improve procedural understanding, fault rehearsal, and system-level learning when they are tied to observable task performance rather than novelty alone (Tao et al., 2019; Jones et al., 2023; Villalonga et al., 2021)

The careful conclusion is not that simulation replaces site work. It is that simulation can shift expensive learning left, where mistakes are cheaper and more visible.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)