How to Troubleshoot a Double-OTE Race Condition in Ladder Logic

A double-OTE race condition occurs when a PLC program writes to the same output coil more than once in a single scan. Because ladder logic executes sequentially, the final rung overrides earlier commands. The fix is architectural: consolidate output control, validate scan behavior, and verify the result against simulated equipment response.

A conveyor does not ignore a stop command because the PLC is “confused.” It ignores it because the program told it two different things in one scan, and the last instruction won.

In a recent review of 500 beginner submissions built on the OLLA Lab conveyor scenario, 68% introduced a duplicate write to the same motor-run bit when adding a secondary stop or permissive condition [Methodology: n=500 conveyor troubleshooting submissions, task defined as modifying a baseline single-motor conveyor to add one abnormal-condition stop path, comparator was the original single-OTE reference solution, time window January 15-March 15, 2026]. This internal Ampergon Vallis metric supports one narrow point: visual inspection alone often misses destructive output duplication in novice ladder edits. It does not support any broader claim about industry defect rates.

This is exactly where a simulation environment becomes operationally useful. The issue is not syntax. The issue is deployability under scan-cycle reality.

A double-OTE error occurs when the same output address or tag is written by more than one Output Energize instruction during a single PLC scan.

In ladder logic, the PLC typically executes a repeating cycle:

1. Read inputs
2. Execute logic
3. Update outputs
4. Perform housekeeping and communications

That sequence is deterministic. The processor does not “average” conflicting output instructions or negotiate between them. It executes them in order.

If `MTR_1_Run` is energized on rung 3 and then de-energized or re-energized differently on rung 15, the later rung defines the final state written to the output image. On real equipment, that can mean a motor keeps running after a jam input, or a contactor chatters under conflicting logic.

The “Last Rung Wins” Rule

The “last rung wins” rule is the practical consequence of sequential execution.

A PLC does not usually drive the physical output card the instant it encounters an OTE instruction in the program. It updates the internal output image as logic executes, then writes the resulting state to the physical outputs at the end of the scan. If multiple rungs write to the same bit, the last executed write is the one that survives.

This is why duplicate coils are not merely untidy style. They are destructive ambiguity encoded as deterministic behavior.

Why this matters physically, not just logically

A double-OTE fault is not only a software defect. It can create mechanical consequences.

On conveyors and motor-driven systems, conflicting run/stop commands can produce:

• ignored stop conditions,
• intermittent contactor chatter,
• nuisance trips,
• premature wear on starters and relays,
• product collisions,
• sequence loss between upstream and downstream equipment.

The code may look readable and still be wrong in operation. Commissioning has a low tolerance for elegant mistakes.

The conveyor crashed because the stop condition was overwritten later in the scan by a second rung commanding the same motor-run output.

Here is the scenario logic in plain terms:

- The objective: Stop the conveyor when photoeye `PE_1` detects a jam. - The intended behavior: A jam should remove the run command to `MTR_1_Run`. - The error: An earlier rung drops `MTR_1_Run` on jam, but a later rung reasserts `MTR_1_Run` using an upstream-clear permissive and system-run condition. - The result: The jam stop exists in the code but not in the final output state.

That is the paradox operators dislike: the sensor worked, the rung looked right, and the conveyor still drove product into a blockage.

Example of the destructive pattern

Rung 3: `[NOT PE_1_Jam] ------------------------------- (OTE) [MTR_1_Run]`

Rung 15: `[Upstream_Clear] -- [System_Run] ------------- (OTE) [MTR_1_Run]`

If `PE_1_Jam` goes true, rung 3 drops the motor run bit. If rung 15 remains true later in the same scan, `MTR_1_Run` is set again. The conveyor runs. The jam remains.

What the fault looks like in operation

In a simulated conveyor line, the visible symptoms typically include:

• product continuing into an occupied zone,
• no effective response to the jam photoeye,
• motor command state appearing inconsistent with the intended stop logic,
• intermittent operator confusion because the HMI or logic view may show one condition while the final output state reflects another.

This is why troubleshooting by static screenshot is weak evidence. You need state visibility across the scan and across the machine model.

PLC race conditions in ladder logic are usually not “race conditions” in the software-threading sense. They are deterministic state conflicts created by scan order, duplicate writes, asynchronous input changes between scans, or poorly partitioned sequencing logic.

In this article, the race condition is specifically a scan-order overwrite.

The mechanism is straightforward:

• the PLC reads the current input image,
• rung logic executes in sequence,
• multiple instructions target the same output bit,
• the last write defines the final output image,
• the machine reacts to that final state, not to the programmer’s intention.

This matters because many new programmers assume each rung acts independently on the real machine. It does not. The scan is one execution pass, and the machine only sees the resulting image state. Ladder logic is forgiving about syntax and unforgiving about architecture.

Common causes of duplicate-write faults

The most common engineering causes are:

• adding a second stop path without consolidating the original run logic,
• mixing permissives and commands across separate rungs that target the same physical output,
• patching faults during debugging instead of redesigning the output structure,
• using physical output tags directly inside multiple sequence sections,
• failing to separate internal state logic from final output mapping.

A useful contrast is this: draft generation versus deterministic veto. The PLC will happily execute both rungs. It will not warn you that one silently invalidated the other.

You spot a double-OTE race condition by observing the output tag state, the triggering conditions, and the simulated equipment response together rather than inspecting ladder syntax in isolation.

This is where OLLA Lab is credibly useful as a validation and rehearsal environment. It does not replace field commissioning, and it does not confer site competence by association. What it does provide is a safe place to observe cause-and-effect that would be expensive, fast, or unsafe to study on live equipment.

Use the Variables Panel as a diagnostic instrument

The Variables Panel is useful because it exposes the tag-level state changes that static ladder review can hide.

For this fault, watch at least these tags:

• `PE_1_Jam`
• `Upstream_Clear`
• `System_Run`
• `MTR_1_Run`

The diagnostic pattern is:

• `PE_1_Jam` changes to true,
• the earlier rung logically removes the run condition,
• a later rung still evaluates true,
• `MTR_1_Run` returns to true by the end of the scan,
• the conveyor digital twin continues moving despite the jam condition.

That is diagnostic proof of overwrite behavior, not just suspicion.

Slow the execution to inspect cause-and-effect

The scan-time control is useful because it makes rapid state transitions easier to inspect.

When available in the scenario workflow, slow the execution enough to observe:

1. the input transition,
2. the earlier rung response,
3. the later rung overwrite,
4. the final output state,
5. the equipment response in the conveyor model.

On a live system, these transitions are often too fast to observe cleanly without trend tools, forcing logic cross-reference, and a calm day that the plant did not schedule for you.

Compare ladder state against equipment state

The real value of simulation is not that you can see a rung turn green. It is that you can compare logic state against machine behavior.

For this conveyor case, verify whether:

• the ladder indicates a jam condition,
• the motor-run bit remains asserted at scan completion,
• the simulated conveyor still advances product,
• the collision or jam consequence appears in the equipment model.

That comparison is what makes the environment simulation-ready in an operational sense: the engineer can observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

The correct architecture is to let one rung, one routine, or one clearly bounded mapping layer own the final physical output command.

The rule is simple: one physical output, one final writer. Everything else should feed that decision, not compete with it.

### Method 1: Parallel branching for consolidated OR logic

Parallel branching is a clean solution when multiple permissives or command paths should drive one output decision.

Instead of writing `MTR_1_Run` in multiple rungs, combine the logic into one rung with explicit branches and stop conditions.

Example structure:

`[System_Run] -- [Upstream_Clear] -- [NOT PE_1_Jam] -- [NOT EStop_Active] -- (OTE) [MTR_1_Run]`

Or, where multiple valid run requests exist, use branch logic upstream of a single final OTE.

This approach is usually the most readable for straightforward motor control.

### Method 2: Latch/Unlatch (OTL/OTU) with caution

Latch and unlatch instructions can be appropriate for retained command states, sequence steps, or operator requests, but they require discipline.

Use them carefully because:

• retained states can survive conditions the programmer forgot to clear,
• restart behavior after power loss or mode transitions must be explicitly considered,
• safety-related behavior should never rely on casual latch logic.

For safety functions, the governing design basis must come from the applicable safety architecture and standards, not from convenience in ladder drafting.

### Method 3: Intermediate tagging with final output mapping

Intermediate tags are often the most scalable solution in larger machines or process skids.

The pattern is:

• compute internal conditions using memory bits,
• separate permissives, trips, requests, and sequence states,
• map those internal states to one final physical output in a dedicated output routine.

Example:

`Rung 5: [System_Run] -- [Upstream_Clear] -------------------- (OTE) [Run_Request]` `Rung 6: [PE_1_Jam] ------------------------------------------ (OTE) [Jam_Trip]` `Rung 20: [Run_Request] -- [NOT Jam_Trip] -- [NOT EStop_Active] ---- (OTE) [MTR_1_Run]`

This architecture improves traceability because the final output decision is explicit.

You should document engineering evidence, not a gallery of screenshots.

If you want to demonstrate real troubleshooting skill, use this compact structure:

State observable acceptance criteria, such as: “If `PE_1_Jam = TRUE`, then `MTR_1_Run = FALSE` by scan completion, and conveyor motion stops in the digital twin.”

Document the architectural correction: consolidated rung, intermediate tag design, or revised sequence ownership.

Capture the engineering principle, such as: “Physical outputs require a single final writer,” or “abnormal-condition logic must be validated against final scan state, not only rung-local intent.”

1. System Description Define the conveyor section, motor command, jam sensor, upstream permissive, and expected sequence.
2. Operational definition of correct behavior
3. Ladder logic and simulated equipment state Include the relevant rung set and the corresponding equipment state before the fix.
4. The injected fault case Show the duplicate OTE or competing write path and the exact condition under which it overrides the stop logic.
5. The revision made
6. Lessons learned

That kind of evidence is useful in training, peer review, and commissioning rehearsal because it shows reasoning, not just software possession.

The core execution model comes from IEC 61131-3 practice: PLC programs execute deterministically according to the language and runtime model implemented by the controller platform.

The risk argument is also well grounded. Functional safety literature consistently distinguishes between intended control behavior and verified behavior under faulted or abnormal conditions. That distinction matters here because duplicate writes can invalidate intended protective logic without producing a syntax error.

The simulation argument should also be kept bounded. A digital twin or simulated machine model does not certify field readiness on its own. What it does support, when used properly, is earlier fault discovery, safer rehearsal of abnormal conditions, and more observable validation of sequence behavior before commissioning.

OLLA Lab fits as a web-based validation and rehearsal environment for ladder logic, simulated I/O behavior, and digital-twin-aligned troubleshooting.

In this specific use case, it is useful for:

• building and editing ladder logic in the browser,
• running the conveyor scenario without physical hardware,
• monitoring tags in the Variables Panel,
• comparing ladder state to simulated machine behavior,
• rehearsing abnormal conditions such as jams, permissive loss, and stop-path revisions,
• documenting the fix as an engineering evidence package.

That is a credible scope.

- Read: Understanding Scan Cycles: How OLLA Lab Mimics Real Hardware. - Read: Seal-In vs. Latch: Why Professional Engineers Choose Carefully. - Test the fault safely in practice: Open the Conveyor Crash Preset in OLLA Lab.

• For a complete breakdown of IEC 61131-3 programming structure and ladder fundamentals, visit the Ladder Logic Mastery Hub.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - PLC scan-cycle fundamentals (AutomationDirect) - IEC 61508 Functional safety overview - Race conditions and synchronization concepts (NIST glossary) - Digital twin validation for control logic (IFAC-PapersOnLine)