PLC Analog Filtering and False Process Stability

Analog filtering is frequently used to smooth noisy process measurements.

A fluctuating pressure, temperature, flow or level signal becomes easier to read. HMI trends look cleaner. PID controllers stop reacting to every small change, and nuisance alarms may occur less often.

Filtering is useful—but only up to a point.

Every filter delays the signal reaching the PLC logic. When the filter becomes too strong, the displayed process value can remain calm while the real process has already changed significantly.

The trend appears stable.

The process may not be.

What Analog Filtering Actually Does

A filter reduces rapid changes in a measurement by spreading their effect over time.

Instead of allowing the PLC value to follow every raw input change immediately, the filter moves gradually toward the new value.

A simplified sequence is:

Physical process changes
        ↓
Raw analog signal changes
        ↓
Filter slows the response
        ↓
PLC receives a delayed value
        ↓
Alarm, interlock or PID reacts later

Filtering does not normally eliminate the underlying disturbance. It changes how much of that disturbance is visible and how quickly the control system responds to it.

This distinction matters.

If the raw signal is noisy because of damaged shielding, poor grounding or VFD interference, a software filter may hide the symptoms without correcting the installation.

Filtering Creates Dead Time

In control systems, dead time is the delay between a real process change and the controller seeing enough of that change to respond.

A filter contributes to this delay.

Consider a low-pressure shutdown:

1. Actual pressure falls from 5 bar to 2 bar.
2. The transmitter reacts immediately.
3. The raw PLC input begins falling.
4. A strong filter holds the processed value near 5 bar.
5. The low-pressure interlock remains healthy.
6. The machine continues operating.
7. The filtered value eventually drops below the trip threshold.
8. The shutdown occurs late.

The comparison instruction may be completely correct:

Low_Pressure_Trip := Pressure_Filtered < 3.0;

The problem is that Pressure_Filtered no longer represents the current physical pressure.

It represents a delayed version of it.

A Simple Filter Example

A common first-order software filter can be represented conceptually as:

Filtered_Value :=
    Filtered_Value
    + Alpha × (Raw_Value - Filtered_Value);

Where:

• Raw_Value is the latest measurement.
• Filtered_Value is the smoothed result.
• Alpha determines how quickly the result follows the input.

A larger Alpha follows the raw signal more quickly.

A smaller Alpha produces smoother but slower movement.

The same idea may also be configured through:

• Time constants
• Moving averages
• Analog-module integration time
• Transmitter damping
• PID input filtering

Different implementations behave differently, but the trade-off remains similar:

More smoothing usually means more delay.

The Hidden Stack of Filters

A signal may pass through several filtering stages without anyone realizing the total delay.

For example:

1. Transmitter damping: 2 seconds
2. Analog input module filter: 500 milliseconds
3. PLC moving average: 3 seconds
4. PID process-value filter: 1 second
5. HMI trend averaging: 2 seconds

The final display may look excellent, but the control system is responding to a measurement that is several seconds behind the real process.

Commissioning engineers should identify every filtering stage in the signal path:

Sensor response
↓
Transmitter damping
↓
Analog-module filtering
↓
PLC software filter
↓
PID filtering
↓
HMI smoothing

The total response must be tested, not guessed.

False Stability

False stability occurs when filtering makes an unstable signal look calm.

Suppose the real pressure repeatedly oscillates between 4 and 6 bar. A heavily filtered display may remain near 5 bar.

The HMI trend suggests that the process is stable.

Meanwhile:

• The pump may be surging.
• A valve may be hunting.
• Pressure switches may be changing state.
• Mechanical equipment may be experiencing repeated load changes.
• Product quality may be affected.

The filtered value is not technically false—it is an average of the changing signal.

However, it hides the behaviour that maintenance and process engineers need to see.

Slow HMI Trends Can Hide Fast Events

HMI trends create another layer of apparent stability.

An HMI may sample a PLC tag every 500 milliseconds or once per second. It may also apply:

• Deadband
• Compression
• Averaging
• Rounding
• Historical data reduction

A spike lasting 100 milliseconds may stop equipment without ever appearing on the trend.

The operator sees:

Pressure stable at 4.8 bar

The PLC may have seen:

4.8 → 2.6 → 4.8 bar

during the time between HMI updates.

For intermittent faults, use a PLC trace or high-speed data logger rather than relying only on the operator trend.

Delayed Shutdown Response

Overfiltering becomes dangerous when filtered measurements control protective actions.

Examples include:

• Low lubrication pressure
• High temperature
• Loss of cooling flow
• Excessive tank level
• Low suction pressure
• High motor load
• Loss of ventilation

A smooth value is less important than timely detection.

Where appropriate, use separate measurement paths:

Pressure_Raw
Pressure_Protection
Pressure_Control
Pressure_Display

Possible roles include:

• Pressure_Raw for diagnostics
• Pressure_Protection with minimal suitable filtering
• Pressure_Control with filtering appropriate for PID stability
• Pressure_Display with additional smoothing for readability

Critical safety functions must use the required safety-rated architecture and validated measurement method. Ordinary PLC filtering is not a substitute for safety-system design.

Delayed Interlock Clearing

Filtering can delay recovery as well as shutdown.

Suppose a low-pressure fault clears physically after the pump restores pressure. The raw signal returns to normal quickly, but the filtered value rises slowly.

The PLC continues showing:

Pressure_Permissive = FALSE

The operator sees healthy pressure on a local gauge but cannot reset the machine.

This creates complaints such as:

• “The pressure is fine, but the PLC still says it is low.”
• “The machine always takes several seconds before it can restart.”
• “Reset only works on the second attempt.”

The logic may not be malfunctioning. It may be waiting for a delayed filtered value.

The recovery delay should be deliberate and documented rather than an accidental consequence of signal smoothing.

Startup Instability

Filtered permissives can also create intermittent startup problems.

Consider a machine that requires pressure above 3 bar.

The physical pressure reaches 3.5 bar, but the filtered value is still 2.9 bar when the operator presses START.

The request is rejected.

A moment later, the filtered value reaches 3.1 bar, but the start command has already disappeared.

The operator presses START again and the machine runs normally.

This often creates the impression that the HMI button or PLC logic is unreliable.

A better design may:

• Display that startup validation is still in progress.
• Enable START only when permissives are fully validated.
• Capture a short start request for a controlled period.
• Require the filtered condition to remain stable before declaring readiness.
• Use a separate startup filter appropriate to the process.

The solution should not allow an old start request to remain active indefinitely.

PID Overshoot and Oscillation

PID control depends on timely feedback.

When heavy filtering delays the process value, the controller continues increasing its output because it cannot yet see the effect of its previous action.

For example:

1. Temperature is below setpoint.
2. PID increases heater output.
3. The real temperature begins rising.
4. The filtered temperature remains low.
5. PID increases output further.
6. The delayed measurement finally rises.
7. The process overshoots the setpoint.

This can produce:

• Overshoot
• Slow recovery
• Repeated oscillation
• Valve hunting
• Unstable pump speed
• Long settling time

Retuning the PID may reduce the symptoms, but it does not remove the delay.

Before changing PID gains, examine:

• Transmitter damping
• Input-module filter
• PLC filter
• PID process-value filter
• Actual process response
• Control-output response

A controller cannot react effectively to information it receives too late.

Moving Average Filters

A moving average calculates the mean of several recent samples.

For example:

Filtered_Value :=
    Average of the last 20 samples

This can remove random fluctuations effectively, but it introduces delay because old values remain part of the result.

The delay depends on:

• Number of samples
• PLC task period
• Whether the samples are equally spaced
• How quickly the real process changes

A 20-sample average in a 100-millisecond task covers approximately two seconds of history.

The displayed result therefore contains measurements that may already be two seconds old.

Moving averages are useful for slowly changing processes but may be unsuitable for fast interlocks.

Filter Time Constants

Many first-order filters are configured using a time constant.

A larger time constant produces a slower response.

The filtered value does not usually reach the new input immediately. It approaches it gradually.

This means that a filter described as “two seconds” does not necessarily settle completely after exactly two seconds. Its full response may take several time constants.

Commissioning should therefore measure:

• Time to begin responding
• Time to reach the alarm threshold
• Time to reach most of the final value
• Time to settle

The threshold-crossing time is particularly important for alarms and interlocks.

Filter Reset and Initialization Problems

Software filters require an initial value.

Poor initialization can create false startup behaviour.

For example, after a PLC restart:

Filtered_Pressure = 0 bar
Raw_Pressure = 5 bar

If the filter slowly moves from zero toward the real value, the PLC may generate a false low-pressure fault.

A better startup approach may initialize the filter from the first valid raw measurement:

IF First_Valid_Sample THEN
    Pressure_Filtered := Pressure_Raw;
    Filter_Initialized := TRUE;
END_IF;

However, the raw sample must be confirmed valid before it is accepted. Initializing from stale or invalid data creates a different problem.

Filter design should define:

• Power-up value
• First valid sample
• Communication-loss behaviour
• Invalid-signal behaviour
• Manual reset behaviour
• Retentive or non-retentive state

Freezing the Filter During Bad Data

When communication fails or the analog module reports an invalid signal, some programs allow the filter to continue using the last valid input.

This may create a believable flat value.

A stronger design separates the value from its quality:

Pressure_Filtered
Pressure_Valid
Pressure_Last_Update
Pressure_Communication_Healthy

When the input becomes invalid:

• The last value may be retained for diagnostics.
• The measurement quality should become false.
• Control logic should follow a defined fallback strategy.
• The HMI should indicate stale or invalid data.

A frozen value must not continue appearing as a healthy live measurement.

Filtering Noise Versus Hiding Faults

Filtering may be appropriate for small unavoidable disturbances.

It should not be used to hide:

• Loose terminals
• Ground loops
• Damaged shielding
• Incorrect cable routing
• Unstable transmitter power
• Faulty sensors
• VFD interference
• Process oscillation

A useful commissioning question is:

Is the filter removing harmless measurement noise, or hiding information about a real fault?

If the raw value changes every time a nearby contactor operates, increasing the filter constant is not a proper repair.

Fix the electrical cause first.

Hysteresis Is Not the Same as Filtering

Filtering and hysteresis solve different problems.

Filtering smooths the measured value over time.

Hysteresis uses separate activation and reset thresholds.

For example:

Pressure_Healthy becomes TRUE above 3.2 bar.
Pressure_Healthy becomes FALSE below 2.8 bar.

This prevents a permissive from switching repeatedly around one limit.

Hysteresis often provides more predictable Boolean behaviour than heavily filtering an analog value solely to stabilize a threshold.

The two techniques may be used together, but their purposes should remain clear.

Debounce and Validation Timers

A validation timer can require a condition to remain continuously healthy before it is accepted.

For example:

Pressure > 3.0 bar continuously for 500 ms
→ Pressure_Ready = TRUE

This is useful when a stable startup condition is required.

However, timers also add delay.

The engineer should decide independently:

• How much analog filtering is needed?
• How much hysteresis is needed?
• How long must the condition remain valid?
• How quickly must a fault be detected?

Using a large filter, wide hysteresis and long validation timer together can create a very sluggish control response.

A Better Signal Architecture

A robust analog structure may include:

Pressure_Raw_Count
Pressure_Scaled
Pressure_Fast
Pressure_Control
Pressure_Display
Pressure_Valid
Pressure_Underflow
Pressure_Overflow
Pressure_Noise_Alarm

Each value has a defined purpose.

Raw count

Used for module and electrical diagnostics.

Scaled value

Converted into engineering units without unnecessary smoothing.

Fast value

Used for time-sensitive process detection where appropriate.

Control value

Filtered according to PID and process requirements.

Display value

Smoothed for operator readability.

Validity and diagnostics

Used to reject broken, stale or out-of-range data.

This is clearer than using one heavily filtered tag everywhere.

How to Test Filter Delay

A practical test should compare the real input with every processed version.

Use a loop calibrator or controlled process change:

1. Stabilize the input at a known value.
2. Apply a realistic step change.
3. Record the raw count.
4. Record the scaled value.
5. Record each filtered value.
6. Record alarm and interlock states.
7. Measure the response time.
8. Repeat in both directions.

Test:

• Rising signal
• Falling signal
• Small disturbance
• Large step
• Threshold crossing
• Power recovery
• Communication recovery
• Invalid-signal transition

The falling response may be more important for a low-pressure trip, while the rising response may matter more for startup permission.

Recommended Troubleshooting Workflow

When a process value looks stable but equipment responds late:

1. Verify the actual physical process.
2. Observe the raw analog input.
3. Compare raw, scaled and filtered tags.
4. Review transmitter damping.
5. Check analog-module integration settings.
6. Identify every software filter.
7. Review HMI smoothing and sampling.
8. Measure the total response delay.
9. Confirm which value controls each alarm and interlock.
10. Inspect grounding, shielding and cable routing.
11. Reduce filtering only after understanding the noise source.
12. Retest alarms, shutdowns, startup and PID behaviour.

Do not tune the filter based only on how attractive the trend looks.

Questions to Ask During Commissioning

For every filtered measurement, engineers should be able to answer:

• Why is this signal filtered?
• What noise is being removed?
• What is the filter time constant?
• How much total delay exists?
• Is transmitter damping also enabled?
• Which value controls the PID?
• Which value controls shutdowns?
• Which value appears on the HMI?
• What happens after power recovery?
• What happens when the signal becomes invalid?
• Can the raw value still be viewed and traced?

If nobody can answer these questions, the filtering strategy is not fully controlled.

Final Thoughts

Analog filtering can improve control quality and operator visibility, but it always introduces a trade-off.

More smoothing creates a cleaner signal.

It also creates a slower signal.

Excessive filtering can delay shutdowns, prevent timely resets, destabilize startup sequences and increase PID overshoot. It may also make an unstable process appear healthy.

The objective is not to produce the smoothest possible trend.

It is to preserve enough process visibility for the PLC to react correctly.

Verify the raw signal first. Correct grounding, shielding, wiring and transmitter problems. Then apply only the amount of filtering the process genuinely requires.

Filtering should reduce unwanted electrical instability.

It should never remove the control system’s ability to see what the process is actually doing.