Seal-In Latch Instability in PLC Programs

Seal-in logic is one of the most common structures in industrial automation.

A momentary START signal energizes a run command. A contact associated with that command then maintains the state after the original START signal disappears. The command remains active until a STOP, fault or another reset condition breaks the circuit.

A simplified version looks like this:

Stop_Healthy AND
(Start_Request OR Motor_Run)
→ Motor_Run

The concept is straightforward. It has been used for decades in hardwired motor-control circuits and is equally common in PLC programs.

Yet seal-in logic is also responsible for many intermittent commissioning problems.

A motor may restart after power restoration, an output may flicker, a start command may occasionally be ignored or a machine may remain latched after a fault. The logic looks correct whenever someone monitors it online, making the problem difficult to reproduce.

The latch is rarely unstable by itself. Instability usually comes from the signals surrounding it, the way the state is stored or another part of the program writing to the same command.

How a Seal-In Circuit Works

A basic PLC latch contains:

• A momentary start request
• A stop condition
• A run command
• A feedback contact from the run command

When START becomes true, the PLC sets Motor_Run.

The Motor_Run contact then creates another true path around the momentary START condition. When START returns to false, the command remains active because the feedback path is still complete.

When STOP becomes active—or Stop_Healthy becomes false—the path is broken and Motor_Run turns off.

Under ideal conditions, this works reliably.

Real systems add more variables:

• HMI commands
• Remote I/O
• Automatic sequence requests
• Manual operation
• Safety status
• Drive communication
• Fault resets
• Retained memory
• Maintenance bypasses

The rung may still look simple, but the state it controls is no longer simple.

Why Latched States Are Difficult to Troubleshoot

A latch remembers an earlier event.

When a technician opens the program, START may already be false while the motor command remains true. The live conditions explain why the command stays active, but they may not show what originally started it.

The starting event may have occurred:

• Several scans earlier
• Before an alarm appeared
• During an HMI update
• While remote I/O was reconnecting
• Immediately after the PLC entered RUN
• During a brief communication recovery

Without event history, the original trigger disappears.

This is why intermittent latch problems often behave correctly while someone is watching. The timing combination that caused the problem has already passed.

Input Bounce Can Create Multiple Commands

Mechanical push buttons and relay contacts do not always switch cleanly.

When a contact changes state, it may bounce between open and closed several times before settling. Input modules usually include filtering, but the filter setting may not eliminate every transition.

A bouncing START input can produce:

• Several rising edges
• Repeated sequence requests
• Multiple counter increments
• Unexpected retriggering
• Conflicting start and stop states

In an ordinary seal-in circuit, repeated START transitions may not matter after the latch has already been established. They become more important when START also resets timers, advances a sequence or clears another state.

A bouncing STOP input may briefly interrupt the latch and allow it to re-establish on the following scan if the start request remains active.

Use appropriate input filtering or software debouncing, but do not apply excessive delay to stop-related functions. Standard PLC stop logic must also not be confused with a safety-rated emergency-stop circuit.

Asynchronous Inputs Can Miss Each Other

A start request and its required permissives may come from different systems.

For example:

• START comes from an HMI.
• Drive ready comes through PROFINET.
• Air pressure comes from remote I/O.
• Safety healthy comes from a safety controller.
• Valve position comes from a local input.

These signals do not necessarily update during the same PLC scan.

The operator may press START while the HMI shows that every permissive is healthy. Inside the PLC, the short start request may arrive during one scan and the final permissive during the next.

The program could see:

Scan 1:
Start_Request = TRUE
Drive_Ready = FALSE

Then:

Scan 2:
Start_Request = FALSE
Drive_Ready = TRUE

The required conditions never overlap, so the latch is not established.

From the operator’s perspective, the PLC ignored a valid command. In reality, the command and permissive were never true together in the executing task.

A better design may hold the start request until it is accepted, rejected or cancelled:

IF Start_Button THEN
    Start_Request_Latched := TRUE;
END_IF;

IF Start_Accepted OR Stop_Required THEN
    Start_Request_Latched := FALSE;
END_IF;

The retained request must still have a timeout and clear cancellation rules. It should not remain waiting indefinitely and start the machine unexpectedly when a permissive returns much later.

Duplicate Output Writes Create Flicker

One of the most common latch faults is writing to the same tag from multiple locations.

For example:

Network 1:
Start/stop latch → Motor_Run

Network 20:
Automatic sequence → Motor_Run

Network 35:
Fault logic → Reset Motor_Run

Network 60:
Maintenance mode → Motor_Run

Each network may appear correct individually. Together, they create several competing owners.

During one scan, an early network can turn the tag on and a later network can turn it off. Online monitoring may show one coil energized while the physical output remains off because another assignment overwrote it later.

If conditions change between scans, the command may appear to flicker.

Use cross-reference tools to find every write to:

• Physical outputs
• Motor commands
• Latch bits
• Sequence states
• Mode selections
• Fault memories

A strong design gives the final command one assignment point:

Motor_Run :=
    Safety_Healthy
    AND Motor_Permissive
    AND NOT Fault_Active
    AND NOT Stop_Required
    AND
    (
        Automatic_Run_Request
        OR Manual_Run_Request
    );

Requests may come from several places. The final output should have one clear owner.

Stale Permissives Can Keep a Latch Alive

A remote permissive may remain at its last valid state after communication fails.

Suppose a remote drive reports:

Drive_Ready = TRUE

The network connection is then lost. If the PLC retains the last received value, Drive_Ready may still appear true.

The seal-in circuit continues to see a healthy permissive even though the source device is no longer communicating.

A valid permissive should include communication quality:

Drive_Permissive :=
    Drive_Communication_Healthy
    AND Drive_Data_Valid
    AND Drive_Ready;

The same principle applies to analog conditions. A pressure value of 5 bar is not trustworthy merely because the tag still contains that number. The program must know that it has been updated recently and carries valid quality.

Stale data is dangerous because it often looks completely normal.

Retentive Latches and Unexpected Restart

A latched run command may be configured as retentive, intentionally or accidentally.

If power fails while Motor_Run is true, the bit may remain true after the PLC restarts. The physical motor may initially stay off because other conditions are unavailable.

Later:

1. Remote I/O reconnects.
2. The safety system is reset.
3. The drive becomes ready.
4. The output supply returns.
5. The retained run command becomes effective again.

The machine may then restart without a new START action.

This behaviour is particularly deceptive because the restart may not happen immediately after power restoration. It can occur several seconds later when the final permissive returns.

Run commands should generally be reinitialized to a defined safe state after power-up unless the machine design and risk assessment explicitly permit automatic restart.

Retained settings and recipes are different from retained movement commands. Do not treat them the same way.

Missing Fault Reset Logic

A motor may remain latched after a fault because the fault only blocks the physical output without clearing the internal run request.

For example:

Motor_Output :=
    Motor_Run_Latched
    AND NOT Fault_Active;

When a fault occurs, the physical output turns off, but Motor_Run_Latched remains true.

As soon as the fault clears, the output can turn on again automatically.

That may be appropriate for some process applications, but in many machines it creates an unexpected restart.

The program must define what a fault does to the stored request:

• Does the fault cancel the request?
• Does the request remain pending?
• Is a separate reset required?
• Is a fresh START command required?
• Can automatic operation resume?
• Must the machine enter a recovery state?

These decisions should be deliberate.

A common structure is:

IF Fault_Active OR Stop_Required THEN
    Motor_Run_Latched := FALSE;

ELSIF Start_Request AND Start_Permissive THEN
    Motor_Run_Latched := TRUE;
END_IF;

This ensures that a stop or fault clears the stored run command.

Active Fault and Reset at the Same Time

Set-reset structures become unpredictable when the set and reset conditions are both active during one scan.

Consider:

Fault_Condition → SET Fault_Latched
Reset_Request   → RESET Fault_Latched

The result can depend on execution order.

If RESET is processed last, the fault latch may clear briefly even though the fault condition remains active. Another part of the program may interpret that brief state as permission to continue.

Give the active fault explicit priority:

IF Fault_Condition THEN
    Fault_Latched := TRUE;

ELSIF Reset_Request AND Recovery_Conditions_Valid THEN
    Fault_Latched := FALSE;
END_IF;

This produces one predictable outcome when the two conditions overlap.

The same principle applies to START and STOP. Stop should normally override start rather than relying on accidental ladder order.

Remote STOP Timing

A STOP input connected through remote I/O does not reach the PLC instantly.

The signal passes through:

• Push-button contact
• Input-module filter
• Remote station update
• Network transmission
• PLC task execution
• Output update
• Actuator response

If communication becomes unstable, the delay may increase or the remote station may apply its configured substitute behaviour.

The system design must define what happens when the remote station is lost:

• Are outputs de-energized?
• Are their last states retained?
• Does the PLC receive a fault immediately?
• Is restart blocked after communication returns?
• Must the operator issue a fresh start?

For safety functions, standard remote I/O and ordinary PLC logic may be inadequate. Required safety behaviour must be implemented with suitable safety-rated hardware, communication and validation.

Online Edits Can Alter Latch Behaviour

Online modifications can affect a live latch in unexpected ways.

Changes may alter:

• Network execution order
• Initialization behaviour
• Set and reset priority
• Temporary variable states
• Function-block memory
• Scan time
• Transition conditions

A new contact inserted into a seal-in path may immediately break an active latch. A changed reset condition may leave the command set indefinitely. Moving logic can also change which duplicate assignment executes last.

Before applying an online change, determine:

• Current latch state
• Machine operating state
• Possible effect of the edited network
• Whether the output could energize or drop out
• Whether a controlled stop is required
• How the latch will be reinitialized afterward

A logically correct edit can still create an unsafe transition when introduced into a running process.

Manual and Automatic Requests Can Fight

A single motor is often controlled from both manual and automatic modes.

An unstable design may use the same latch in both sections:

Manual_Start → SET Motor_Run
Auto_Request → SET Motor_Run
Manual_Stop  → RESET Motor_Run
Auto_Stop    → RESET Motor_Run

Now the result depends on several unrelated commands.

A mode change can also leave the latch from the previous mode active.

A better structure separates requests:

Manual_Run_Request
Automatic_Run_Request

Then selects the active request according to mode:

Selected_Run_Request :=
    (Manual_Mode AND Manual_Run_Request)
    OR
    (Automatic_Mode AND Automatic_Run_Request);

The final command is created only after applying faults, stops and permissives.

Define what happens during mode changes. A transfer from automatic to manual should not preserve an old automatic run request unless that behaviour is specifically intended.

Bypasses Can Conceal the Real State

A bypass is often added directly into a latch permissive:

Valve_Ready := Valve_Open_Feedback OR Valve_Bypass;

When the bypass is active, the program treats the valve as healthy even if it is physically closed.

The motor latch may then remain active under a false condition.

Preserve the distinction between real and bypassed status:

Valve_Feedback_Healthy := Valve_Open_Feedback;

Valve_Start_Permitted :=
    Valve_Open_Feedback
    OR
    (
        Valve_Bypass
        AND Maintenance_Mode
        AND Bypass_Authorized
    );

Display and alarm the bypass separately.

A bypass may permit controlled maintenance operation, but it should not silently turn an unhealthy field condition into a healthy diagnostic state.

Building a Stable Motor Latch

A dependable start-stop function separates different concepts instead of combining everything into one bit.

Start requests

• Physical START button
• HMI start request
• Automatic sequence request
• Manual request

Stop requests

• Physical STOP button
• HMI stop request
• Process stop
• Fault stop
• Mode-change stop

Permissives

• Safety healthy
• Communication valid
• Drive ready
• Process conditions acceptable
• Required positions confirmed

Stored request

The latch stores an accepted request, not the physical running confirmation.

Final command

The output is assigned in one location.

Feedback

The program separately confirms that the contactor, drive or motor actually responded.

Useful tags include:

Motor_Start_Request
Motor_Run_Latched
Motor_Permissive
Motor_Output_Command
Motor_Feedback
Motor_Running_Confirmed

This structure may use more tags, but it makes the machine behaviour much easier to diagnose.

Diagnosing an Intermittent Latch Fault

Watching the rung online is rarely enough.

Record:

• Raw START input
• Raw STOP input
• Processed push-button states
• Every permissive
• Communication-valid bits
• Set condition
• Reset condition
• Latch state
• Final output command
• Physical feedback
• Operating mode
• Current sequence step
• CPU scan time

Use a PLC trace or event buffer to capture the signals around the failure.

Also record the reason the latch changed state. Instead of only storing Motor_Run = FALSE, store diagnostic causes such as:

• Stop button
• Overload trip
• Communication loss
• Drive not ready
• Mode change
• Process interlock
• Power-up initialization

The final state tells you what exists now. The change reason explains what happened.

Tests Every Seal-In Circuit Should Pass

A seal-in circuit should be tested under abnormal conditions, not only with a normal START and STOP sequence.

Test:

• START and STOP simultaneously
• Repeated rapid START commands
• START with a missing permissive
• Permissive loss while running
• Fault and reset together
• Communication failure
• Remote I/O reconnection
• Power loss while latched
• PLC restart with retained data
• Automatic-to-manual transfer
• Manual-to-automatic transfer
• Online edit while stopped
• Bypass activation and removal
• Missing output feedback

For each test, verify:

• Stored latch state
• Final output state
• Restart requirement
• Alarm behaviour
• HMI indication
• Recovery path

The outcome should remain predictable regardless of small timing differences.

Final Thoughts

Seal-in logic is simple only when every signal is local, stable and controlled from one place.

Modern PLC systems introduce HMI commands, network communication, remote I/O, retained memory, mode selection and fault recovery. These additional states can make a familiar holding circuit behave unpredictably.

When a latch becomes unstable, investigate more than the rung itself.

Check for:

• Duplicate writes
• Retentive memory
• Stale permissives
• Asynchronous start conditions
• Unclear reset priorities
• Communication delays
• Mode conflicts
• Hidden bypasses

The strongest seal-in circuit is not the one with the fewest contacts.

It is the one whose set, hold, stop, fault and restart behaviour remain clear under every expected operating condition.