PIDSnap

Control loop will not hold setpoint

A loop sitting steadily away from setpoint is a different problem from a loop that cycles, and it has a much shorter list of causes. In almost every case the controller has either been prevented from correcting the error or has no mechanism to correct it in the first place.

A sluggish control loop crawling towards setpoint Trend of a sluggish PID loop: the process variable creeps towards setpoint and has still not arrived by the end of the window. high low PV SP Output PIDSnap time
Trend of a sluggish PID loop: the process variable creeps towards setpoint and has still not arrived by the end of the window. No overshoot at all, and an offset that is still closing when the trend ends. A loop that never overshoots is not a well-tuned loop, it is a slow one. The output barely moves, which is the giveaway that the controller is not being asked to do much.

What causes it, most likely first

No integral action

most common tuning can fix this

Proportional action needs error to produce output, so a proportional-only loop settles wherever the proportional term balances the load — not at setpoint. The offset grows as the load moves away from where the bias was set. On averaging level control this is deliberate. On flow or pressure it almost never is.

How to confirm it
Check the controller structure and the reset value. Either a P-only structure or a reset value of zero (in time-per-repeat units) gives you this.
What to do
Confirm whether proportional-only was deliberate. If not, integral action needs to be enabled.

Output saturated

most common tuning cannot fix this

The controller is asking for more than the final element can deliver, so the error persists no matter what the tuning is.

How to confirm it
The output sits at 0% or 100%.
What to do
Deal with the constraint. See the saturated output page.
Controller output saturated at its limit Trend showing controller output saturation: the output sits flat against its upper limit while the process variable never reaches setpoint. high low PV SP Output PIDSnap time
Trend showing controller output saturation: the output sits flat against its upper limit while the process variable never reaches setpoint.

The loop has lost the selection in an override scheme

common tuning cannot fix this

In a selector scheme only the winning controller drives the output. A loop that has been overridden is not in control and will sit away from its setpoint by design.

How to confirm it
Check which controller currently has the output. A loop whose output does not match its error is a strong hint.
What to do
Nothing at the loop. Understand the override scheme and why it is active.

Reset so slow the offset never closes

common tuning can fix this

Integral action is present but slow enough that the offset persists for a very long time.

How to confirm it
The gap is closing, just extremely slowly. Watch over several minutes rather than seconds.
What to do
Speed the reset up in steps.

A calibration difference between measurement and reference

less common tuning cannot fix this

The loop is holding its own measurement at setpoint perfectly, and the measurement disagrees with whatever you are comparing it against.

How to confirm it
Compare the transmitter against a local gauge or a laboratory sample.
What to do
Calibration, not tuning.

Questions that come up

Can I just bias the setpoint to compensate?

You can, and on a proportional-only loop that is exactly what the manual reset or bias term is for. But it only holds at one load. As soon as the load changes, the offset changes with it and the bias is wrong again.

Related

Last reviewed 2026-08-01.

Run a free PIDSnap check on this loop

Two photos, thirty seconds, no signup. The pre-flight check finds the structural problems that no amount of tuning will fix — before you touch the controller.

Start a free check