Overshoot after a setpoint change
Overshoot on a setpoint change and overshoot on a load change are different symptoms with different causes, and separating them is the fastest route to the answer.
If the loop overshoots on both, it is a tuning question. If it overshoots only when somebody moves the setpoint, the cause is almost always structural — how the controller handles setpoint changes — and no amount of retuning will fix it without sacrificing disturbance rejection.
Test both kinds of upset
Make a small setpoint change and capture the response. Then wait for a natural load disturbance, or create one, and capture that.
Overshoot on both points at proportional action being too high or reset too fast. Overshoot on setpoint changes only points at derivative acting on error, or at a controller structure that applies the full proportional term to setpoint changes.
Derivative kick and how to remove it
A setpoint change is a step, and the derivative of a step is a spike. If derivative acts on error rather than on the process variable, that spike goes straight to the valve on every setpoint move.
There is no control benefit to it — the disturbance being rejected is one the operator just created deliberately. Derivative on PV gives identical disturbance rejection without the kick, which is why it is the normal configuration.
Windup looks like overshoot but is not a tuning problem
If the output was sitting at a limit before the overshoot, the integral term accumulated while the controller could not act on it. The recovery overshoots because that accumulated term has to unwind.
The giveaway is the output staying at its limit after the process variable has already crossed setpoint. Detuning in response makes it worse, because a slower loop spends longer saturated.
What causes it, most likely first
Derivative acting on error
most common tuning can fix this
Produces an output spike on every setpoint change.
- How to confirm it
- Overshoot on setpoint changes only, with a visible output spike at the moment of the change.
- What to do
- Configure derivative to act on PV instead of error.
Integral windup after saturation
most common tuning can fix this
Accumulated integral action unwinding after the output has been clamped.
- How to confirm it
- Output stays at the limit past the setpoint crossing.
- What to do
- Check anti-reset windup configuration.
Proportional action too high
common tuning can fix this
Straightforward over-correction.
- How to confirm it
- Overshoot on load changes as well as setpoint changes.
- What to do
- Reduce proportional action.
Reset too fast
common tuning can fix this
Integral action continuing to push after the error has been corrected.
- How to confirm it
- Overshoot develops slowly rather than immediately, and the loop takes several swings to settle.
- What to do
- Slow the reset.
Questions that come up
Can I use setpoint ramping instead of fixing this?
Ramping the setpoint does remove the symptom, and on some loops it is the right answer regardless. But if the cause is derivative kick or windup, ramping is hiding a configuration problem that will show up again the next time something steps the setpoint quickly.
Related
Last reviewed 2026-08-01.