How to Diagnose PID Valve Hunting vs. Mechanical Stiction in OLLA Lab

PID hunting and mechanical stiction are not the same fault. Gain-induced oscillation is a controller overcorrection problem, while stiction is a non-linear valve deadband problem that produces limit cycles. OLLA Lab allows engineers to observe, isolate, and rehearse this distinction safely by correlating trend signatures with simulated valve behavior.

Not every oscillating PID loop is badly tuned. A loop can hunt because the controller is too aggressive, but it can also hunt because the valve is physically sticking and releasing in jumps. Software cannot tune its way around a mechanical deadband indefinitely.

In baseline testing of the OLLA Lab Level Control preset, introducing a 1.5% stiction variable at the discharge valve changed a previously stable response at Kp = 0.8, Ki = 2.5 into a sustained limit cycle with 3.2% peak-to-peak error around setpoint [Methodology: n=12 repeated simulation runs on one level-control task, baseline comparator = same loop with stiction disabled, time window = 10-minute steady-state observation after disturbance rejection]. This internal Ampergon Vallis benchmark supports one narrow point: modest non-linear valve friction can destabilize an otherwise acceptable loop. It does not establish a universal stiction threshold for all processes, valves, or tuning constants.

That distinction matters in commissioning. Engineers can lose time trying to fix hardware with gain edits. The loop usually disagrees.

The difference is root cause. PID gain oscillation is a control-law problem caused by excessive proportional or integral action relative to process dynamics. Mechanical stiction is a final control element problem caused by static friction, hysteresis, or binding in the valve assembly.

PID math assumes that a change in controller output produces a reasonably continuous actuator response. Stiction breaks that assumption. The controller output moves; the valve does not; the integral term accumulates; then the valve slips and jumps. That repeating pattern creates a limit cycle.

Historical loop-performance audits in the process industries have repeatedly shown that a substantial share of poor loop behavior originates in final control elements rather than controller tuning alone. Exact percentages vary by plant, audit method, and maintenance condition, but figures in the range of 20% to 30% of loop problems involving valve or actuator issues are widely cited in practitioner literature and ISA-adjacent diagnostic work (Bialkowski, 1993; Ender, 1993; McMillan, 2015). That does not mean 30% of every plant’s variability is always valve-driven. It means blaming the PID first is often an expensive reflex.

Signature symptoms of gain oscillation

Gain-driven hunting usually presents with these characteristics:

• The PV trend is relatively smooth and sinusoidal.
• Oscillation amplitude often changes predictably when Kp or Ki is reduced.
• The loop response tends to improve quickly when the controller is placed in manual.
• The CV and PV remain dynamically connected without a hard response threshold.
• The waveform is often more symmetrical around the setpoint.

This is a math problem. The controller is overcorrecting a process it can still continuously influence.

Signature symptoms of mechanical stiction

Stiction-driven hunting usually presents with these characteristics:

• The PV trend appears sawtoothed, stepped, or square-edged, not smoothly sinusoidal.
• The CV ramps continuously, but the valve position or PV does not respond until a threshold is crossed.
• Adjusting gains may change the timing of the cycle more than its amplitude.
• The loop may continue to hunt even after repeated tuning changes.
• Direction reversal often shows hysteresis, with a different threshold in each direction.

This is a mechanics problem. The controller is not talking to a smooth actuator; it is arguing with friction.

You identify stiction by comparing the shape and timing of the controller output (CV) against the process variable (PV). The trend relationship matters more than the fact of oscillation itself.

In a stiction case, the integral term often causes the CV to ramp gradually as it tries to eliminate steady-state error. If the valve is stuck, the PV remains nearly unchanged during that ramp. Once the output exceeds the breakaway force, the valve moves abruptly and the PV jumps. The cycle then repeats in the opposite direction.

That creates a recognizable pattern:

- CV trend: often triangular or ramp-like - PV trend: often square-wave-like or stepped - Valve response: delayed, then abrupt - Phase relationship: PV movement occurs only after CV crosses a threshold

A smooth sine wave suggests tuning. A triangle-to-square relationship strongly suggests non-linearity in the final element.

Analyzing the PV vs. CV relationship

The most useful diagnostic question is simple: Does the PV respond continuously to small CV changes?

If the answer is yes, the loop is probably dealing with tuning, process lag, dead time, or disturbance rejection limits. If the answer is no, and the PV only moves after accumulated output changes, the loop likely contains a deadband or stiction problem.

In practical terms:

• If CV changes by 0.5%, 1.0%, 1.5% and the PV remains flat, the actuator may be stuck.
• If the PV then moves suddenly after a threshold, you are observing a slip-jump event.
• If the same behavior repeats when the output reverses direction, you likely have hysteresis as well as stiction.

This is where OLLA Lab becomes operationally useful. The platform allows engineers to compare the ladder state, variable state, oscilloscope traces, and simulated equipment behavior in one environment rather than guessing from a single trend line.

Suggested image alt-text: “Screenshot of OLLA Lab oscilloscope displaying a Controller Output triangle wave and Process Variable square wave, demonstrating mechanical valve stiction alongside a 3D digital twin of a sticking pneumatic valve.”

The standard field approach is a manual bump test. The objective is to remove closed-loop PID behavior from the diagnosis and test whether the valve responds proportionally to small output changes.

This should be done carefully on live systems because output bumps can move the process into unsafe or off-spec conditions. That is exactly why simulation has value here.

The micro-step method in OLLA Lab

1. Place the PID controller in Manual. This opens the loop and prevents integral action from masking the actuator behavior.
2. Apply a small output step in one direction. A 0.5% change is a reasonable starting point for a training scenario.
3. Observe the PV and valve state. If there is no visible response, the output change may still be inside the mechanical deadband.
4. Apply another small step. Repeat in equal increments until the PV or valve position changes.
5. Record the total output change required to initiate movement. That accumulated change is the practical breakaway threshold.
6. Reverse direction and repeat. A different threshold on reversal indicates hysteresis.
7. Compare the measured deadband against expected valve behavior. A healthy final element should not require repeated output accumulation before movement under normal conditions.

What the bump test proves

A manual bump test can support several bounded conclusions:

• It can show that the actuator response is non-linear.
• It can estimate the effective deadband or breakaway threshold.
• It can reveal directional hysteresis.
• It can help separate controller tuning issues from valve mechanics.

It does not by itself identify the exact physical failure mode. Packing friction, actuator linkage wear, positioner issues, air supply problems, and valve sizing problems can all produce similar symptoms. Diagnosis still needs instrumentation judgment.

Stiction creates a limit cycle because the integral term keeps integrating error while the valve is stuck. Once the controller output exceeds static friction, the valve moves too far relative to the accumulated correction, and the process overshoots.

The sequence is mechanically simple and mathematically inconvenient:

• The PV drifts away from setpoint.
• The PID sees sustained error.
• The I term accumulates because the error persists.
• The valve remains stuck until breakaway force is exceeded.
• The valve suddenly moves.
• The PV overshoots.
• The controller reverses output.
• The same sequence repeats in the opposite direction.

This is a classic non-linear oscillation mechanism. Retuning may change how fast the loop enters the cycle, but it usually does not remove the underlying deadband. Lowering gain can make the problem look quieter. It does not make the valve less stuck.

Why integral action is usually the amplifier

Integral action is usually the term that turns stiction into visible hunting because it keeps accumulating output demand during the no-response period. Proportional action reacts immediately to error, but integral action stores accumulated correction.

That is why stiction often appears as:

• long CV ramps,
• delayed valve motion,
• abrupt PV changes,
• and repeated overshoot near setpoint.

If anti-windup protection is weak, the cycle can become even more persistent.

OLLA Lab simulates stiction by allowing the learner or instructor to introduce non-linear valve behavior into a realistic process scenario and then observe its effect across the control stack: ladder logic, variables, trends, and simulated equipment state.

That matters because “Simulation-Ready” should mean something operational, not decorative. In this context, a Simulation-Ready engineer is one who can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. That is a stricter standard than knowing ladder syntax.

What OLLA Lab allows engineers to rehearse

Within the platform, engineers can practice:

• building or reviewing ladder logic around a process loop,
• monitoring SP, PV, CV, alarms, timers, analog values, and tag states,
• comparing signal behavior against a 3D or WebXR equipment model,
• injecting abnormal conditions such as valve stiction,
• running manual tests without risking plant equipment,
• revising logic after diagnosis,
• and documenting the difference between a control problem and a mechanical problem.

This is bounded product value. OLLA Lab is not a substitute for plant experience, maintenance craft knowledge, or formal safety validation. It is a risk-contained rehearsal environment for tasks that are too costly, too disruptive, or too unsafe to teach by trial on live assets.

### A practical ladder artifact: loop-hunting alarm logic

A useful training exercise is to detect persistent deviation near setpoint and raise a diagnostic alarm for operator review. The logic below is intentionally simple. It is not a universal alarm philosophy, but it is a credible starting pattern.

|----[SUB SP PV DEV_RAW]-------------------------------------------| |----[ABS DEV_RAW DEV_ABS]-------------------------------------------|

|----[GEQ DEV_ABS 2.0 ]-------------------------(HUNT_DEV_HIGH)------|

|----[TON HUNT_ACCUM 1000 ms]----------------------------------------| | Enable: HUNT_DEV_HIGH | | Preset: 30000 ms |

|----[TON HUNT_WINDOW 1000 ms]---------------------------------------| | Enable: LOOP_IN_AUTO | | Preset: 60000 ms |

|----[XIC HUNT_ACCUM.DN]----[XIO HUNT_WINDOW.DN]-----(LOOP_HUNT_ALM)---|

|----[XIC HUNT_WINDOW.DN]-------------------------(RES HUNT_ACCUM)-----| |----[XIC HUNT_WINDOW.DN]-------------------------(RES HUNT_WINDOW)----|

What this alarm does

This logic implements a bounded diagnostic rule:

• Calculate the absolute deviation between setpoint and process variable.
• If deviation exceeds 2%, accumulate time.
• If the loop spends 30 seconds above that threshold within a 1-minute window, trigger a Loop Hunting Alarm.
• Reset the counters at the end of the observation window.

This does not prove stiction by itself. It proves persistent deviation. In OLLA Lab, the learner can then correlate that alarm with oscilloscope traces and equipment behavior to determine whether the root cause is poor tuning, external disturbance, or non-linear valve response.

A credible training record is a compact body of engineering evidence, not a gallery of interface captures. Screenshots are supporting material. They are not proof of diagnostic reasoning.

Use this structure:

State what acceptable behavior means in measurable terms: settling time, overshoot limit, steady-state error, alarm constraints, or disturbance recovery.

1. System Description Define the process loop, controlled variable, manipulated variable, operating objective, and equipment context.
2. Operational definition of “correct”
3. Ladder logic and simulated equipment state Include the relevant ladder sections, tag mapping, and the observed valve or equipment behavior in the simulation.
4. The injected fault case Specify the abnormal condition introduced, such as 1.5% valve stiction, signal bias, sensor lag, or actuator delay.
5. The revision made Document whether the response was tuning, alarm logic, operator guidance, maintenance escalation, or interlock revision.
6. Lessons learned State what the test proved, what it did not prove, and what would require field confirmation.

That format demonstrates judgment. Reviewers generally care less about whether a rung looks tidy than whether the engineer can defend why it exists.

Tune the PID when the actuator response is continuous and the loop behavior changes predictably with gain adjustments. Suspect hardware first when the control output changes smoothly but the process responds only after threshold crossings, jumps, or directional deadband.

A practical screening rule is:

• Tune first if the waveform is smooth, symmetric, and gain-sensitive.
• Inspect hardware first if the waveform is stepped, threshold-driven, and resistant to tuning changes.

Other hardware-side causes can mimic stiction:

• valve sizing errors,
• positioner calibration drift,
• pneumatic supply instability,
• linkage backlash,
• sensor noise or filtering mismatch,
• and intermittent mechanical binding.

The point is not to romanticize hardware faults. It is to stop treating every oscillation as a software confession.

A digital twin is useful here because it makes the relationship between signal behavior and physical mechanism observable in one place. For this article, “digital twin validation” means testing ladder logic and control responses against a virtual equipment model whose state changes can be inspected alongside I/O and trend data.

That is an operational definition, not a prestige label.

In OLLA Lab, the value is not that the model is virtual. The value is that the learner can:

• induce a known non-linearity,
• observe repeatable trend signatures,
• compare ladder state to equipment state,
• and practice the diagnostic sequence without risking a live valve, process upset, or maintenance event.

That is especially useful for commissioning preparation. Real plants rarely offer controlled failures on demand, and when they do, nobody calls it training.

Diagnosing hunting at the setpoint begins with one disciplined question: Is the controller overcorrecting, or is the valve failing to respond continuously? If the oscillation is smooth and gain-sensitive, tuning is the likely path. If the controller output ramps while the process waits and then jumps, suspect stiction and test the final element.

OLLA Lab is credible in this workflow because it keeps the product inside the proof chain. It allows engineers to rehearse manual bump testing, trend interpretation, fault injection, and ladder revision in a risk-contained environment. That is the useful boundary. It does not replace field commissioning, but it does let engineers practice the parts of commissioning that live equipment tends to punish.

- Bialkowski (1993), ISA Transactions90009-M) - Ender (1993), ACC proceedings on loop performance - McMillan, *Tuning and Control Loop Performance* (ISA) - Skogestad (2003), PID tuning rules00062-8) - IEC 61508 Functional Safety overview