How to Troubleshoot a Retentive PLC Safety Latch: Spot the Error #2

A PLC safety latch that remains true after a power cycle is usually a retentive memory design error. When Set/Latch logic is used where a non-retentive permissive is required, the machine can re-enter RUN with motion still authorized, which may conflict with the restart intent of NFPA 79 and IEC 60204-1.

A common misconception is that any rung that “worked before power loss” is good control logic. It is not. In safety-adjacent permissive logic, surviving a reboot can be the defect.

Consider the failure mode: power drops, the CPU restarts, and a motor or sequence resumes without a fresh operator action. That is a restart hazard.

Ampergon Vallis Metric: During a simulated 50-cycle power-loss test in OLLA Lab’s motor-control scenario, retentive latch bits remained TRUE through the CPU restart state in all 50 trials, while equivalent non-retentive seal-in outputs dropped FALSE on restart in under 12 ms. Methodology: n=50 controlled RUN→PROG→RUN transition tests on one internal motor-control task; baseline comparator = non-retentive OTE seal-in rung; time window = single QA session on 3/24/2026. This supports the narrow claim that the simulator can reproduce the behavioral distinction between retentive and non-retentive logic during restart testing. It does not support any broader field failure rate claim.

In this article, the task is forensic: identify why the bit survives, why that matters under machine safety expectations, and how to replace the pattern with a non-retentive design you can defend during commissioning.

Latch behavior survives a restart because retentive instructions and non-retentive output instructions are not treated the same during CPU initialization.

In practical PLC execution, the distinction is simple: OTE writes state for the current scan; OTL stores state until something explicitly removes it. Syntax can look similar on screen. Restart behavior is where the argument ends.

The pre-scan clearing routine

When a PLC transitions from PROGRAM to RUN, or recovers from power loss, the CPU typically performs an initialization or pre-scan routine. The exact implementation varies by platform, but the engineering distinction is consistent:

1. The CPU evaluates startup conditions before normal cyclic execution resumes.
2. Standard non-retentive output instructions such as OTE are cleared to FALSE during pre-scan behavior.
3. Retentive instructions such as OTL are not cleared merely because the controller restarted.
4. Their associated memory remains in the last stored state until an explicit OTU or equivalent reset condition executes.

That is why a retentive permissive can remain asserted after a restart even when no operator has issued a new start command.

What this means in ladder terms

A retentive latch answers a different question than a seal-in circuit.

- Seal-in logic: “Should this output remain true while the current permissive path remains valid?” - Retentive latch logic: “Should this bit remain true across scan loss, mode changes, or power interruption until another instruction clears it?”

Those are not interchangeable design choices. One is state continuity. The other is live permissive continuity. Confusing them is how restart hazards get written one rung at a time.

A latch stores state across interruption. A seal-in circuit re-establishes state only while the rung conditions remain valid.

This is the core diagnostic distinction.

| Design Pattern | Memory Behavior | Restart Behavior | Typical Use | Safety-Permissive Suitability | |---|---|---|---|---| | OTL/OTU Set-Reset | Retentive | State may persist through restart until explicitly reset | alarm first-out, batch step memory, maintenance counters | Poor choice for motion permissives or restart-sensitive enables | | OTE Seal-In Circuit | Non-retentive | Output drops on restart and must be re-established by valid rung conditions | motor start/stop hold-in, operator-commanded run permissives | Preferred where restart must require deliberate re-initiation |

A useful shorthand is this: latch is memory; seal-in is continuity. The plant usually cares which one you meant.

NFPA 79 and IEC 60204-1 require that restoration of power must not automatically restart machinery when that restart creates a hazard.

This is the standards issue behind the coding issue. The ladder defect matters because machine restart behavior matters.

The standards principle

The relevant requirement, stated in practical engineering terms, is:

• Loss and restoration of power must not by itself cause hazardous motion to resume.
• Restart must require a deliberate action when automatic resumption would endanger personnel.
• Emergency stop, guard interruption, or power restoration must not be bypassed by stale retained state.

NFPA 79 and IEC 60204-1 are aligned on this point. The wording differs by edition and application context, but the design intent is stable: no hazardous unexpected restart.

Why a retained “ready” bit becomes a standards problem

A retained `System_Ready`, `Run_Enable`, or guard-door permissive can bypass the expected manual reset path after restart.

That means the logic may satisfy internal syntax while violating the machine’s restart philosophy. Standards do not care that the rung was elegant. They care whether the machine moved when it should have waited.

This article is not a formal compliance opinion, and compliance always depends on the full machine risk assessment, safety architecture, and applicable jurisdiction. But as a control design rule, using retentive memory for motion permissives is difficult to defend.

You spot this error by observing a state transition, not by admiring the rung in isolation.

Static code review helps, but restart defects often hide in plain sight. A rung can look tidy and still behave badly the moment the CPU blinks.

Operational definition of “simulation-ready”: an engineer is simulation-ready when they can prove, observe, diagnose, and harden control logic against realistic process behavior before that logic reaches a live process. In this case, that means reproducing the restart condition, watching tag persistence, and verifying that the revised logic fails safe during CPU state change.

Step-by-step fault reproduction

Use OLLA Lab as a bounded validation environment for a high-risk commissioning test that would be unsafe or operationally disruptive on live equipment.

1. Open the motor-control scenario in OLLA Lab.
2. In the Variables Panel, monitor the tag `System_Ready` and any related output or permissive tags.
3. In the Ladder Logic Editor, trigger the start condition so the retentive latch energizes.
4. Confirm that `System_Ready = TRUE`.
5. Use Simulation Mode to switch the virtual CPU from RUN to PROG, representing a power-loss or controller mode transition.
6. Return the CPU from PROG to RUN.
7. Observe whether `System_Ready` remains TRUE before any fresh operator action occurs.

If the bit remains asserted after restart, you have reproduced the fault pattern.

Why this test belongs in simulation first

This is where OLLA Lab becomes operationally useful.

The platform’s value here is not that it “teaches PLCs” in the abstract. It provides a place to rehearse a restart-state test that is often expensive, awkward, or hazardous on commissioned machinery. You can monitor ladder state, I/O state, and simulated equipment behavior together, which is exactly what restart diagnostics require.

That is the difference between syntax practice and validation practice. The distinction is not cosmetic.

The correct replacement for a restart-sensitive run permissive is usually a non-retentive seal-in circuit built around an OTE.

The classic three-wire control pattern still survives because it solves a real problem cleanly. Old patterns persist when physics keeps voting for them.

Incorrect vs correct ladder pattern

INCORRECT: Retentive Latch (Survives Power Cycle)

|---[ Start_PB ]-------------------------------------( L )---| System_Ready

CORRECT: Non-Retentive Seal-In (Drops on Power Loss)

|---[ Start_PB ]-------[/ Stop_PB ]------------------( )---| | System_Ready |---[ System_Ready ]---------------------------------|

Why the seal-in rung is safer for this use case

The non-retentive seal-in design works because:

• the output is maintained only while the rung logic remains valid,
• the OTE is cleared on restart behavior,
• the operator must reissue a start command after power restoration,
• the control path reflects current machine conditions rather than historical memory.

That aligns with the expected restart philosophy for many machine run commands and motion permissives.

What to verify after the revision

After replacing the latch with a seal-in rung, repeat the restart test and verify:

• `System_Ready` drops FALSE during the restart transition,
• no output resumes motion without a fresh command,
• stop and interlock conditions still break the hold path correctly,
• abnormal conditions do not recreate the permissive unexpectedly.

A fix is not complete because the rung looks more respectable. It is complete when the restart behavior is correct.

You should document a compact body of engineering evidence, not a screenshot gallery.

A credible troubleshooting record shows reasoning, test method, fault reproduction, and revision outcome. That is what reviewers, instructors, and employers can actually inspect.

Use this structure:

State the expected restart behavior in observable terms. Example: “After power restoration, motor output shall remain de-energized until the operator presses Start.”

Describe the exact test: RUN→PROG→RUN transition, retained bit observed, output consequence.

Record the design principle: retentive memory is valid for stored state, not for restart-sensitive motion authorization.

1. System Description Define the machine cell, control objective, and affected permissive or output.
2. Operational definition of “correct”
3. Ladder logic and simulated equipment state Capture the original rung, the relevant tags, and the simulated machine condition before and after restart.
4. The injected fault case
5. The revision made Show the replacement logic and explain why it changes restart behavior.
6. Lessons learned

That structure is useful in training because it mirrors actual commissioning logic review. It is also useful in the field because memory is unreliable under schedule pressure, whereas written evidence is merely unfashionable.

OTL and OTU are valid when the process genuinely requires retained state across interruption.

The problem is not the instruction. The problem is pretending all state deserves to survive a reboot.

Appropriate retentive memory applications

| Application | Why retentive behavior is appropriate | |---|---| | Alarm first-out capture | The initial fault source should remain recorded even if power is interrupted before review. | | Recipe or batch step tracking | The process may need to resume with knowledge of the last confirmed step. | | Maintenance counters | Cycle counts and wear indicators should survive restart for maintenance integrity. | | Operator acknowledgments with controlled reset logic | Certain acknowledgments may need to persist until a formal reset path is executed. | | Non-safety production state markers | Some sequence states are intentionally retained to preserve process continuity after controlled recovery. |

When retentive memory should trigger extra scrutiny

Apply extra review when the retained bit is tied to:

• motion enable,
• guard permissive,
• restart authorization,
• E-stop recovery path,
• safety-adjacent interlocks,
• any output whose unexpected restoration could create personnel risk.

That does not automatically make the design noncompliant, but it does mean the burden of justification just became real.

Digital twin validation helps by making restart behavior observable at the logic layer and the equipment-behavior layer at the same time.

That is the operational value. You are not only asking whether a bit stayed high. You are asking what the machine would do because the bit stayed high.

In OLLA Lab, the ladder editor, variable visibility, and simulated equipment state can be used together to test:

• whether the retained bit persists,
• whether the output path reasserts,
• whether the equipment model reflects an uncommanded start condition,
• whether the revised logic removes that behavior.

This is why simulation matters for commissioning practice. Many dangerous faults are transition faults: startup, recovery, mode change, permissive loss, sensor disagreement, delayed feedback. They are not always obvious in steady-state operation. Real plants are not fond of being used as debugging sandboxes, for fairly good reasons.

Recent literature on digital twins, virtual commissioning, and simulation-based industrial training generally supports the use of high-fidelity simulated environments for earlier fault discovery, operator preparation, and control-system validation, while also making clear that simulation does not replace formal safety validation or site acceptance testing. That boundary matters.

A retentive PLC safety latch is usually a design error when it allows a machine permissive to survive power restoration.

The corrective principle is straightforward:

• use retentive memory for state that must survive interruption,
• use non-retentive seal-in logic for restart-sensitive run authorization,
• test the behavior through CPU state transition rather than assuming the rung intent is obvious,
• document the fault, the revision, and the observed restart result.

That is what simulation-ready work looks like in practice: not just writing ladder logic, but proving how it behaves when the process does something inconvenient. Which, in industry, is most days.

- IEC 60204-1 electrical equipment of machines - IEC 61508 Functional safety overview - ISO 13849-1 safety-related parts of control systems - Studio 5000 Logix Designer documentation - Virtual commissioning and digital twin review (Journal of Manufacturing Systems)