Unsafe Restart Behavior in PLC Systems

Restart logic is one of the most safety-critical parts of an industrial PLC program.

A machine that stops safely during a fault can still become dangerous if it restarts unexpectedly afterward. Motors may energize, cylinders may move and conveyors may begin running while operators believe the equipment is still stopped.

These incidents often occur because the PLC program remembers an old command, accepts incomplete permissives or resumes from a sequence state that no longer matches the physical machine.

The program may be executing exactly as written.

The problem is that the restart behaviour was never clearly defined.

A Typical Unsafe Restart Sequence

Consider a motor that was running when control power failed:

1. The PLC loses power.
2. The motor contactor releases.
3. The internal run latch remains stored in retentive memory.
4. Power returns and the PLC enters RUN.
5. The drive or remote I/O is still initializing.
6. The final permissive becomes healthy several seconds later.
7. The stored run request becomes effective.
8. The motor starts without a new operator command.

The machine did not restart immediately when power returned. It waited until the last permissive became true, making the event more difficult to predict.

From the PLC’s perspective, the run request never disappeared.

From the operator’s perspective, the motor started by itself.

Retained Latches

Retentive memory preserves selected values through a power interruption or CPU restart.

This is useful for:

• Production counters
• Recipes
• Setpoints
• Calibration values
• Maintenance information

It is potentially dangerous for:

• Motor run commands
• Valve movement commands
• Automatic cycle requests
• Sequence-enable bits
• Temporary bypasses

A retained run request may remain inactive while safety, communication or process permissives are unavailable. As those conditions recover, the old command can become active again.

Movement commands should normally return to a defined safe state after startup unless automatic recovery has been specifically assessed, designed and permitted.

Physical Conditions May Change During Power Loss

Even when the PLC remembers its sequence state correctly, the machine itself may not remain in the same condition.

During an interruption:

• Pneumatic pressure may decay.
• Cylinders may move under load.
• Spring-return valves may change position.
• Drives lose torque.
• Contactors release.
• Products may be removed manually.
• Tank levels and temperatures may continue changing.

A retained sequence step may therefore describe a machine state that no longer exists.

Before continuing, the PLC should compare stored state information with actual field feedback.

When the two do not match, the machine should enter a controlled recovery state rather than resuming automatically.

Stale Permissives

Startup conditions may appear healthy even when their data is no longer valid.

For example, a remote device may last report:

Remote_System_Ready = TRUE

Communication then fails. If the PLC retains the last value, the ready bit may remain true until the remote station reconnects or a watchdog expires.

A valid permissive should include communication quality:

Remote_Start_Permissive :=
    Remote_Communication_Healthy
    AND Remote_Data_Valid
    AND Remote_System_Ready;

The same principle applies to analog values. A pressure reading cannot be trusted merely because it still contains a plausible number.

Important startup data should include:

• Communication status
• Data-valid indication
• Device diagnostic state
• Update counter
• Timestamp or signal age
• Plausibility checks

A stale healthy signal is more dangerous than an obvious fault because it can silently permit operation.

Missing Permissive Reset

Some programs only block the physical output when a fault occurs:

Motor_Output :=
    Run_Request_Latched
    AND Motor_Permissive
    AND NOT Fault_Active;

If the fault becomes active, the output turns off—but the stored run request remains true.

As soon as the fault and permissives recover, the motor can restart automatically.

The program must decide what should happen to the request when operation is interrupted.

Possible behaviours include:

• Cancel the run request.
• Require a fresh START command.
• Hold the request until an operator confirms recovery.
• Permit controlled automatic restart after a validated process interruption.
• Move the system into a dedicated recovery sequence.

The correct choice depends on the machine risk assessment and process requirements. It should never be an accidental consequence of leaving the latch active.

Reset Must Not Mean Start

A RESET command should normally acknowledge or clear a fault after its cause has disappeared.

It should not automatically:

• Energize outputs
• Restore a retained run command
• Start an automatic sequence
• Resume movement
• Clear every stopping condition
• Return immediately to the interrupted step

Combining reset and start behaviour creates a dangerous operator expectation problem.

The operator may press RESET to remove an alarm and unintentionally initiate movement.

Use separate functions for:

• Fault acknowledgement
• Fault reset
• Recovery authorization
• Machine start

After reset, the system should normally return to a known ready or recovery state. A deliberate start command can then begin operation.

Active Faults Must Override Reset

A reset should not be accepted while the original fault is still present.

Unstable logic may repeatedly set and clear the fault when the operator holds RESET:

Fault_Condition → SET Fault_Latched
Reset_Request   → RESET Fault_Latched

If the two instructions are evaluated in an unfortunate order, the fault may disappear for one scan. Other logic may interpret that brief state as permission to restart.

Use explicit priority:

IF Fault_Condition THEN
    Fault_Latched := TRUE;

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

The active fault wins. Reset becomes possible only after all required recovery conditions are stable.

Asynchronous Startup Conditions

Devices do not become ready simultaneously after power restoration.

A typical sequence may be:

1. PLC enters RUN.
2. Safety controller becomes healthy.
3. Remote I/O reconnects.
4. VFD establishes communication.
5. Drive-ready status appears.
6. Pneumatic pressure reaches its minimum.
7. Analog measurements become valid.
8. Operator interface reconnects.

If the program evaluates startup conditions too early, it may enter a fault or unstable sequence state.

A deterministic startup should distinguish between:

• Initializing
• Communicating
• Data valid
• Ready
• Faulted
• Recovery required

A device that has not completed initialization is not necessarily defective.

Validate Permissives Before Restart

Restart should not occur because all required conditions were true for a single scan.

Communication bits can flicker during reconnection. Mechanical contacts can bounce. Analog values may briefly pass through acceptable ranges while stabilizing.

A restart permissive can require all relevant conditions to remain continuously healthy for a defined period:

Restart_Ready :=
    Safety_Healthy
    AND Communication_Healthy
    AND Devices_Ready
    AND Positions_Valid
    AND Process_Conditions_Valid;

Then:

Restart_Ready continuously true
for required validation time
→ Reset permitted

The validation period should be based on real device and process behaviour. It should not be used to hide unstable wiring or unreliable communication.

Define an Explicit Startup State

A strong PLC program begins in a known state after startup.

For example:

State 0: Initialization

• Clear non-retentive movement requests.
• Disable automatic outputs.
• Initialize diagnostic structures.
• Prevent sequence transitions.

State 10: Communication validation

• Confirm remote I/O.
• Confirm drives and intelligent devices.
• Verify that process data is updating.

State 20: Physical-state validation

• Check actuator positions.
• Compare retained sequence data with field feedback.
• Identify any inconsistent state.

State 30: Recovery required

• Allow only controlled manual recovery actions.
• Keep automatic mode blocked.
• Display clear recovery instructions.

State 40: Ready for reset

• All required conditions are stable.
• Operator reset may be accepted.

State 50: Ready to start

• The system is healthy.
• A separate START command is required.

This approach makes restart behaviour understandable and testable.

Controlled Recovery States

After a fault, the safest action may not be to continue from the interrupted sequence step.

The system may need to:

• Stop all automatic movement.
• Cancel stored output requests.
• Move actuators to home positions.
• Empty or reject the current product.
• Re-establish communication.
• Confirm process values.
• Require manual inspection.
• Restart from a known sequence state.

Recovery states should define which outputs are allowed to operate and under what conditions.

Manual recovery controls should not silently reactivate automatic sequencing.

Preventing Unexpected Automatic Restart

A typical restart-permission structure could include:

Restart_Permitted :=
    Startup_Complete
    AND Safety_Healthy
    AND No_Active_Fault
    AND Communication_Validated
    AND Field_Positions_Validated
    AND Process_Data_Valid
    AND Operator_Reset_Accepted;

The final run command may then require a fresh request:

Machine_Run :=
    Restart_Permitted
    AND New_Start_Request;

The important detail is New_Start_Request.

A command that existed before the interruption should not automatically be treated as a new operator decision unless the application has been specifically designed for automatic restart.

HMI Commands After Reconnection

HMI buttons and command tags also require attention during recovery.

Depending on their configuration, an HMI may reconnect with:

• A command tag still true
• A delayed button-release message
• Retained internal script values
• Old screen data
• A pending automatic command

Momentary HMI controls should be handled as requests rather than direct output commands.

The PLC may require a rising edge after startup or clear all external command buffers during initialization.

For example:

HMI_Start_Request_Valid :=
    HMI_Communication_Healthy
    AND Startup_Complete
    AND Rising_Edge(HMI_Start_Button);

This prevents an old true state from being interpreted as a fresh start command.

Bypasses During Recovery

A maintenance bypass that survives a restart can remove critical permissives exactly when the system is most unstable.

Bypasses should have defined power-up behaviour.

Depending on the application, they may need to:

• Reset automatically after power loss
• Require reauthorization
• Be blocked during startup
• Generate a prominent alarm
• Prevent automatic mode
• Expire after a time limit
• Be recorded in an event log

A bypass must not silently turn an unknown startup condition into a healthy one.

First-Out Fault and Restart History

When several interlocks recover at different times, the original cause can disappear.

Record:

• First condition that stopped the machine
• Time of the event
• Sequence step
• Active movement command
• Operating mode
• Relevant analog values
• Communication state
• Reason reset was blocked
• Reason restart was accepted

A restart-history buffer can show:

09:14:32.105 — Drive communication lost
09:14:32.112 — Motor command removed
09:14:36.400 — Drive communication restored
09:14:37.020 — Drive data confirmed valid
09:14:39.020 — Restart permissives validated
09:14:44.810 — Operator reset accepted
09:14:48.245 — New start command received

This provides far more useful evidence than a single current-state indication.

Restart Tests That Should Be Performed

Restart logic should be tested deliberately under abnormal conditions.

Test:

• Power failure while equipment is running
• PLC restart with a stored run request
• Remote I/O reconnecting late
• Drive becoming ready after other permissives
• HMI reconnecting with a command active
• Fault clearing while RESET is held
• Safety reset before process data becomes valid
• Power returning with actuators out of position
• Communication recovering with stale values
• Bypass active during power loss
• Repeated rapid power interruptions
• Operator reset without a fresh START command

For every test, confirm:

• Whether outputs remain safely controlled
• Whether old commands are cancelled
• Whether data is valid
• Whether automatic mode remains blocked
• Whether operator action is required
• Whether the recovery state is clear
• Whether the final restart is deliberate

Safety Functions Require Safety-Rated Design

Standard PLC restart logic must not be used as a substitute for required safety functions.

Prevention of unexpected startup may involve:

• Safety relays
• Fail-safe PLCs
• Safe drive functions
• Guard interlocks
• Contactor feedback
• Energy isolation
• Lockout/tagout procedures

The correct architecture depends on the machine risk assessment and applicable safety requirements.

Ordinary PLC logic can coordinate restart behaviour, but it must operate within the properly designed safety system.

Final Thoughts

Unsafe restart behaviour usually comes from undefined stored states rather than complicated programming syntax.

A retained latch survives. A permissive returns late. Communication data appears healthy before it is valid. A reset clears the alarm while an old run request remains active.

The machine then starts because every condition eventually becomes true—even though nobody issued a new command.

Professional restart logic must define:

• What is cleared at startup
• What may remain retained
• How permissives are validated
• How field positions are checked
• What reset actually does
• Which recovery states are permitted
• When a fresh start request is required

A restart should never happen merely because the PLC has recovered.

It should happen only because the system has confirmed that recovery is complete and a deliberate restart is safe.