How to Program PLC Logic for Valve Hysteresis

Control valve hysteresis is the difference in valve position for the same command signal depending on whether the valve is opening or closing. In PLC-controlled loops, that mechanical lag can drive integral windup-like behavior and hunting. A practical software response is bounded deadband and rate-aware validation before live commissioning.

Valve hysteresis is not a tuning myth. It is a mechanical nonlinearity that can make a well-structured PID loop behave badly because the controller output and the actual valve position stop matching in a predictable, direction-dependent way.

A common mistake is to treat the resulting oscillation as a pure tuning problem. Sometimes it is. Often it is not. Historical process-control audits frequently cited in industry literature have reported that a substantial share of poorly performing loops involve final control element problems, especially friction, stiction, backlash, or hysteresis, rather than PID constants alone. Those figures are useful as directional evidence, not as a universal plant law.

During baseline testing in OLLA Lab’s digital twin environment, injecting 3% simulated valve hysteresis into a level-control scenario caused a default PID configuration to produce approximately ±8% PV oscillation within 12 minutes. Methodology: n=1 scenario, level-control task, baseline comparator was the same loop with no injected hysteresis, and the observation window was 12 minutes. This supports one narrow point: modest mechanical lag can destabilize an otherwise reasonable loop. It does not support a general industry-wide failure rate.

That distinction matters because syntax is not deployability. A rung that compiles is not yet a loop that will behave on a sticky valve.

Control valve hysteresis is the maximum difference in valve output for the same input value during a full calibration cycle, excluding time-dependent effects such as drift. That framing is consistent with ISA terminology used to distinguish hysteresis from related valve nonidealities.

In practical control terms, hysteresis means the PLC may command 50%, but the valve stem may sit at one position while opening and a different position while closing. The command is identical. The mechanical state is not.

This is why operators sometimes say the valve is “lying” to the loop. The language is informal, but the problem is real.

How is hysteresis different from stiction and mechanical deadband?

These terms are often mixed together. They should not be.

| Condition | Operational definition | Typical loop symptom | |---|---|---| | Hysteresis | Different valve position for the same command depending on travel direction | Direction-dependent offset and cycling | | Stiction | Static friction prevents motion until force builds, then the valve jumps | Stick-slip motion, sawtooth-like oscillation | | Mechanical deadband | Range of input change that produces no observable valve movement | Delayed response around reversals or small corrections |

A useful distinction is this:

• Hysteresis is path-dependent lag
• Stiction is breakaway friction
• Deadband is a no-response zone

They often coexist. Valves are not obliged to fail one concept at a time.

Why does hysteresis appear in real valves?

Hysteresis usually comes from the mechanics of the final control element, not from the PLC instruction itself.

Common contributors include:

• Packing friction
• Actuator linkage backlash
• Seal drag
• Positioner issues
• Shaft or stem wear
• Poor maintenance or contamination
• Undersized or poorly selected valve assemblies

The PLC only discovers the problem after the process starts misbehaving.

Hysteresis causes PID hunting by breaking the assumed relationship between controller output and process response. The controller believes a small output correction should produce a small valve movement. The valve does not respond proportionally.

The failure pattern is usually sequential rather than mysterious.

The 3 stages of hysteresis-induced oscillation

1. Command lag The PID output changes, but the valve does not move enough, or does not move at all, because friction or directional lag absorbs the correction.
2. Integral saturation-like buildup The error persists, so integral action continues accumulating output demand. The controller is acting on the evidence it has.
3. Mechanical overshoot Once friction is overcome, the valve moves too far relative to the accumulated integral effort, and the process variable crosses past the desired value. The cycle then repeats in the opposite direction.

This is one reason loop hunting can survive multiple retuning attempts. If the final element is nonlinear, cleaner gains alone may only produce cleaner disappointment.

Why is integral action usually the first culprit?

Integral action is designed to eliminate steady-state error. That is useful when the final control element responds proportionally. It is less useful when the valve ignores small commands until enough force accumulates.

When hysteresis is present:

• small errors persist longer,
• integral action keeps accumulating,
• output changes become more aggressive,
• and the valve eventually breaks loose with too much stored correction behind it.

This is not classic integral windup in the narrow output-saturation sense, but it is closely related in practice: the integral term keeps pushing because the loop does not see the expected process response.

What should you look for in trend data?

Trend evidence is usually clearer than argument.

Look for:

• Repeating oscillation around setpoint despite conservative tuning
• Controller output moving smoothly while PV responds in delayed jumps
• Different response behavior when the valve is opening versus closing
• Small output changes with no PV response, followed by abrupt correction
• Better apparent stability in manual mode than in automatic mode

If the CV looks civilized and the PV looks inconsistent, inspect the valve behavior before rewriting the tuning sheet.

A practical software mitigation is to suppress or freeze integral contribution when the control error is inside a defined tolerance band that is smaller than the process alarm margin but large enough to avoid chasing valve friction.

This does not fix the valve. It changes the controller’s behavior so it stops issuing futile micro-corrections inside a region where the valve is unlikely to respond cleanly.

What does deadband logic do in operational terms?

Deadband logic tells the controller:

• if the process error is very small,
• and the valve’s mechanical imperfection is likely larger than the benefit of correction,
• then do not keep integrating that small error.

That is the key distinction:

• Deadband is not laziness
• Deadband is a controlled refusal to amplify mechanical noise

### Structured Text example: freeze integral action inside the hysteresis band

Error := SP - PV; AbsError := ABS(Error);

IF AbsError < Deadband_Limit THEN Integral_Enable := FALSE; ELSE Integral_Enable := TRUE; END_IF;

DeltaCV := CV_Command - CV_Last;

IF DeltaCV > CV_RateLimit THEN CV_Command_Limited := CV_Last + CV_RateLimit; ELSIF DeltaCV < -CV_RateLimit THEN CV_Command_Limited := CV_Last - CV_RateLimit; ELSE CV_Command_Limited := CV_Command; END_IF;

IF Integral_Enable THEN PID_Integral_Mode := TRUE; ELSE PID_Integral_Mode := FALSE; END_IF;

CV_Out := CV_Command_Limited; CV_Last := CV_Out;

This is a pseudo-implementation, not a vendor-specific instruction set. Actual deployment depends on the PLC platform, PID block structure, scan behavior, and whether the controller exposes integral hold, bias tracking, or external reset feedback.

Pseudo-ladder logic concept

A ladder-oriented implementation usually includes:

- branch logic that either:

• subtraction block for `SP - PV`
• absolute value block
• comparator for `ABS(Error) < Deadband_Limit`
• internal bit such as `INT_HOLD`
• disables integral accumulation, or
• routes the PID block into a hold or freeze mode
• optional rate limiter on output command change per scan or per second

The exact mechanism matters less than the control intent: stop integrating inside a region where the valve cannot deliver proportional correction.

How do you choose the deadband value?

The deadband should be based on observed mechanical behavior and process tolerance, not on aesthetic preference.

A defensible starting method is:

• estimate the effective hysteresis or no-response region from trend data or valve testing,
• convert that behavior into an equivalent control error or output band,
• set the deadband just large enough to prevent futile correction,
• then verify that product quality, level stability, pressure control, or energy performance remain acceptable.

Too small, and the loop still hunts. Too large, and you have simply renamed poor control as strategy.

Why should you also limit output velocity?

Output velocity limits reduce aggressive command changes that can worsen friction-related behavior or produce abrupt breakaway events.

In practice, rate limiting helps by:

• smoothing controller output transitions,
• reducing repeated reversals near setpoint,
• lowering stress on sticky mechanical elements,
• making trend diagnosis easier.

This is not a substitute for maintenance. It is a software-side restraint that can make a damaged or friction-heavy loop more manageable until the hardware is corrected.

A control strategy is simulation-ready when an engineer can prove, observe, diagnose, and harden the logic against realistic process behavior before it reaches a live process.

That definition is operational, not decorative.

A simulation-ready valve-control routine should allow the engineer to:

• observe the difference between commanded CV and simulated valve movement,
• inject mechanical lag, hysteresis, or delayed response,
• monitor PV, SP, CV, and internal control states together,
• test abnormal conditions without risking equipment or process upset,
• revise the logic and compare before-and-after behavior under the same fault.

This is the real progression from syntax to deployability. Plants do not commission against idealized diagrams.

Yes, if digital twin validation is defined narrowly and used honestly.

In this article, digital twin validation means the engineer can inject a simulated mechanical delay or direction-dependent valve response between the controller output and the process feedback, then observe whether the control logic remains stable under that degraded condition.

That is a useful test. It is not a SIL claim, a site acceptance test, or a substitute for field commissioning.

What does this look like in OLLA Lab?

OLLA Lab is useful here as a bounded validation environment.

An engineer can use the platform to:

• build or review the ladder logic controlling the loop,
• run the logic in simulation mode,
• monitor tags, analog values, and output behavior in the variables panel,
• compare controller demand against simulated equipment state,
• inject a fault condition representing hysteresis or lag,
• revise deadband or output limiting logic,
• rerun the scenario under the same conditions.

This is where OLLA Lab becomes operationally useful. It lets engineers rehearse a high-risk commissioning task that would be expensive, slow, or unsafe to provoke on a live process.

Why not test this directly on the plant?

Because intentionally driving a sticky valve into oscillation on a live process can create avoidable risk.

Depending on the service, that risk may include:

• spills or overflow,
• unstable reactor or tank behavior,
• nuisance trips,
• product quality loss,
• unnecessary valve wear,
• operator intervention that obscures the original control problem.

Live plants are poor places to “see what happens” when the answer may involve cleanup reports.

Labeled media concept

Visual: Split-screen image showing OLLA Lab variables and simulated valve behavior. Alt text: Screenshot of OLLA Lab digital twin simulation comparing a smooth PLC control variable output against a delayed, jumping mechanical valve plunger, illustrating control valve hysteresis.

The right output is a compact body of engineering evidence, not a screenshot gallery.

Use this structure:

State the acceptable control behavior in measurable terms: settling range, oscillation limit, overshoot tolerance, alarm margin, or recovery time.

1. System Description Define the loop, process objective, valve role, and control architecture.
2. Operational definition of correct behavior
3. Ladder logic and simulated equipment state Show the control logic, relevant tags, and the expected relationship between CV, valve position, and PV.
4. The injected fault case Document the simulated hysteresis, stiction, or lag condition and how it was introduced.
5. The revision made Record the deadband, integral hold, rate limit, or other logic change applied.
6. Lessons learned Explain what changed, what improved, and what still requires field verification or mechanical maintenance.

This form of evidence is more persuasive because it preserves causality. Anyone can post a trend. Fewer people can explain why it changed.

The technical discussion sits across instrumentation, control theory, and functional validation.

Useful references include:

• ISA terminology and valve-performance definitions for hysteresis, deadband, and related calibration behavior
• IEC 61508 for the broader discipline of lifecycle rigor, validation, and bounded claims around safety-related systems
• exida guidance and process-control reliability literature for practical distinctions between software behavior and hardware fault mechanisms
• IFAC and process-control publications on nonlinear actuator effects, stiction compensation, and loop performance degradation
• Industrial vendor and audit literature from firms such as Emerson and EnTech, when clearly qualified as field studies rather than universal statistics

The key editorial rule is simple: use standards for definitions, literature for mechanisms, and internal simulation data only for bounded observations.

Deadband logic is a mitigation, not absolution.

Before deployment, verify:

• the valve has been inspected or at least diagnosed as a likely contributor,
• the deadband does not mask a quality-critical error,
• alarms and trips remain appropriate,
• operator expectations are updated,
• output rate limiting does not create unacceptable sluggishness,
• the control objective still matches process risk.

A stable loop can still be wrong. Quiet failure is still failure, just with better manners.

- 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