Tuning for Setpoint Tracking versus Disturbance Rejection
This discussion is as old as controller tuning itself: should one tune a controller to respond well to setpoint changes or to do well at rejecting disturbances. Different tuning rules have been developed for the two cases, and much research has been done to find the silver bullet of a tuning rule that would do well in both cases, which is not possible.
So what is the real issue here? The problem becomes apparent in a control loop that has a process with much more lag than dead time. That is, the process’ time constant is more than two times as long as its apparent dead time (which also includes any small lags). If such a control loop is tuned for fast disturbance rejection, and an operator makes a setpoint change, the loop overshoots the setpoint. If the control loop is tuned to not overshoot after a setpoint change, it provides sluggish response to disturbances.
This typically is not a problem with flow or liquid-pressure control loops (because their lags are typically shorter than two times the apparent dead time), but it can be a problem with temperature control loops, and especially with large-volume gas pressure control loops – as shown in the two figures below.
As I said previously, this is not an issue on many control loops because their processes are balanced in the amount of dead time and lag they have. It also is not an issue with control loops that never undergo setpoint changes (tune for disturbance rejection) or in the rare cases where there are setpoint changes but no disturbances (tune for setpoint changes). But this is an issue on many lag-dominant loops that are subject to both disturbances and setpoint changes.
So here is my advice: Always tune control loops for good disturbance rejection. If overshoot after a setpoint change is a problem, use the proportional on process variable (P on PV as opposed to P on Error) controller option. This controller option does a great job of eliminating overshoot after a setpoint change. If your controller does not provide this option, you can use a setpoint filter to eliminate overshoot after a setpoint change (see https://blog.opticontrols.com/archives/1319). The setpoint filter’s time constant should be set between 1 and 1.5 times the integral time (as per controls guru Greg McMillan). I have also had good success by setting the setpoint filter’s time constant equal to the process time constant.
Do not use setpoint filtering or P on PV in control loops that have to actively track their setpoints, such as the secondary/inner loop in a cascade-control arrangement. It will seriously deteriorate the system’s control performance. Luckily, overshoot rarely poses a problem in cascaded inner loops.
A final note: Please realize that the solutions above do not apply to control loops with integrating processes (such as liquid level control). These control loops will always overshoot their setpoints after a setpoint change. Unless, of course, you do not use any integral action in the controller or turn it off during a setpoint change.
Stay tuned.
Jacques Smuts
Founder and Principal Consultant of OptiControls Inc.
Author of Process Control for Practitioners
Jacques, helpful guidance as usual.
A comment about cascade loops: overshoot can be a problem in some secondary loops such as steam temperature control since it can cause frequent actuator reversals, overheating motor actuators or wearing glands prematurely – even though the control looks OK. Some “gap” setting can help but is limited to a very small value in this case.
So how does one calculate P on PV?
John: You would do step testing, calculate the process characteristics, and then calculate tuning settings, e.g. using the Cohen-Coon method. Regardless of if P is on PV or Error. That is the key point I’m trying to make in this post.