The Psychology of PLC Commissioning Failure

Many commissioning failures begin with a technical problem.

The dangerous part starts when the technical problem changes how people behave.

An unexpected fault appears. Production stops. Operators begin asking when the line will run again. Management wants an explanation, while maintenance teams are already checking sensors, drives and electrical panels.

Pressure rises quickly.

Someone forces a permissive. Another engineer extends a timer. A third person attempts a manual sequence recovery. The machine still does not start, so more changes are added.

Within a short time, the original control system no longer exists.

The team is now troubleshooting a machine containing:

• The original fault
• Several active forces
• Temporary bypasses
• Modified timers
• Online program edits
• Manually altered sequence states
• Unknown operator actions

At that point, troubleshooting quality usually collapses.

The objective should never be to make the machine run somehow.

The objective is to restore predictable behaviour safely.

How Production Pressure Changes Troubleshooting

Under normal conditions, an engineer may follow a disciplined process:

1. Confirm the symptom.
2. Record the machine state.
3. Identify the first failed condition.
4. Form a hypothesis.
5. Test one variable.
6. Compare the result with the prediction.

Under production pressure, the process often becomes:

Machine stops
↓
Urgency increases
↓
First theory appears
↓
Several changes are made
↓
Machine still does not run
↓
More changes are added

The team becomes focused on action rather than evidence.

Doing something feels more productive than pausing to understand the system. Unfortunately, activity and progress are not the same thing.

The Original Fault Becomes Hidden

Consider a machine that fails because a drive-ready signal arrives late after communication recovery.

The first engineer forces Drive_Ready true.

The sequence advances but stops because valve feedback is missing. Another engineer bypasses the valve feedback.

The motor then fails to start before its timer expires, so someone increases the startup timeout from 5 seconds to 20 seconds.

Eventually, the machine runs.

What actually repaired it?

Possibilities include:

• Communication finished recovering naturally.
• The forced drive-ready signal allowed an unsafe transition.
• The valve bypass concealed a real field problem.
• The extended timer allowed a slow device to respond.
• One of the earlier conditions was never faulty at all.

Because several changes were made together, the evidence has been destroyed.

The machine may now depend on one or more temporary modifications that nobody fully understands.

Action Bias

Under pressure, people often feel that immediate action is better than observation.

This is known as action bias.

In commissioning, action bias may appear as:

• Pressing RESET repeatedly
• Power cycling equipment
• Forcing tags before checking raw inputs
• Changing timers without measuring response time
• Editing logic before reading diagnostics
• Replacing devices without confirming failure
• Restarting the sequence without preserving fault data

These actions sometimes appear successful, which reinforces the behaviour.

For example, power cycling a drive may restore communication. The engineer concludes that power cycling is the solution, even though the underlying network fault remains unresolved.

The next failure is then treated the same way.

Confirmation Bias

Once an engineer forms a theory, it becomes easy to interpret every observation as supporting it.

Suppose the initial theory is:

The startup timer is too short.

The engineer notices that the sequence times out and increases the timer. When the machine later starts, the theory appears confirmed.

However, the real cause may have been a delayed network update that happened to recover during the longer timeout.

Evidence that contradicts the timer theory may be ignored:

• The device normally responds in two seconds.
• The timeout occurred only after network interruption.
• The raw ready signal was stale.
• Another identical machine uses the original timer successfully.

A strong troubleshooting process attempts to disprove a theory, not merely confirm it.

Ask:

What observation would show that this theory is wrong?

Anchoring on the First Explanation

The first plausible explanation often dominates the entire recovery.

An operator may say:

It started after the last PLC update, so the program must be wrong.

The team then investigates ladder logic for hours, even though the actual fault is a loose sensor terminal disturbed during the same maintenance period.

This is anchoring.

Common commissioning anchors include:

• “It must be the PLC.”
• “The drive always causes this.”
• “That sensor has been unreliable before.”
• “The timer is too short.”
• “The network is overloaded.”
• “The operator pressed the wrong button.”

Previous experience is useful, but it should guide investigation rather than replace evidence.

Tunnel Vision

Pressure narrows attention.

An engineer may focus intensely on one ladder network while ignoring:

• The physical field device
• Safety-system status
• Communication validity
• Analog signal quality
• Another routine writing the same output
• Recent mechanical work
• Active forces
• Retained sequence states

The highlighted contact on the screen becomes the entire problem.

A useful way to prevent tunnel vision is to trace the complete control path:

Operator or sequence request
↓
Startup permissives
↓
Machine state
↓
Final command
↓
Physical output
↓
Field response
↓
Feedback confirmation

This forces the investigation to include both program behaviour and physical equipment.

Escalation of Commitment

Once several changes have been made, engineers may resist undoing them.

They have invested time and effort in the current approach. Rolling back can feel like losing progress.

This leads to escalation of commitment:

1. A bypass is added.
2. It does not solve the problem completely.
3. Another bypass is added.
4. A timer is changed.
5. Sequence logic is edited.
6. Returning to the original program now feels risky.

The team keeps moving forward because too much work has already been invested.

A predefined rollback rule prevents this.

For example:

When a controlled change does not produce the predicted result, restore the baseline before testing another theory.

Rollback is not failure. It protects the integrity of the troubleshooting process.

Group Pressure and Authority

Plant recovery usually involves people with different responsibilities:

• Operators
• Maintenance technicians
• PLC engineers
• Production supervisors
• Process engineers
• Managers
• Equipment suppliers

A senior person may demand a quick bypass. A junior engineer may recognize the risk but feel uncomfortable challenging the instruction.

Statements such as these create dangerous pressure:

• “Just force it for one cycle.”
• “We have done this before.”
• “Production cannot wait.”
• “The interlock is probably unnecessary.”
• “Get it running now and document it later.”

Professional recovery requires the authority to pause when the machine state is unclear.

Concerns should be stated specifically:

Forcing this feedback will allow the sequence to continue without confirming the valve position. We need to verify the valve physically before applying that test.

Specific technical language is more effective than a vague objection.

Fatigue Changes Decision Quality

Commissioning work often extends late into the night.

Fatigue reduces:

• Attention
• Memory
• Patience
• Risk awareness
• Ability to compare alternatives
• Accuracy during online edits

At 03:00 AM, a programmer may:

• Edit the wrong tag
• Forget a force
• Use the wrong timer value
• Download an outdated project
• Misread an input state
• Skip documentation
• Accept a weak explanation too quickly

Fatigue should be treated as a technical risk.

Useful controls include:

• A second person reviewing online changes
• Short recovery pauses
• Clear change records
• Shift handover notes
• Limits on simultaneous edits
• Confirmation before downloads
• Formal review of active forces and bypasses

A tired engineer may still be highly experienced. Experience does not remove the effects of fatigue.

Repeated Reset Attempts Destroy Evidence

Pressing RESET is often the first operator response.

Repeated resets can:

• Clear first-out fault records
• Restart timers
• Change sequence states
• Cause communication to reconnect
• Remove temporary diagnostic conditions
• Create new secondary faults

By the time an engineer arrives, the original condition may have disappeared.

A better system preserves:

• First fault
• Previous state
• Timestamp
• Start request
• Output command
• Important permissives
• Communication state
• Process values

Operators should also understand when to stop resetting and preserve the machine state for investigation.

Blind Startup Attempts Increase Instability

Repeatedly attempting to start an unhealthy machine can create additional problems.

Each attempt may:

• Move actuators into different positions
• Partially advance products
• Restart timers
• Change pressure or temperature
• Create new alarms
• Alter the sequence state
• Increase mechanical stress

After several attempts, the physical machine may no longer match the original fault condition.

One controlled startup test with full monitoring is more valuable than ten blind attempts.

Before testing again, define:

• Expected transition
• Required permissives
• Expected device response
• Stop criteria
• Data to capture

Excessive Forcing

Forcing can be useful when testing one clearly understood condition.

It becomes dangerous when it replaces diagnosis.

Multiple active forces create an artificial machine state that may never exist in normal operation.

For example:

Drive_Ready forced TRUE
Valve_Open forced TRUE
Pressure_Healthy forced TRUE
Downstream_Ready forced TRUE

The PLC now believes the machine is fully prepared, regardless of the physical process.

If the output energizes, the test proves only that the downstream logic executes when all conditions are artificially satisfied.

It does not prove which original condition was defective.

Every force should have:

• A documented purpose
• A defined expected result
• A responsible person
• A removal condition
• A physical risk assessment

Before returning to production, inspect the complete force table.

Timer Changes Without Evidence

Timers are easy to change and difficult to blame.

A timeout fault may be caused by:

• Slow mechanical movement
• Low air pressure
• Delayed remote I/O
• Stale communication
• Incorrect feedback
• A genuinely short timeout

Increasing the timer can make all these faults appear to disappear.

Before changing it, measure:

• Command activation time
• Actual mechanical response
• Feedback arrival time
• Network update delay
• Variation across repeated cycles

Then select a timer based on real response data and an appropriate margin.

A timer should represent a process requirement—not frustration with a fault.

Bypass Logic Left Active

Temporary bypasses are especially vulnerable to human factors.

The person who creates the bypass intends to remove it later. Production resumes, attention moves elsewhere, and the override remains active.

Weeks later:

• Operators depend on it.
• Maintenance does not know why it exists.
• The HMI shows the condition as healthy.
• New logic is built around it.
• The original fault remains unresolved.

Bypass management should include:

Bypass name
Affected condition
Activation time
Authorized person
Reason
Operating restriction
Expiration or removal requirement

An active bypass should remain visible and alarmed.

The Loss of a Known Baseline

Troubleshooting depends on comparison.

Engineers need to know:

• What the system did before
• What changed
• What result followed

Uncontrolled edits destroy that baseline.

A recovery team should establish a known reference:

• Current running PLC project
• Active parameter values
• Device firmware and configuration
• Force table
• Bypass list
• Current machine state
• Recent maintenance work

Every test should begin from that known condition where practical.

Without a baseline, nobody can distinguish the original problem from the effects of later changes.

Disciplined Troubleshooting Is Faster

Disciplined troubleshooting may appear slower because it begins with observation.

In reality, it prevents hours of circular testing.

A disciplined method is:

Observe

Record the exact symptom and current state.

Preserve

Capture faults, diagnostics and signal values before resetting.

Localize

Determine whether the failure is in the request, permission, command, output or feedback.

Hypothesize

State one explanation that predicts the observed behaviour.

Test

Change one controlled variable.

Compare

Did the result match the prediction?

Roll back

Restore unsuccessful changes.

Verify

Repeat the normal sequence and relevant abnormal tests.

This process maintains cause and effect.

Use a Written Hypothesis

Before applying a change, write one sentence:

We believe the motor does not start because the drive-ready telegram arrives after the start request expires.

Then define the test:

Capture the start request and drive-ready bit at PLC task speed without forcing either signal.

And define the expected evidence:

On failed attempts, the start request will return false one or more scans before drive ready becomes true.

This prevents the investigation from drifting into unrelated edits.

One Change at a Time

One controlled change is a fundamental recovery rule.

Weak approach:

Increase timeout
Force pressure permissive
Disable valve fault
Restart remote I/O

Strong approach:

Capture current behaviour
↓
Apply one change
↓
Repeat the same test
↓
Record the result
↓
Keep or reverse the change

When several changes are unavoidable, treat them as one defined change set with a complete rollback plan.

Define Stop Rules

Recovery teams should decide in advance when testing must stop.

Stop when:

• Unexpected movement occurs
• The machine state no longer matches the physical condition
• Safety status changes
• A new uncontrolled fault appears
• More than one unexplained output energizes
• Communication becomes invalid
• The test result contradicts the hypothesis
• The rollback path is no longer clear

Without stop rules, teams may continue adding changes because they feel close to a solution.

Separate Recovery From Root-Cause Repair

Emergency recovery and permanent repair are related but different tasks.

A temporary method may be necessary to:

• Move equipment to a safe position
• Finish a controlled process step
• Recover trapped product
• Restore limited production

That does not make the temporary method a permanent solution.

Clearly document:

• Temporary condition
• Remaining risk
• Operating restriction
• Required permanent repair
• Deadline
• Person responsible

Temporary workarounds should not disappear into normal production.

Shift Handover Is a High-Risk Moment

During shift change, knowledge can be lost.

The outgoing engineer may know:

• Which force is active
• Which timer was changed
• Which sensor remains unreliable
• Which startup attempt last succeeded
• Which backup is current

If this information is not transferred clearly, the incoming shift may repeat tests or misunderstand the machine state.

A technical handover should include:

Current machine state
Original fault
Changes made
Active forces
Active bypasses
Temporary parameters
Tests completed
Tests remaining
Rollback location
Known operating restrictions

Verbal explanation alone is not enough during a complex recovery.

Build Diagnostics That Reduce Panic

Good PLC architecture supports calm decision-making.

Useful features include:

• First-out fault recording
• Current and previous machine state
• Transition reason history
• Raw and processed permissive screens
• Output command versus feedback
• Active bypass register
• Communication-quality status
• Signal-age monitoring
• Timestamped event logs
• Clear recovery instructions

When the HMI states:

Startup blocked: Drive 2 data not valid after network recovery

the team is less likely to begin forcing unrelated conditions.

Poor diagnostics create uncertainty. Uncertainty creates pressure. Pressure creates uncontrolled changes.

A Practical Commissioning Recovery Discipline

When a serious fault appears:

Stabilize the situation

Stop repeated startup attempts and uncontrolled changes.

Establish safety

Confirm hazardous energy, machine position and required isolation procedures.

Assign control

Choose one person to coordinate technical actions.

Preserve evidence

Capture diagnostics, machine state, process values and active commands.

Record the baseline

Save the running program and list every force, bypass and recent edit.

Investigate systematically

Trace request, permission, command, physical output and feedback.

Test one hypothesis

Define the expected result before changing anything.

Roll back unsuccessful changes

Do not build additional theories on top of failed modifications.

Recover through the normal architecture

Return through validation, recovery and startup states rather than forcing the running state.

Verify before handover

Test start, stop, fault, reset and recovery behaviour.

Questions to Ask Before Every Change

Before forcing, bypassing or editing, ask:

• What evidence supports this change?
• What exact result do we expect?
• Which outputs could be affected?
• Can the change create unexpected motion?
• How will we know whether it worked?
• How will it be reversed?
• Who is recording it?
• Does the machine need to be in a different state first?
• Are we fixing the cause or hiding the symptom?

When these questions cannot be answered, the change is not ready to be applied.

Final Thoughts

Commissioning failure is not purely a programming problem.

It is also a decision-making problem.

As pressure increases, people become more likely to force signals, bypass interlocks, change several parameters and repeatedly attempt startup. Each uncontrolled action makes the system harder to understand.

Eventually, the original fault becomes only one part of the problem.

Disciplined troubleshooting protects the machine from this escalation.

The goal is not maximum speed at the beginning of the recovery.

The goal is maintaining enough control that every observation and change still means something.

A machine that runs only because several undocumented overrides happened to align has not been recovered.

It has become temporarily operational in an unknown state.

Professional commissioning recovery restores:

• Known logic
• Verified field conditions
• Defined machine states
• Controlled startup
• Predictable fault response
• Documented changes

Fast troubleshooting feels productive.

Disciplined troubleshooting produces evidence.

Under live plant pressure, evidence is what brings the system back safely.