Deterministic Start/Stop Design in PLC Programming

A start-stop circuit is one of the first control structures most PLC programmers learn.

Press START, the equipment runs. Press STOP, the equipment stops. Add a holding condition, several permissives and a fault reset, and the circuit appears complete.

In a real industrial system, however, reliable start-stop logic must handle much more than two push buttons.

It must behave predictably during:

• Power restoration
• Communication recovery
• Delayed remote inputs
• Unstable permissives
• Operating-mode changes
• Equipment faults
• Operator mistakes
• Abnormal field conditions

The goal is not merely to make the output turn on and off.

The goal is to ensure that every command, interruption and recovery produces a defined result.

This is the foundation of deterministic start-stop design.

What Makes Start-Stop Logic Deterministic?

A deterministic circuit behaves consistently when the same relevant conditions occur.

The programmer should be able to answer:

• What happens if START and STOP are active together?
• What happens if a permissive disappears while running?
• What happens after a power failure?
• What happens if the HMI reconnects with a start bit active?
• What happens if communication returns before the data is valid?
• What happens when RESET is pressed while the fault still exists?
• What happens if manual and automatic requests overlap?

The answers should not depend on accidental network order, duplicate coils or an old retained latch.

A strong program defines these outcomes explicitly.

Separate the Different Control States

One of the most important design improvements is separating states that are often combined into one tag.

A tag called Motor_Run may be used incorrectly to represent:

• Operator request
• Automatic sequence request
• PLC output command
• Contactor feedback
• Motor-running confirmation

These are different conditions.

A clearer structure uses separate tags:

Motor_Start_Request
Motor_Stop_Request
Motor_Start_Permissive
Motor_Run_Request_Latched
Motor_Output_Command
Motor_Contactor_Feedback
Motor_Running_Confirmed

This makes troubleshooting much easier.

The PLC can show that a start was requested but rejected because the drive was not ready. It can also detect when the output was commanded but the contactor did not respond.

Use One Authoritative Output Owner

The final physical output should be assigned in one clearly defined location.

Manual control, automatic sequences and maintenance functions may all create requests, but they should not write directly to the same output.

For example:

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

The final command can then be calculated once:

Motor_Output_Command :=
    Safety_Healthy
    AND Run_Permissive
    AND NOT Fault_Active
    AND NOT Stop_Required
    AND Selected_Run_Request;

Finally:

Q0.0 := Motor_Output_Command;

This structure prevents later ladder rungs from silently overwriting an earlier command.

The output has one owner, and every condition affecting it is visible.

Define Stop Priority Clearly

START and STOP can overlap.

This may happen because:

• Both physical buttons are pressed
• An automatic request appears during shutdown
• The HMI sends a start while a remote stop is updating
• Communication retains an old command
• Different tasks process the signals asynchronously

In most applications, STOP should override START.

That priority should be built into the logic:

IF Stop_Required OR Fault_Active THEN
    Run_Request_Latched := FALSE;

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

The result remains predictable even if the two commands become true during the same scan.

Do not rely on the physical position of set and reset instructions to determine priority accidentally.

Capture Momentary Start Requests Safely

A short HMI start pulse may disappear before all remote permissives become valid.

For example:

Scan 1:
Start_Request = TRUE
Drive_Ready = FALSE

Scan 2:
Start_Request = FALSE
Drive_Ready = TRUE

The operator pressed START while the HMI displayed the drive as ready, but the two conditions did not overlap inside the PLC task.

A temporary request latch can solve this:

IF Rising_Edge(Start_Button) THEN
    Start_Request_Pending := TRUE;
END_IF;

IF Start_Accepted
   OR Stop_Required
   OR Start_Request_Timeout THEN
    Start_Request_Pending := FALSE;
END_IF;

The request should have a timeout.

It must not remain stored indefinitely and start the equipment several minutes later when a missing permissive unexpectedly returns.

Validate Startup Conditions

Startup permissives often arrive from different sources:

• Local inputs
• Remote I/O
• Safety controllers
• VFD telegrams
• Other PLCs
• Analog instruments
• HMI commands

These conditions do not become healthy simultaneously.

A deterministic startup should use explicit phases, such as:

1. Initialization
2. Communication validation
3. Data validation
4. Device readiness
5. Physical-position verification
6. Permissive stabilization
7. Ready for reset
8. Ready to start

This prevents the machine from evaluating every device immediately after the CPU enters RUN.

A device that is still initializing should not automatically be treated as faulty.

Require Stable Permissives

An important permissive should not always be accepted because it was true during one scan.

Communication bits may flicker during reconnection. Pressure switches may chatter. Analog values may briefly pass through acceptable limits.

A startup validation structure might be:

All_Start_Permissives :=
    Safety_Healthy
    AND Remote_IO_Healthy
    AND Drive_Ready
    AND Pressure_Healthy
    AND Valve_Position_Valid
    AND Process_Data_Valid;

Then require:

All_Start_Permissives continuously true
for the validation period
→ Startup_Validated

The validation time should reflect actual equipment behaviour.

It should not be used to hide defective sensors, unstable power supplies or unreliable communication.

Separate Startup and Running Permissives

The conditions required to start equipment are not always identical to those required to keep it running.

For example, startup may require:

• Drive ready
• Valve fully open
• Downstream equipment available
• Pressure stable
• Communication initialized

Once the motor is running, a brief loss of a non-critical ready signal may require a controlled stop rather than immediate output removal.

Useful categories include:

Start_Permissive
Run_Permissive
Trip_Condition
Restart_Permissive

This is clearer than using one generic System_OK bit for every operating phase.

Critical safety conditions still require the appropriate safety-rated system and must not be delayed by ordinary standard PLC logic.

Reject Stale Data

A Boolean value can remain true after its source stops communicating.

For example:

Remote_Ready = TRUE

If communication fails and the previous value is retained, the PLC may continue treating the remote device as ready.

A valid remote permissive should include quality:

Remote_Start_Permissive :=
    Remote_Communication_Healthy
    AND Remote_Data_Valid
    AND Remote_Ready;

Useful checks include:

• Heartbeat counters
• Update counters
• Timestamps
• Signal-age monitoring
• Device status words
• Communication watchdogs
• Plausibility validation

A value is not healthy merely because it contains a believable state.

Define Power-Recovery Behaviour

Power restoration is one of the most important tests for start-stop logic.

A dangerous sequence may occur when:

1. Power fails while the motor is running.
2. The physical output de-energizes.
3. The internal run latch remains retained.
4. The PLC restarts.
5. Remote I/O reconnects.
6. The drive becomes ready.
7. The old run request becomes effective again.
8. The motor starts without a new command.

A deterministic program should define which values are retained and which are cleared.

Production counters and setpoints may need retention. Movement commands usually require more caution.

A common approach is:

On PLC startup:
    Clear run requests
    Clear temporary maintenance commands
    Disable automatic outputs
    Enter initialization state

Automatic restart should occur only when it has been deliberately designed, risk assessed and clearly authorized by the process requirements.

Reset Must Not Act as Start

RESET and START should be separate functions.

RESET may:

• Acknowledge an alarm
• Clear a fault latch
• Confirm recovery conditions
• Return the machine to a ready state

It should not automatically:

• Energize outputs
• Resume automatic movement
• Restore a retained command
• Continue from an uncertain sequence step

The operator may press RESET merely to clear an alarm message. Unexpected movement must not follow unless the control philosophy explicitly requires and safely permits it.

A cleaner sequence is:

Fault cleared
↓
Recovery conditions validated
↓
Reset accepted
↓
Machine enters READY
↓
Fresh START command required

Active Faults Must Override Reset

A fault should remain latched while its original cause is still present.

Avoid unclear set-reset competition:

Fault_Condition → SET Fault_Latched
Reset_Request   → RESET Fault_Latched

If both are true during one scan, the result may depend on execution order.

Use explicit priority:

IF Fault_Condition THEN
    Fault_Latched := TRUE;

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

The fault wins until the process has genuinely recovered.

This prevents one-scan fault clearing from briefly allowing equipment to start.

Define Recovery States

After a fault, the machine may not be ready to resume from the interrupted point.

It may need to:

• Stop all automatic movement
• Cancel old run requests
• Re-establish communication
• Confirm field positions
• Move actuators to safe positions
• Reject an incomplete product
• Restore process pressure
• Require operator inspection

Useful recovery states may include:

• Faulted
• Waiting for fault removal
• Communication recovery
• Position validation
• Manual recovery
• Ready for reset
• Ready for start

Each state should define which outputs are allowed and which transitions are valid.

Recovery should guide the machine toward a known condition rather than simply clearing alarm bits.

Keep Bypasses Controlled

A maintenance bypass should never become part of normal start-stop behaviour.

If a bypass is necessary, it should be:

• Clearly displayed
• Access controlled
• Logged
• Limited to maintenance mode
• Time restricted where appropriate
• Reset after power loss
• Prevented from hiding the raw fault
• Considered during restart validation

For example:

Valve_Feedback_Healthy :=
    Valve_Open_Feedback;

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

The bypass may permit limited operation, but the real feedback must remain visible as unhealthy.

Avoid Hidden Latches

A latch should have:

• One clear owner
• One documented purpose
• Explicit set conditions
• Explicit reset conditions
• Defined priority
• Known retentive behaviour
• Known power-up state

Hidden latches become dangerous when they are set in one block and reset in another.

Cross-reference tools should be used to identify every write to:

• Run commands
• Fault memories
• Operating modes
• Sequence states
• Bypass bits
• Physical outputs

The fewer locations that write to a state, the easier it is to predict.

Monitor Output Feedback

A command does not prove that the field device responded.

A deterministic motor-control function should compare:

Motor_Output_Command
Motor_Contactor_Feedback
Drive_Running_Status
Motor_Speed_Confirmed

Possible faults include:

• Command active but no feedback
• Feedback active without command
• Feedback arriving too late
• Feedback remaining active after stop
• Communication invalid
• Mechanical device not responding

Use clearly defined response timers.

For example:

Motor contactor must provide feedback within 500 milliseconds of the command.

If feedback does not arrive, record a specific fault rather than producing a generic startup error.

Record Why the Output Changed

A useful control function should preserve the reason why an output was blocked or stopped.

Possible diagnostic reasons include:

• Stop button active
• Safety circuit unhealthy
• Overload trip
• Drive not ready
• Communication invalid
• Pressure unavailable
• Valve not confirmed
• Fault active
• Startup validation incomplete
• Maintenance bypass active
• Output feedback timeout

A single Motor_Not_Ready indication is not enough.

A first-out recorder can capture the earliest failed condition before secondary alarms appear.

Test the Abnormal Conditions

A deterministic start-stop circuit is not fully tested by pressing START and STOP once.

Commissioning should include:

• START and STOP together
• START before permissives become ready
• Short HMI start pulse
• Delayed remote I/O
• Communication loss during startup
• Permissive loss while running
• Fault and reset together
• Power loss while running
• PLC restart with retained data
• HMI reconnection with command active
• Automatic-to-manual transition
• Manual-to-automatic transition
• Bypass activation and removal
• Missing output feedback
• Repeated rapid commands

The machine should reach a predictable state in every case.

A Practical Control Structure

A reliable motor function may follow this sequence:

1. Build start requests

Physical_Start_Request
HMI_Start_Request
Automatic_Run_Request
Manual_Run_Request

2. Build stop requests

Physical_Stop_Request
HMI_Stop_Request
Process_Stop_Request
Fault_Stop_Request
Mode_Change_Stop

3. Validate permissives

Communication_Valid
Drive_Ready
Pressure_Healthy
Valve_Position_Valid
Process_Ready

4. Validate startup stability

Start_Permissives_Stable

5. Store the accepted request

Run_Request_Latched

6. Calculate the command once

Motor_Output_Command :=
    Safety_Healthy
    AND Run_Request_Latched
    AND Run_Permissive
    AND NOT Fault_Active
    AND NOT Stop_Required;

7. Verify physical response

Motor_Feedback_Healthy

8. Record the reason for failure

Motor_Blocking_Reason
Motor_First_Out_Fault

This architecture is longer than a traditional seal-in rung, but its behaviour is far clearer.

Final Thoughts

Deterministic start-stop design is not about writing complicated logic.

It is about removing ambiguity.

A strong PLC program clearly defines:

• Who owns the output
• What START actually requests
• What STOP overrides
• Which permissives are required
• How long they must remain stable
• What is cleared after power loss
• What RESET is allowed to do
• How the system recovers
• When a fresh start command is required

Simple logic becomes dangerous when machine behaviour is undefined.

The strongest PLC systems are rarely the ones with the most instructions.

They are the ones that behave predictably when the plant does not.