PID spotlight part 10: Heuristic tuning, deadtime-dominant self-limiting process

 

Deadtime dominant self-limiting processes behave differently than lag dominant and moderate processes. This means that the visual cues we used to determine whether a controller had too much or too little controller gain or the integral was set too fast or slow in PID spotlight part 9 do not apply to deadtime dominant processes. We need to establish what the new visual cues are and identify any new shortcut calculations we will use to help speed our controller tuning efforts.

In short, we need to establish what good tuning looks like for a deadtime dominant process and to see what bad tuning looks like. However, this information doesn’t change the basics of the heuristic controller tuning process. We are still using pattern recognition to determine whether the controller has too much or too little controller gain and/or if the integral is too slow or too fast. With deadtime dominant processes we do not need to worry about derivative; it should always be set to zero. If you haven’t already done so, please read PID spotlight part 9 before proceeding.

Note: Everything that follows applies only to deadtime dominant self-limiting processes. Heuristic tuning of lag dominant and moderate self-limiting processes was covered in PID spotlight part 9.

What does good look like for deadtime-dominant processes?

For lag dominant and moderate processes, we have a rule that says a properly tuned PID controller should have a controller gain larger than the baseline controller gain (K > K_base). We’ve also established that for deadtime dominant processes the controller gain must be set below the baseline controller gain for stable control (K < K_base). Clearly the second statement means that the first statement cannot be true for deadtime dominant processes, therefore we need to establish “what good looks like” for a deadtime dominant process. This brings us to Figure 1.

Ideal tuning for a deadtime dominant process is critically damped; the process variable (PV) gets to setpoint (SP) as fast as possible without overshoot. We do not want overshoot as this will cause a persistent error. Nor do we want undershoot because this will also result in a persistent error. Note that on a deadtime dominant process if the controller misses on its first error correction attempt it must wait through the deadtime before it gets a second chance at correcting the error.

Ideal tuning for a deadtime dominant process looks like:

• An initial output (OP) step that is less than the final OP value after the process lines out (required for stability).

• An integral action ramp that matches the final OP value when the PV starts moving.

• The OP remains flat while the PV ramps to the SP without stalling or overshoot.

A close look at the controller gain and integral contribution plots provides some insight into how the controller behaves:

• On the SP change the controller gain steps the OP proportional to the controller error. During the deadtime period the controller gain contribution remains fixed (as we learned in PID spotlight part 2).

Once the PV starts moving the controller gain contribution returns to zero as the error is reduced to zero.

• After the SP change the integral action starts to ramp as it attempts to eliminate the error. During the deadtime period the integral proceeds at a fixed ramp rate. We see this as a constant ramp in the OP until the PV starts moving.

• If tuned properly once the PV starts moving the integral action properly backfills the controller gain contribution as it returns to zero. This should result in stopping the OP at its final value.

What’s interesting here is the visible controller action is done when the PV starts moving. The OP, as if by magic, stops while the PV moves toward SP. What you don’t see (because control systems do not let you see) is that the controller gain contribution and integral contribution are still working until the PV reaches SP. The OP remains steady because the tuning is perfectly balanced.

As you can imagine if controller gain and integral are not perfectly balanced you get a much different response.

What does bad look like? Too much controller gain

Figure 2 shows the response of a controller on a deadtime dominant process tuned with too much controller gain. The first thing to note is the PV and OP peaks do not line up. Having the peaks line up is a key visual cue for spotting tuning with too much controller gain on lag dominant or moderate processes. However, the deadtime in a deadtime dominant process shifts the PV peak significantly after the OP peak. We need a new visual cue.

What we see in figure 2 is if there is too much controller gain on a deadtime dominant process the OP will make a sharp change in direction at the first peak after a SP change. This occurs because the controller gain contribution returns toward zero faster than the integral after the PV starts moving; the tuning is not well balanced.

What does bad look like? Integral set too fast

Figure 3 shows the response of a controller on a deadtime dominant process tuned with the integral set too fast. As with lag dominant and moderate processes the PV and OP peaks do not line up. This is good news; we can use the same visual cue to identify too much integral regardless of the lag/deadtime ratio. That said, we should note that this process has two minutes deadtime, and we should therefore be alert to the possibility that this is a deadtime dominant process.

What does bad look like? Too little controller gain

Figure 4 shows the response of a controller on a deadtime dominant process tuned with too little controller gain. Similar to lag dominant and moderate processes, we see that it takes a long time for the PV to reach the SP. Controller gain is not doing enough work, leaving integral to do most of the job.

The normal correction is to raise the controller gain to at least the baseline controller gain (K_base), however we should note that this process has a large deadtime and therefore we may have a deadtime dominant process. We saw in PID spotlight part  that setting controller gain equal to K_base may result in instability; we should limit an increase in controller gain to no more than two times the current controller gain.

What does bad look like? Integral set too slow

Figure 5 shows the response of a controller on a deadtime dominant process tuned with integral set too slow. Similar to lag dominant and moderate processes integral doesn’t backfill the controller gain fast enough once the PV starts moving. We can’t rely on the initial controller gain response to identify the problem; we know it’s going to be far short of the final OP value. We can, however, look for another visual cue: after the PV starts moving the OP will stall or even reverse direction. The PV will then stall or reverse direction after the deadtime period reflecting the OP stall. Depending on the lag/deadtime ratio this can become very pronounced.

What does bad look like? A summary: Too much, fast, little, slow

To summarize four bad ways:

• Too much controller gain: The controller OP makes a sharp change in direction when the process variable (PV) starts to move. Note that the PV and OP peaks will not line up due to the long deadtime.

• Integral is too fast: The PV and OP peaks do not line up (similar to lag dominant and moderate processes). The presence of deadtime should alert you that this might be a deadtime dominant process.

• Too little controller gain: The initial OP bump after a SP change will be far short of the final OP value (similar to lag dominant and moderate processes). The presence of deadtime should alert you that this might be a deadtime dominant process.

• Integral is too slow: The OP will stall or possibly even reverse after the PV starts moving.

It should strike you that we only have new visual cues for two of the four cases (too much controller gain and integral set too slow) and that these cues are potentially subtle. There are two additional cues to look for to warn us that we are working with a deadtime dominant process; deadtime and unstable controller operation when the controller gain is less than the baseline gain (K < K_base).

A shortcut for deadtime dominant tuning

If we suspect that we have a deadtime dominant process there is a shortcut we can use to speed our tuning based on our knowledge of what good tuning looks like.

Good tuning requires that the controller output (OP) reaches its final value when the process variable (PV) starts moving. For this to occur the sum of the controller gain contribution and the integral contribution must add up to the final OP by the end of the deadtime (Dt). Figure 6 is a picture of the three basic calculations and their relationship to each other. These can be used to either calculate the integral constant (T_i) if you think you know the controller gain (K), or calculate the controller gain if you think you know the integral constant. The three component calculations are:

Final controller output change can be calculated from the baseline controller gain and change in setpoint:

ΔOP = K_base* ΔSP

The controller gain contribution is (from our knowledge of the classical PID algorithm):

K * ΔSP

The controller integral contribution is (from our knowledge of the classical PID algorithm):

K * D_t * ΔSP

      T_i

Putting it all together we get:

ΔOP = K_base * ΔSP = K * ΔSP + K * D_t * ΔSP / T_i

Removing repeated terms and simplifying we get:

K_base = K * (1 + D_t / T_i)

From here we can either solve for controller gain (K) or integral (T_i). Figure 6 shows this relationship solved for T_i, which we would use if we knew what K was. Note that this relationship is only valid for the classical PID algorithm. If your system uses another algorithm, you must derive the proper relationship for that algorithm. That said, the basic principle remains the same: The controller gain contribution plus the integral contribution must equal the baseline controller gain at the end of the deadtime period.

Example one: On a simplified IMC PI tuning method

There is a fair bit of information up above, and it may be hard to see how it all works together. A couple of examples may help. Our first example uses heuristic tuning to trim a controller initially tuned using the simplified IMC PI tuning method.

In PID spotlight part 7 on open loop tuning, we used the simplified IMC tuning method to calculate tuning constants for a process with a gain of 2.0, three equal lags of 10 seconds, and a deadtime of 120 seconds. The open loop step test identified an apparent deadtime of 2.08 minutes and an overall process lag of 0.45 minutes. The baseline gain (K_base) is 0.5.

Figure 7 shows the response to a setpoint (SP) change. I noted in PID spotlight part 7 that integral might be set too slow. Based on our identification cues, we can say that indeed the integral appears to be too slow, the controller output (OP) stalls and then backs up when the PV starts moving. Our first move will be to calculate what we think the integral ought to be using our shortcut calculation:

T_i = 1.63

Figure 8 shows that the integral is still too slow. The OP still stalls and backs up after the PV starts moving. Note that the OP reached the final OP when the PV started moving and the PV did reach SP before it started drifting away. The shortcut calculation did do what we wanted; it got the PV to SP as quick as possible. Unfortunately, the tuning didn’t hold it there, which tells us that controller gain and integral are not properly balanced.

What this means is not only is the integral set too slow, but the controller gain is also too big. Both will need to be adjusted. You have a choice. Do you guess a new controller gain and calculate a new integral constant, or do you guess a new integral constant and calculate a new controller gain? In this case, we will guess a new integral constant (if for no other reason than to show that the calculation can be done both ways). Let’s speed up the integral 25%:

T_{i (New)} = T_{i (Old)} * 0.75

T_{i (New)} = 1.63 * 0.75

T_{i (New)} = 1.22

The new controller gain can be calculated from:

K = K_base /( 1 + D_t/T_i)

K = 0.5 /( 1 + 2.08/1.22)

K = 0.18

In Figure 9 we can see that the integral is still a little too slow, and by implication the controller gain is still a little too high. At this point we could reduce the integral another 25% to 0.92, at which point we would see that the integral is now too fast (and the controller gain too small). We would then split the difference, ending up with K = 0.17 and T_i = 1.07, which is very close to optimum.

A second example: Too little controller gain, too-fast integral

For our second example, I will use the same process but start with too little controller gain and integral set far too fast.

Our first impression of Figure 10 is of a controller tuned with far too much integral; the PV and OP peaks do not line up. As part of our normal data collection, we note that the deadtime is 2.08 minutes, and we estimate the baseline controller gain from the relative size of the PV and OP swings (this is an alternate approach for controllers with long persistent swings).

K_base = ΔOP/ΔPV = 9/18 = 0.5

The next thing we should note is the controller gain at 0.10 is considerably smaller than the baseline controller gain of 0.5. Our first thought should be that the controller gain is too small, however the large deadtime suggests that we may be working with a deadtime dominant process. This leaves us with a question: Do we increase the controller gain?

Given how close to instability this controller is cutting the speed of the integral in half (doubling the integral constant) is reasonable. Let’s set the new T_i = 0.60.

Let’s also calculate an estimated controller gain. Since at this point, we do not know that the process is deadtime dominant, we will use the method for estimating controller gain for lag dominant and moderate self-limiting processes (see PID spotlight part 9):

K = 0.5 * T_i * K_base / D_t

K = 0.5 * 0.60 * 0.5 / 2.08

K = 0.07

This is less than the current controller gain, and since we have reason to suspect that the controller gain is too small, we will not change controller gain.

In Figure 11, it looks like this is a deadtime dominant process. Furthermore, the controller OP is just about at its final value when the PV starts to move, which looks like we are pretty close to proper tuning for a deadtime dominant process (this occurred entirely by happy accident. This should not be expected.) However, the integral constant is still too fast based on the OP and PV overshoot. Now that we believe we are close we can use a more typical 50% increase in the integral constant to 0.90. Since we believe that we are dealing with a deadtime dominant process we will calculate the controller gain using the deadtime dominant shortcut method:

K = K_base /( 1 + D_t/T_i)

K = 0.5 /( 1 + 2.08/0.90)

K = 0.15

Figure 12 shows us that we still have too much integral. At this point we are also quite sure that we are working with a deadtime dominant process. From here, we would increase the integral another 25% to 1.13 and calculate a controller gain of 0.17. This is fairly close to optimum, at which point we would close out our tuning efforts.

Our two examples point out one of the oddities that can happen with heuristic tuning. The first example started with tuning constants calculated as the result of an open-loop step test. The constants were pretty close to correct, but needed some work to bring them to optimal. It took four adjustments to get to optimal tuning. The second example started with tuning constants that were far from optimal, and yet we got close to optimal tuning in three adjustments.

This is not unexpected. There is an element of luck in heuristic tuning. Experience also helps. As you gain experience you will move from always making 25% steps to picking step size based on your estimate that “It looks like we’re about this far away.”

Hints: Heuristic tuning tips

Deadtime dominant processes are difficult to tune because the optimal tuning window is small, and the stability margin is very small (unlike moderate and lag dominant processes). That said, heuristic tuning is still relatively safe provided you do not make large adjustments. Since we do know exactly what good tuning looks like we can calculate controller gain (K) or integral (T_i) once we make an educated guess at the other parameter and know that the resulting tuning constants will be stable (if not ideal).

Again, I can never repeat this advice enough: Keep a loop-tuning log.

More hints: Heuristic tuning limitations

Heuristic tuning can require multiple steps. If a control loop’s tuning is far off the mark it may be better to use open-loop tuning to get a first approximation and then use heuristics to finalize the tuning constants. If you are in a reasonably well-tuned facility then if you find you must retune a control loop, it is very likely that the existing tuning constants are not too far from optimum. It will be far quicker to use heuristics, especially if there is a recent SP change in the trends, to estimate new tuning constants.

A bad control valve will warp loop-tuning results. Specific to deadtime dominant processes a sticking valve will result in a PV limit cycle around the SP that you will not be able to eliminate.

 Tips for deadtime dominant processes: Control upstream, compensate

A PID controller has a limited ability to control disturbances to a deadtime-dominant process. Disturbances will always be fully expressed and persistent. If PID tuning is perfect, then a process disturbance will persist for one full deadtime period, and it will take another full deadtime period to eliminate the disturbance (the process will be off setpoint for a minimum of two full deadtime periods). If this is not acceptable you should explore:

• Eliminating process disturbances through proper control of upstream processes.

• Compensate for disturbances using feedforward control.

• Consider some form of deadtime compensation control. This cannot prevent unmeasured disturbances from being fully expressed and persistent, but can shorten the recovery time (the process will be off setpoint for one deadtime period, but not two).

Summary of heuristic tuning: Too much gain? Integral too low?

Relative to lag dominant and moderate processes deadtime dominant processes use different visual cues to determine when a controller may have too much controller gain or the integral is set too slow. Also, unlike lag dominant and moderate processes good tuning of deadtime dominant process is different; specifically, the controller gain is less than the baseline controller gain, and the controller output should be equal to the final controller output when the PV starts moving. Because of this constraint there is a shortcut method that can be used to speed tuning of a deadtime dominant process; once you have estimated the controller gain the integral can be calculated directly (or vice versa).

Published open- or closed-loop tuning methods may not identify optimum tuning constants for a deadtime dominant process, therefore heuristic testing will very likely be required to optimize the controller tuning.

Next steps: Integrating processes, near-integrating processes

This is the final installment on tuning self-limiting processes. Integrating processes are next (think level control, although there are plenty of other integrating processes). We will also talk about near-integrating processes: These are self-limiting processes that have very long time constants. For tuning purposes, we can treat them like integrating processes, which reduces tuning time by (reportedly) up to 90%. We will begin with the basics. The behavior of integrating processes will in some ways look very much like self-limiting processes, and in other ways is very different. These differences change the way we think about controller performance and tuning to achieve desired performance.

Ed Bullerdiek is a retired control engineer with 37 years of process control experience in petroleum refining and oil production. Edited by Mark T. Hoske, editor in chief, Control Engineering, WTWH Media, mhoske@wtwhmedia.com.

CONSIDER THIS

Open-loop, closed-loop and heuristic tuning methods are complimentary. How will having a working knowledge of the concepts behind all three methods speed and improve your tuning efforts?

ONLINE

PID series from Ed Bullerdiek, retired control engineer

Part 1: Three reasons to tune control loops: Safety, profit, energy efficiency

PID spotlight, part 2: Know these 13 terms, interactions

PID spotlight, part 3: How to select one of four process responses

PID spotlight, part 4: How to balance PID control for a self-limiting process

PID spotlight, part 5: What does good and bad controller tuning look like?

PID spotlight, part 6: Deadtime? How to boost controller performance anyway

PID spotlight, part 7: Open-loop tuning of a self-limiting process

PID spotlight, part 8: Closed-loop tuning for self-limiting processes

PID spotlight, part 9: Heuristic tuning for a self-limiting process (part A on heuristic tuning)

Aug. 1 RCEP webcast available for one year: How to automate series: The mechanics of loop tuning

More on PID and advanced process control from Control Engineering

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.