Why Stable PLC Logic Still Fails: The Danger of Good-Looking Trends

A smooth HMI trend can be reassuring.

Pressure appears steady. Temperature moves gradually. Tank level remains inside its normal range, and no obvious signal faults are visible.

Everything looks healthy.

Yet the machine may still behave incorrectly because a stable trend does not prove that the underlying process data is accurate, current or physically possible.

The PLC program may be executing exactly as designed. The problem is that it is making decisions from bad information.

This creates one of the most dangerous commissioning conditions:

false confidence.

A PLC Only Knows the Data It Receives

The controller does not directly observe pressure, temperature, flow or level.

It receives a numerical representation of the process through a chain of devices and calculations:

Physical process
↓
Sensor or transmitter
↓
Electrical or network signal
↓
Analog input module
↓
Scaling
↓
Filtering
↓
PLC logic
↓
HMI display

Every stage can introduce errors.

The HMI displays the final processed value, not the physical process itself. A clean number on the screen may have already passed through transmitter damping, module filtering, PLC averaging and slow HMI sampling.

By the time the operator sees it, important process behaviour may have disappeared.

How False Stability Is Created

A common sequence looks like this:

Noisy or unstable signal
↓
Heavy filtering applied
↓
Trend becomes smooth
↓
Underlying problem remains
↓
Operators assume the process is stable

The visual symptom disappears, but the original fault is still present.

The noise may have come from:

• Poor shielding
• Grounding problems
• VFD interference
• Loose terminals
• Unstable transmitter power
• A failing sensor
• Real process oscillation

Filtering cannot determine which of these causes is present. It merely slows and averages the measurement.

A Smooth Trend Can Be Delayed

Suppose a pressure signal is heavily filtered.

The real pressure falls from 5 bar to 2 bar in less than one second. The raw analog value follows the change immediately, but the filtered value falls slowly:

Actual pressure:       5.0 → 2.0 bar
Filtered PLC value:    5.0 → 4.7 → 4.2 → 3.6 → 3.0 → 2.5

If the low-pressure interlock activates below 3 bar, the machine continues running until the delayed value finally crosses the threshold.

The logic is technically correct:

Low_Pressure_Trip := Pressure_Filtered < 3.0;

The shutdown is late because the logic is using old process information.

A Stable Value May Be Frozen

Networked measurements can remain at their last valid value after communication fails.

For example:

Remote_Tank_Level = 62.4%

The remote device disconnects, but the PLC tag remains at 62.4%.

The HMI trend becomes perfectly flat.

That flat line may look like excellent process stability. In reality, no fresh measurement is arriving.

A robust signal should include:

Tank_Level_Value
Tank_Level_Communication_Healthy
Tank_Level_Data_Valid
Tank_Level_Last_Update
Tank_Level_Signal_Age

The value should be trusted only when its quality is healthy:

Tank_Level_Valid :=
    Communication_Healthy
    AND Data_Quality_Good
    AND Signal_Age < Maximum_Age;

A believable number is not necessarily a live number.

Saturation Creates False Flatlines

A transmitter may reach the end of its configured range while the physical process continues changing.

Consider a level transmitter configured as:

• 4 mA = 0%
• 20 mA = 100%

If the real level moves above the calibrated range, the PLC may continue displaying approximately 100%.

The trend is stable because the instrument cannot report a higher value.

Possible signs of saturation include:

• Value remains exactly at the upper or lower limit
• Control output continues changing without process response
• Related measurements disagree
• Transmitter reports overrange
• Analog module reports overflow
• Physical observations contradict the HMI

A flat trend at a limit should be investigated rather than automatically accepted as normal.

Incorrect Scaling Can Look Believable

Scaling errors do not always produce obviously impossible numbers.

Suppose a pressure transmitter is configured for 0–16 bar, but the PLC scales it as 0–10 bar.

At 12 mA, the real pressure is 8 bar, while the PLC displays 5 bar.

The trend still rises and falls smoothly. Operators may see a reasonable value and trust it.

However:

• High-pressure alarms activate too late
• PID control uses the wrong feedback
• Permissives change at incorrect physical points
• Historical data becomes misleading
• Process limits may be exceeded

A believable trend can remain wrong across its entire range.

Physically Impossible Data

A process value may remain inside its configured numerical limits while violating basic process behaviour.

Examples include:

• Flow reported while the pump is stopped
• Pressure remaining constant after a pipe is vented
• Tank level changing by 40% in one second
• Temperature jumping instantly by 80°C
• Valve position reporting open and closed simultaneously
• Pressure increasing while every pump and valve is isolated
• Two nearby temperature sensors differing by an extreme amount

The PLC will not recognize these contradictions unless plausibility checks are programmed.

For example:

Flow_Implausible :=
    Pump_Stopped
    AND Flow_PV > Minimum_Expected_Flow;

Or:

Level_Rate_Fault :=
    ABS(Level_PV - Previous_Level_PV)
    > Maximum_Possible_Change_Per_Scan;

Plausibility logic does not replace instrumentation maintenance, but it helps detect believable values that do not match physical reality.

Slow HMI Sampling Hides Fast Events

A PLC may execute every few milliseconds, while the HMI refreshes once every half-second or slower.

A signal spike lasting 30 milliseconds can:

• Trigger an alarm
• Drop a permissive
• Stop a motor
• Reset a sequence
• Cause a PID output change

The HMI may never display it.

The operator sees a stable line before and after the shutdown and concludes that the output dropped without a reason.

For intermittent events, record at PLC task speed:

• Raw input
• Scaled value
• Filtered value
• Signal-valid bit
• Alarm state
• Permissive state
• Output command
• Sequence step

A PLC trace reveals behaviour that ordinary HMI trends cannot capture.

Good-Looking Trends Can Hide Real Oscillation

Suppose a raw pressure signal oscillates repeatedly between 4 and 6 bar.

A strong moving average may display approximately 5 bar.

The HMI appears calm, but the real process may be experiencing:

• Pump surging
• Valve hunting
• Unstable flow
• Mechanical vibration
• Repeated load changes
• Product-quality variation

The filtered average is mathematically valid, yet it removes the very information needed to diagnose the process.

This is why important signals should often retain several versions:

Pressure_Raw
Pressure_Scaled
Pressure_Control
Pressure_Display
Pressure_Valid

The display value can be smooth while the diagnostic raw value remains available.

Filtering Does Not Repair Electrical Noise

When a raw signal fluctuates, adding more filtering is tempting.

The trend becomes attractive, and commissioning can continue.

However, the original problem may still be:

• A damaged shield
• Signal cable routed beside a VFD output cable
• Poor equipotential bonding
• Corroded junction-box terminals
• Unstable 24 V supply
• Incorrect transmitter grounding
• Defective analog module
• Real process instability

A software filter can hide all of these.

Before adjusting the filter, verify:

1. The real process with an independent instrument
2. The transmitter output
3. Raw PLC counts
4. Cable shielding and routing
5. Grounding and bonding
6. Terminal condition
7. Module configuration
8. Signal behaviour during motor and VFD operation

Filtering should be the final refinement, not the first repair.

False Stability Can Corrupt PID Control

A PID controller relies on current feedback.

When the process value is heavily delayed, the controller keeps reacting to conditions that existed several seconds earlier.

A typical sequence is:

1. Process value is below setpoint.
2. PID increases output.
3. Real process begins responding.
4. Filtered feedback remains low.
5. PID increases output further.
6. Delayed feedback finally rises.
7. Process overshoots.
8. Controller reverses direction.

The result may be blamed on poor tuning.

The real problem may be accumulated signal delay from:

• Transmitter damping
• Module integration
• PLC filtering
• PID input filtering
• Network update time

PID tuning cannot eliminate measurement dead time. The complete signal path must be reviewed first.

False Stability Affects Startup Permissives

Filtered analog values are also used to create startup conditions.

For example:

Pressure_Ready :=
    Pressure_Filtered > 3.0;

The physical pressure may already be 3.5 bar, but the filtered value still reads 2.8 bar.

The operator presses START, and the request is rejected.

A few seconds later, the filtered value crosses the threshold. The next start attempt works normally.

This produces intermittent startup behaviour even though the process and logic appear healthy.

Startup design should clearly define:

• Which signal version is used
• How long the value must remain valid
• Whether communication quality is healthy
• Whether a short start request is captured
• How delayed recovery is displayed to the operator

Raw Values Must Remain Accessible

A common design mistake is exposing only the final filtered engineering value.

Maintenance personnel should also be able to inspect:

• Raw module count
• Unfiltered engineering value
• Filtered control value
• Display value
• Underflow and overflow
• Wire-break status
• Communication validity
• Last update time
• Rate of change

Without these layers, technicians cannot determine whether the problem originates in the transmitter, wiring, module, scaling, filtering or HMI.

Do Not Confuse Stability With Accuracy

A signal has several separate qualities:

Accuracy

Does the value match the real process?

Stability

Does the value fluctuate?

Freshness

Is the value being updated?

Validity

Is the transmitter, module and communication path healthy?

Response time

Does the value follow the process quickly enough?

A measurement can be stable but inaccurate.

It can be accurate but stale.

It can be valid but too heavily delayed for an interlock.

A professional control system evaluates more than whether the number looks smooth.

A Better Commissioning Method

When a trend appears stable but machine behaviour does not make sense:

Verify the physical process

Compare the PLC value with a calibrated independent instrument.

Observe the raw signal

Check the raw analog count or direct network value before scaling and filtering.

Compare all signal stages

Record:

Raw
Scaled
Filtered
Displayed

Check signal quality

Verify module diagnostics, communication state, update counter and signal age.

Test dynamic response

Apply a controlled process or calibrator change and measure how quickly each signal stage responds.

Check plausibility

Compare the measurement with related process conditions and equipment states.

Review control dependencies

Determine which value is used by:

• Alarms
• Interlocks
• PID loops
• Permissives
• HMI trends
• Historical records

Only after this evidence is collected should logic or filtering be changed.

Questions Every Engineer Should Ask

For an important analog signal, the commissioning team should know:

• What is the actual transmitter range?
• What raw counts represent the nominal range?
• Is the signal electrically stable?
• How much filtering exists?
• Is the displayed value live?
• What happens during communication failure?
• Can saturation be detected?
• Does the signal match independent measurements?
• Is the value physically plausible?
• Which version controls shutdowns?
• Which version controls the PID?
• Can the raw value be traced?

When these questions cannot be answered, a smooth trend should not create confidence.

It should create suspicion.

Final Thoughts

Stable PLC logic can still fail because the controller’s decisions are only as trustworthy as the data behind them.

A smooth trend may be:

• Delayed by filtering
• Frozen after communication loss
• Clamped at a limit
• Scaled incorrectly
• Averaging real oscillation
• Physically impossible

The code may not be incorrect.

The data quality may be poor.

Commissioning should therefore verify the complete signal chain before changing logic, PID tuning or alarm thresholds.

A clean HMI trend is useful, but it is not proof.

The most dangerous process value is often the one that looks perfectly normal while quietly hiding the truth.