How to Reduce Valve Stiction Using PWM and Dither Logic in a PLC

Valve stiction causes PID limit cycling because static friction delays movement until control effort builds and then releases abruptly. A low-amplitude, high-frequency dither signal, often generated with PWM or math blocks, keeps the actuator in micro-motion and can reduce breakaway effects. OLLA Lab allows that logic to be rehearsed and observed safely before plant deployment.

Valve stiction is not a tuning problem in disguise. It is a mechanical nonlinearity that often survives perfectly respectable PID settings and then makes the loop look guilty anyway.

In practical terms, stiction causes the controller output to build, the valve to refuse movement, and then the valve to jump when breakaway force is finally exceeded. That jump pushes the process past where it should have gone, and the loop begins the same pattern again. During digital twin validation in OLLA Lab’s process control environment, a 50 Hz triangle-wave dither at 2% output amplitude reduced overshoot by 18% in a high-stiction valve scenario and suppressed the recurring limit cycle observed in the undithered case. Methodology: n=12 repeated simulation runs of the same valve-positioning task, baseline comparator = identical PID loop without dither, time window = 7-day internal validation cycle. This is an internal Ampergon Vallis benchmark, not a universal plant-performance claim.

A useful definition matters here. Simulation-ready does not mean "able to draw ladder syntax." It means able to prove, observe, diagnose, and harden control logic against realistic process behavior before that logic reaches a live process. Syntax is cheap. Commissioning mistakes are not.

Valve stiction is the difference between the force required to start valve movement and the force required to keep it moving. In friction terms, static friction exceeds kinetic friction, so the valve resists initial motion and then moves too easily once breakaway occurs.

That mismatch drives a characteristic control pattern. The PID loop keeps integrating error because the final control element does not respond immediately. When the actuator finally breaks free, the stored-up control effort produces a larger movement than intended. The process overshoots, the controller reverses, and the same sequence repeats in the opposite direction. It is a mechanical deadband with poor timing.

The stiction cycle in a PID loop

- Stall: The controller output changes, but the valve stem or actuator does not move because static friction has not been overcome. - Integral buildup: The PID loop, especially the integral term, continues accumulating corrective effort. - Breakaway: The output finally exceeds the static friction threshold. - Overshoot: The valve jumps because kinetic friction is lower than the breakaway threshold. - Reversal: The controller corrects in the opposite direction. - Repeat: The loop enters a sustained or intermittent limit cycle.

This behavior is well documented in valve diagnostics literature and control practice, including ISA guidance on control valve performance and nonlinearity assessment. The important distinction is simple: poor tuning can oscillate a healthy valve, but stiction can make a well-tuned loop oscillate anyway.

How do you recognize stiction instead of ordinary poor tuning?

Stiction usually leaves a different fingerprint than aggressive tuning. The controller output often ramps or steps while the valve position remains flat, followed by a sudden movement once breakaway occurs.

Common indicators include:

• A sawtooth or staircase pattern in controller output
• Delayed valve response to small output changes
• Repeating overshoot around setpoint despite conservative tuning
• Improved behavior when output changes are large, but poor behavior near small corrections
• Asymmetry between opening and closing response

If the loop only behaves when you bully the valve into moving, the valve is telling you something.

Dither reduces the practical effect of stiction by keeping the actuator in continuous micro-motion. The principle is straightforward: a small, fast oscillation is superimposed on the main control variable so the valve mechanism does not settle into a static friction state.

The distinction that matters is macroscopic movement versus microscopic movement. A controller may want the valve to stay near 40% open while remaining ready to move smoothly to 41% or 39.5% as process conditions change. Without dither, the valve can stick at 40% until enough force accumulates. With dither, the stem or actuator remains in slight motion around that operating point, so the next commanded change occurs within the kinetic friction regime rather than having to overcome static breakaway from rest.

What does PWM have to do with dither?

PWM is one practical way to create a controlled oscillatory signal in PLC logic. In some architectures, engineers use a high-frequency pulse train with a defined duty cycle; in others, they generate a triangle, square, or sine-like waveform mathematically and add it directly to the analog output command.

The exact implementation depends on the actuator, I/P transducer, valve positioner, and output hardware. That qualification matters. Dither is the control objective; PWM is one possible implementation method.

What makes dither effective?

Effective dither has three properties:

- Low amplitude: It must be large enough to overcome stiction effects but small enough not to create visible process oscillation. - High frequency: It must be fast enough to create micro-motion rather than a slow hunting motion. - Correct placement: It must be added at the right point in the control path, typically to the final control signal after the main PID output is computed.

In practice, amplitudes are often kept small, commonly in the low single-digit percentage range of output span, and frequency is chosen with respect to actuator mechanics and output hardware response. There is no universal setting that fits every valve.

Dither logic is implemented by generating a fast waveform, scaling it to a safe amplitude, and superimposing it on the PID control variable before the final analog output is written. OLLA Lab’s ladder logic environment and math-capable workflow make that sequence observable without requiring live hardware abuse.

This is where OLLA Lab becomes operationally useful. The point is not that it teaches math blocks in the abstract. The point is that it lets an engineer rehearse a high-risk output-conditioning technique while watching I/O, variables, and simulated equipment behavior together.

### Step 1: Create a time base for the waveform

Use a fast, repeating timer or equivalent time accumulator as the basis for waveform generation. The timer period determines the frequency domain available for the dither signal.

In ladder terms, this often means:

• A self-resetting TON or cyclic timer
• A normalized accumulator value
• A repeatable scan-safe update pattern

The objective is not merely to make something oscillate. It is to make it oscillate predictably.

### Step 2: Compute the waveform

Use OLLA’s math blocks to generate a periodic function from the time base. A sine wave is common when smoothness matters; a triangle wave is often easier to reason about and tune.

Typical options include:

• `SIN` for a smooth periodic waveform
• `COMPUTE` logic for triangle or sawtooth generation
• Conditional math for square-wave style modulation where hardware permits it

A triangle wave is often a sensible teaching choice because its slope and amplitude are easier to inspect visually in simulation.

### Step 3: Scale the waveform amplitude

Use a multiply block to limit the dither amplitude to a narrow band around the PID output. A common starting range in simulation is roughly 1% to 3% of output span, but this should be validated against the specific actuator model and process sensitivity.

Amplitude scaling should be explicit, not implied. That means:

• Define a `Dither_Amplitude_Setpoint`
• Multiply the raw waveform by that value
• Clamp the final result if output limits can be exceeded

A dither signal that quietly drives the output beyond its legal range is not sophisticated. It is just badly hidden.

### Step 4: Superimpose the dither on the PID output

Use an add block to combine the base PID control variable with the scaled dither signal. The resulting value becomes the commanded analog output.

The control structure is conceptually simple:

• `PID_CV` = primary controller output
• `Dither_Scaled` = low-amplitude periodic signal
• `Final_Output` = `PID_CV + Dither_Scaled`

This preserves the main control objective while conditioning the final control element against static friction effects.

### Step 5: Observe both logic state and equipment response

Validation requires more than watching the rung go true. Use OLLA Lab’s variables panel and simulated equipment behavior together.

Observe:

• PID output trend
• Dither waveform magnitude
• Final analog output
• Valve position response
• Process variable stability
• Presence or absence of limit cycling

That combined view matters because a mathematically elegant signal can still be mechanically wrong.

Example logic artifact

Structured Text / Math Block Logic:

`Dither_Angle := (Timer_Fast.ACC / Timer_Fast.PRE) 360.0;` `Dither_Raw := SIN(Dither_Angle);` `Dither_Scaled := Dither_Raw Dither_Amplitude_Setpoint;` `Final_Valve_Output := PID_1.CV + Dither_Scaled;`

_Image alt text: Screenshot of OLLA Lab’s Variables Panel and 3D Digital Twin showing a PID control variable combined with a high-frequency dither signal, with trend behavior indicating reduced stiction-driven limit cycling._

Digital twin validation is critical because dither is one of those techniques that looks harmless on paper and can become expensive on hardware. The risk is not theoretical. Incorrect frequency, excessive amplitude, or poor output conditioning can accelerate packing wear, overstress solenoids, excite mechanical resonance, or create visible process oscillation instead of suppressing it.

That is why this topic is rarely taught properly on live equipment. Plants do not usually volunteer a production valve as a teaching aid for experimental output modulation.

What does digital twin validation mean here, operationally?

In this context, digital twin validation means testing ladder logic and output-conditioning behavior against a realistic machine or process model, then comparing commanded state, simulated equipment response, and observed fault behavior before deployment to a live process.

That definition is operational, not decorative. It includes:

• Running the control logic in simulation
• Injecting realistic process and actuator behavior
• Observing whether the valve response matches the control intent
• Verifying that abnormal parameter choices produce visible consequences
• Revising the logic before any field download occurs

This is the practical bridge between syntax and deployability.

What can go wrong if dither is implemented badly?

Several failure modes are common:

- Amplitude too high: The valve moves visibly around setpoint, creating process noise or wear. - Frequency too low: The dither becomes a secondary oscillation rather than micro-motion. - Frequency too high for hardware response: The actuator or output stage cannot follow the command meaningfully. - No output limiting: The combined PID plus dither signal saturates the analog output. - Wrong insertion point: The dither is added upstream in a way that corrupts the controller structure rather than conditioning the final command.

The field version of this lesson is simple: if you do not know where the energy is going, do not add more of it.

Engineers should document dither work as a compact body of evidence showing system behavior, fault injection, and revision logic. A screenshot gallery proves that software existed. It does not prove that reasoning occurred.

Use this structure:

State what success means in measurable terms: reduced overshoot, suppressed limit cycling, acceptable valve travel, stable process variable, no output saturation.

Record the change: amplitude reduction, waveform change, clamp addition, timer adjustment, or insertion-point correction.

That is the kind of evidence a serious reviewer can inspect. It also aligns with the broader purpose of simulation-based commissioning practice described in industrial training and digital validation literature: not merely running code, but proving behavior under normal and abnormal conditions.

1. System Description Define the loop, actuator type, process variable, control objective, and where dither is inserted in the signal path.
2. Operational definition of correct
3. Ladder logic and simulated equipment state Show the control logic, variable states, and the corresponding simulated valve or process response.
4. The injected fault case Deliberately test a bad amplitude, bad frequency, output clamp omission, or actuator lag condition.
5. The revision made
6. Lessons learned Summarize what the test demonstrated about friction behavior, controller interaction, and deployment limits.

No single standard says to use one exact dither value for every valve, because valves, actuators, and processes are not identical. The relevant standards and literature instead define the surrounding discipline: functional safety boundaries, control valve diagnostics, actuator behavior, and model-based validation.

The most relevant sources include:

• ISA control valve diagnostics guidance for understanding stiction, hysteresis, and installed valve behavior
• IEC 61508 for the broader discipline of functional safety and the limits of what simulation can and cannot claim in safety-related systems
• exida and related functional safety practice for validation discipline and separation between simulated proof and field qualification
• IFAC and process control literature on nonlinear final control element behavior and loop performance degradation
• Recent digital twin and simulation training literature for the value of model-based rehearsal in reducing commissioning uncertainty

A necessary boundary: OLLA Lab can support rehearsal, observation, and logic hardening. It does not certify a safety function, replace field acceptance testing, or qualify a loop for SIL claims by association. Simulation is a proving ground, not a regulatory shortcut.

OLLA Lab supports dither rehearsal by combining web-based ladder logic construction, simulation mode, variable visibility, math-capable logic building, and 3D digital twin observation in one environment. That makes it suitable for practicing the exact sequence engineers struggle to rehearse on live assets: generate output logic, monitor I/O, inject abnormal conditions, compare equipment response, and revise.

Within that bounded role, the platform is useful for:

• Building ladder logic with timers, comparators, math functions, and PID instructions
• Running the logic in simulation without physical hardware
• Monitoring variables, analog values, and output behavior
• Validating logic against realistic scenario behavior and digital twin models
• Practicing commissioning-style revisions after a fault or instability is observed

That is the right frame for the product. It is a validation and rehearsal environment for high-risk control tasks. It is not a substitute for plant experience, instrument calibration, maintenance inspection, or formal compliance work.

Valve stiction is a mechanical problem that often presents as a control problem. Dither works because it changes the friction regime seen by the actuator, keeping the final control element in micro-motion so the PID loop is not forced into repeated breakaway and overshoot.

The engineering challenge is not understanding that sentence. The engineering challenge is implementing the waveform safely, placing it correctly in the control path, and validating that it improves response without creating a new failure mode. That is exactly the kind of work that benefits from simulation before deployment. The plant will still have the last word, but it is better not to arrive there with first-draft logic.

- IEC 61508 Functional Safety overview - exida Functional Safety and Automation resources - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), PID tuning rules00062-8) - Tao et al. (2019), Digital Twin in Industry