How to Implement a First-Order Lag Filter in Ladder Logic

A first-order lag filter in ladder logic is a digital low-pass filter that smooths noisy analog inputs by combining the current raw value with the previous filtered value using a weighting constant, alpha. In practice, it can reduce noise-driven PID instability while introducing a tunable response delay that should be validated before deployment.

Raw analog signals are not automatically good enough just because the transmitter is calibrated. In live plants, 4–20 mA and 0–10 V signals routinely pick up noise from EMI, grounding issues, turbulent process conditions, and mechanical vibration. If that noise is fed directly into control logic, the PLC reacts to disturbance rather than process truth. Actuators then hunt, chatter, and wear out.

During OLLA Lab validation testing, injecting a 2 mA peak-to-peak high-frequency noise wave into a simulated 4–20 mA pressure signal produced a 15% variance in PID actuator output. Applying a first-order lag filter with alpha = 0.15 reduced actuator variance to 1.2% in the same scenario. Methodology: n=12 repeated simulation runs on one pressure-loop task, baseline comparator = unfiltered signal path, time window = 10-minute equivalent simulated runtime per run. This supports the claim that software filtering can materially stabilize a noisy loop in a bounded simulation case. It does not support a universal tuning rule for all processes, instruments, or scan times.

A first-order lag filter is a software-based low-pass filter that reduces short-term fluctuation in a signal by blending the current input with the previous filtered result over successive PLC scan cycles. In control practice, it is often implemented as an exponential moving average (EMA).

The standard discrete form is:

Y_n = (alpha × X_n) + ((1 - alpha) × Y_n-1)

Where:

• X_n = raw input
• alpha = filter constant
• Y_n-1 = previous filtered value
• Y_n = new filtered value

Interpretation:

• alpha = 1.0 means no filtering
• lower alpha means heavier smoothing and more lag

The key distinction is simple: this is not averaging a fixed window of samples; it is recursively weighting history. That makes it computationally light and easy to implement in ladder logic.

Why is it called a lag filter?

It is called a lag filter because the output intentionally responds more slowly than the raw input. That delay is not necessarily a defect. It is the trade-off for rejecting high-frequency noise.

The engineering objective is not to make the trend look cleaner. The objective is to remove non-useful variation without delaying the process signal so much that control quality degrades.

Software filtering is necessary because hardware cleanliness and transmitter accuracy do not eliminate dynamic noise at the control level. A signal can be electrically valid and still be operationally unhelpful.

Common sources of signal degradation include:

• Electromagnetic interference (EMI) from VFDs, motor leads, relays, and poorly segregated power and instrumentation wiring
• Ground loops and shielding faults
• Mechanical vibration affecting pressure, flow, and level devices
• Process turbulence such as splashing, cavitation, and pulsation
• A/D conversion granularity and scan interaction

Why does unfiltered noise damage control performance?

Unfiltered noise degrades control performance because the controller treats every change as potentially meaningful unless told otherwise. That is especially problematic in loops using derivative action.

Three common failure patterns are:

• Output hunting
• Derivative amplification
• Mechanical wear from unnecessary actuator movement

This is why software filtering often belongs in the conversation when analog quality is suspect, though not everywhere and not blindly.

You write a first-order lag filter in ladder logic by calculating the weighted contribution of the raw input and the previous filtered value, summing them, and then storing the result for the next scan. The implementation can use separate math blocks or a single compute instruction, depending on the PLC platform.

Step-by-step logic structure

1. Calculate the raw-input weight by multiplying the raw input by alpha.
2. Calculate the historical weight by subtracting alpha from 1.0 and multiplying that result by the previous filtered value.
3. Sum both weighted terms to produce the new filtered value.
4. Update the historical tag so it is available on the next scan.

Ladder implementation example

[Language: Ladder Diagram]

// Rung 1: Execute first-order lag math CPT Dest: Tag_Filtered_Current Expression: (Tag_Raw_Input Tag_Alpha) + (Tag_Filtered_Previous (1.0 - Tag_Alpha))

// Rung 2: Update historical tag for next scan MOV Source: Tag_Filtered_Current Dest: Tag_Filtered_Previous

What tags do you need?

At minimum, define:

• `Tag_Raw_Input` — scaled analog input
• `Tag_Alpha` — filter constant as REAL
• `Tag_Filtered_Current` — current filtered result
• `Tag_Filtered_Previous` — retained prior-scan filtered result

What execution detail matters most?

Execution order matters because this is a recursive calculation. If you overwrite the historical value too early, the filter stops behaving as intended.

You should initialize a first-order lag filter so that the historical value starts from a known condition, usually the current raw input at startup or on first scan. This prevents a large artificial transient when the filter begins executing.

Common initialization strategies include:

- First-scan seeding: set `Tag_Filtered_Previous = Tag_Raw_Input` on first program scan - Mode-change seeding: re-seed when switching from manual to automatic if stale history would distort response - Fault-recovery seeding: reinitialize after a bad input condition or sensor substitution event

The right choice depends on process criticality and control philosophy.

You choose alpha by balancing noise attenuation against response delay. Lower alpha values smooth more aggressively but increase lag. Higher alpha values preserve responsiveness but reject less noise.

A practical interpretation is:

- High alpha, for example 0.6 to 0.9: light filtering, fast response, limited noise suppression - Moderate alpha, for example 0.2 to 0.5: balanced smoothing and responsiveness - Low alpha, for example 0.05 to 0.15: strong smoothing, slower response, greater phase-lag risk

These ranges are heuristic, not universal settings. The correct value depends on:

• process time constant
• PLC scan time
• sensor behavior
• control objective
• whether the filtered signal feeds indication, alarming, or closed-loop control

What is the main tuning trade-off?

The main trade-off is smoothness versus phase lag.

If alpha is too high:

• the signal remains noisy
• the PID still reacts to disturbance
• actuator wear may remain elevated

If alpha is too low:

• the loop sees the process too late
• disturbance rejection worsens
• the controller may become sluggish or unstable for a different reason

Replacing noise with delay is not necessarily an improvement.

Scan time affects filter behavior because the equation executes once per scan, and the effective smoothing depends on how often the recursive update occurs. The same alpha value does not produce the same dynamic effect if task execution timing changes materially.

This matters in three ways:

• Faster execution changes the effective time response
• Slower execution increases the apparent delay between meaningful corrections
• Jittered execution can distort expected filter performance, especially in tightly tuned loops

For serious validation, alpha should not be selected in isolation from scan characteristics. A filter tuned in one execution context may behave differently in another.

You test filter response in OLLA Lab by injecting controlled analog noise into a simulated signal, applying the ladder-logic filter, and comparing raw versus filtered behavior in the Variables Panel before any live deployment.

In bounded product terms, OLLA Lab serves as a validation and rehearsal environment for high-risk commissioning tasks. It does not confer site competence, certification, or functional safety qualification. What it does provide is a controlled place to observe, diagnose, and refine control logic against realistic process behavior before it reaches a live process.

Validation workflow in OLLA Lab

• Inject noise into the analog signal using a high-frequency disturbance over a steady baseline
• Build the filter in the ladder editor
• Trend both values in the Variables Panel
• Adjust alpha deliberately
• Observe downstream control behavior
• Revise and retest

What should you look for during validation?

Look for evidence, not aesthetics:

• Does the filtered signal suppress high-frequency oscillation?
• Does the PID output become materially more stable?
• Does the filter delay real process changes too much?
• Do alarms clear up, or do they now arrive late?
• Does the revised behavior remain acceptable across multiple disturbances?

A stable trend line is not enough. The loop must still represent the process at a useful speed.

You should save a compact body of engineering evidence, not just screenshots. The point is to document reasoning, fault response, and revision quality in a way another engineer can audit.

Use this structure:

1. System description: process element, signal type, scaling range, scan context, and where the filtered value is used 2. Operational definition of correct behavior: reduced noise, bounded actuator variance, no unacceptable control lag, and no nuisance alarm chatter 3. Ladder logic and simulated equipment state: implemented logic, tag roles, initial conditions, and simulated process state 4. Injected fault case: disturbance type, amplitude, frequency, turbulence pattern, or sensor jitter profile 5. Revision made: selected alpha, initialization changes, and any downstream PID or alarm adjustments 6. Lessons learned: what improved, what degraded, and what remains uncertain

No single standard tells you exactly what alpha to use for every loop, but several bodies of literature and guidance support the underlying engineering concerns: signal quality, software behavior, safety boundaries, and validation discipline.

Relevant references include:

• IEC 61508 for the broader discipline of functional safety and software lifecycle rigor in electrical, electronic, and programmable systems
• exida guidance for practical interpretation of safety lifecycle and control-system validation concerns
• IFAC and process control literature for filtering, loop performance, and noise-response trade-offs
• Instrumentation and sensor literature for noise behavior, measurement uncertainty, and dynamic signal conditioning

A necessary boundary: using a filter in a training or validation environment does not itself establish safety integrity, compliance, or suitability for a safety instrumented function. Filtering can improve control quality, but it does not replace engineering review.

You should avoid or limit first-order lag filtering when response speed is more important than noise reduction, or when filtering could mask a real and safety-relevant process change.

Use caution in cases such as:

• fast protective trips
• critical permissive logic
• rapidly changing batch transitions
• combustion or pressure-control applications with tight dynamic requirements
• any signal path where delay could worsen hazard exposure

The right question is not can I smooth this signal. The right question is what decision becomes slower if I do.

A first-order lag filter is one of the most practical ways to clean a noisy analog signal in ladder logic, but its value depends on disciplined tuning and validation. The equation is simple. The consequences are not.

The engineering goal is to attenuate non-useful variation without blinding the controller to real process movement. That requires attention to alpha selection, initialization, scan timing, and downstream loop behavior. It also requires a place to test those interactions safely.

That is the bounded role of OLLA Lab: a web-based environment where engineers can build ladder logic, inject realistic disturbance, observe I/O behavior, compare simulated equipment state against ladder state, and revise logic before touching a live process.

- IEC 61131-3 — PLC programming languages - IEC 61508 Functional Safety overview - Åström & Murray, *Feedback Systems* - Seborg et al., *Process Dynamics and Control* (Wiley) - IFAC-PapersOnLine journal homepage