Figure 1: Load response with the PID controller tuned for good set point (yellow line) and good response to load upsets (red line). Top: Process load. Bottom: Measurement upset.
While tuning loops by repeatedly making setpoint changes may seem workable, the results may be far from what your plant needs.
Joe control engineer had a problem. The operations people threatened to throw him out of the control room if he "keeps fooling with the tuning on that reactor temperature loop". He had spent the last few days tuning the temperature loop, but here it was again, that recurring offset. Yet, even now when he asked the operator to once more make a setpoint change, the loop response looked great but still had offset.
Joe's problem was the result of tuning the loop by making setpoint changes when what the plant really wanted was to "just keep the measurement steady and on setpoint." In other words, the plant wants the loop tuned so load upsets have little or no effect. If you tune for setpoint changes, load upsets could cause lots of offset. Joe was the unlucky victim of a loop with a large lag (time constant), or an integrator. Unknowingly he had tuned the loop for great setpoint response by removing most of the integral action from the controller. Poor load response resulted in lots of offset and got Joe in hot water. A process dominated by lag is one with a lag at least 10 times larger than the dead time.
Figure 1: Load response with the PID
controller tuned for good set point (yellow line) and good
response to load upsets (red line). Top: Process load. Bottom:
Measurement upset.
The yellow line in the Figure shows the upset or load response to Joe's loop using his tuning that gives great set point response. The red line shows the response when the same loop is tuned to reject load disturbances. We adjusted the yellow line's tuning to be similarly robust to Joe's (If we made it less robust the response could have been twice as good).
The yellow line in the Figure shows Joe's setpoint response. Nice. The red line shows the controller response tuned for good response to load changes. So, it seems that we had to give up Joe's good set point response to get better load response. We did. However, there are ways to get some of both.
Figure 2: Comparison of setpoint responses. Yellow line: gain-on-error
controller tuned for good setpoint. Red line: gain-on-error
controller tuned for good load. Violet line: tuned for good load
using gain-on-measurement controller. Green line: gain-on-error
controller tuned for good load using a ramped setpoint.
Like most controllers, and with the one Joe used, the gain (or proportional band) works on the error:
Controller output from gain term = Gain*(Error)
Error = Setpoint - Measurement
This is a gain-on-error controller.
If Joe selects a controller where gain works only on the measurement (or process variable):
Controller output from gain term = Gain*(Measurement)
then the gain does not give a "kick" on set point response. This is a gain-on-measurement controller. He can get setpoint response with no overshoot and get good load response! There is a catch though. The setpoint response is not blazingly fast. Compare responses in Figure 2. The violet line shows the gain-on-measurement controller's response with the same tuning as the gain-on-error controller (red line). The controller now has smooth setpoint response, but it is slow.
Since the gain still works on measurement, the load response of gain-on-measurement controller is identical to that of the gain-on-error controller. For a load, the gain-on-measurement controller "sees" the measurement feedback and acts on it exactly the same as the gain-on-error controller. Because the error term contains the setpoint, the gain-on-error has different setpoint response.
If you do not have the option of selecting whether controller can be a gain-on-measurement you can still smooth the setpoint response somewhat by ramping it. However, the ramped setpoint response will overshoot some and the measurement will take longer to reach the final setpoint. See the green line in Figure.
If you are going to try this at home, you'll want to know that we adjusted the tuning of the controller "tuned to reject load" to be similarly robust as the one for "good set point response."
There is a trade-off between tight tuning and sensitivity to process gain or dead time changes. In general, the faster the tuning, the more sensitive the loop is to process changes. The old fashioned rule for tuning is that you want "as high gain as possible at all frequencies without going unstable". A robustness plot in the simulation software graphically allowed us to see the control loop's sensitivity to the tuning. We used the robustness plot to adjust the set point and load tuning in the above Figures to be the same sensitivity.
The load tuning could have been faster. This would have given even more overshoot to set point response, much better response to load changes, but poorer robustness.
Researchers sometimes use simulated loads added to the measurement (or process output) to check on controller load response. Measurement upset response is not that important in industry and can be misleading. Measurement upsets would be like the sensor "glitching", or a temporary hot spot around the sensor. These kinds of problems should be corrected by fixing the process hardware. They should not be "fixed" by a tuning technique that would hide the problem. Load upsets like the one in Figure 1 (top) correspond to changing feed or ambient temperature. Another example would be an inlet or outlet flow upset in a level loop.
Figure 1 (top) shows the same controllers and tuning as in Figure 1 (bottom) but the response is for a measurement upset. The yellow line shows the controller tuned for good set point response. The red line is for the same controller tuned for good response to load changes. The performance compares similarly to the red and yellow setpoint responses of Figure 2; the controller tuned for setpoint looks good here. But stop; this is for the theoretical load that you probably won't find important in your plant. Here we are getting good response in the wrong place. We need good response for real load changes as shown in the Figure 1 (top).
Joe's loop contained a large lag time. If the process is not dominated by a large lag, then tuning for set point changes can give excellent load response also. The more the process is dominated by dead time, the more similar tuned set point and load response become.
Figure 3: Comparison of setpoint and load responses. Red lines demonstrate
tuning for good response to load changes. Yellow lines are tuning for good
setpoint response.
For example, Figure 3 shows the setpoint and load response of
controllers tuned for setpoint (yellow lines) and tuned for good
response to load changes (red lines). This process contains a lag
time equal to the dead time. The responses are fairly similar.
If you have the choice, should you use the controller with gain-on-error or gain-on-measurement for the slave in a cascade loop?
With the gain-on-error the slave responds quicker to the master's controller output. With the gain-on-measurement, the slave responds smoother, but slower, to the master's controller output. So there is a trade-off.
Simulations using ProcessPlus/Cascade for a variety of processes show that for slave processes that are dominated by dead time, it makes little difference which controller you use. For slave processes that are mostly lag or dominated by lag then both master-slave controller combinations can be tuned for similar response of the master's measurement. But a slave controller with gain-on-measurement gives slave and master responses with less oscillation.
Figure 4: Load responses with the slave controller as gain-on-error:
yellow line, gain-on-measurement: red line.
Compare responses in Figure 4.
Both master and slave processes in Figure 4 are dominated by lag.
The red lines shows response using the gain-on-measurement
controller for the slave, while the yellow line uses the
gain-on-error controller. The slave controllers in both use the
same tuning. The master controller (yellow line) has been
de-tuned to be of similar robustness as that of the red line. The
gain-on-error (yellow line) controller causes lots of oscillation
because the slave overshoots a lot to setpoint changes. But what
if the slave with the gain-on-error is tuned for smooth setpoint?
Then, further simulations show that the control system responds
well to load upsets in the master loop, but because it had to be
de-tuned to give the smooth setpoint response, load upsets in the
slave affect the master about 10 times more than without the
detuning.
The gain-on-measurement controller seems to be the best to use for the slave loop of a cascade.
Most of the time in the process industries, response to load changes or good regulation is why a controller is used at all. Setpoint response is usually not as important. Control loops optimized for good setpoint response may not reject loads well when the process contains an integrator or large lag.
Use the controller with gain-on-error. It will give slightly better set-point response. Tune for good set point response or good response to load changes.
Use the controller with gain-on-measurement. Tune for good response to load changes. If your controller is a gain-on-error and you need setpoint response with little or no overshoot, then ramp the setpoint. If you need the fastest set point response, use gain-on-error and tune for setpoint, but the response to load changes will be miserable.
Now you can get both good setpoint and good load response using a setpoint filter. ExperTune PID Analyzer and Tuner software designs the setpoint filter for you and shows you how to implement it.
Use the controller with gain-on-measurement. Tune the slave for good response to load changes. This insures good response to load upsets and you'll also get smooth set point response with little oscillation.
All the simulations and figures for this article were created using the ExperTune Loop Simulator.