What Are Some Ways to Improve and Prioritize Feedforward and Fast Feedback Control?

The following technical discussion is part of an occasional series showcasing the ISA Mentor Program, authored by Greg McMillan, industry consultant, author of numerous process control books, 2010 ISA Life Achievement Award recipient, and retired Senior Fellow from Solutia, Inc. (now Eastman Chemical). Greg will be posting questions and responses from the ISA Mentor Program, with contributions from program participants.

Matthew Howard is the only process system engineer in a large pulp mill with a recovery boiler, two hog boilers, and a Kamyr digester with five-stage bleach plant and pulp machines. He has spearheaded alarm management and the use of lambda tuning methods at his organization. 

Matthew Howard’s Questions

1. After implementing feedforward (FF) control on a system, it is usually necessary to add some feedback trim. What is the most efficient way to tune the feedback (FB) portion of a FF/FB control scheme? I have always struggled with this—I end up doing lambda tuning, but then I keep slowing down lambda until I don’t see an interaction between the FF and FB tuning. It can take a long time if the process is slow.

2. In a time of low capital budgets and a never-ending desire of the business for continuous improvement, my small group is swamped with “controls-only” improvement project requests. What is an effective way to prioritize these many opportunities and figure out which ones we should work on? I support three major departments, each with a robust list of wants.

3. What is the best way to tune a PID on self-regulatory loop that has a faster open loop time constant than the minimum reset time of the PID block in a controller? I have been using lambda tuning methods, and have found this problem many times. I’ve just been putting in the minimum reset time instead of the appropriate value. (Maybe more general: what is the effect of controller execution time on the tuning of feedback control loops?)

Greg McMillan’s Answers

1. Unless the FF is used for decoupling or the disturbance is on the process output rather as a process input, interaction between FB and FF is likely to be caused by FF dynamic compensation that is not quite right, causing the FF signal to arrive sooner or later than when the actual disturbance arrives at the same point in the process. Most disruptive is a FF correction that arrives too soon, causing inverse response. Also disruptive is a correction that arrives so late—or a correction that is so much larger than required—that it causes a second disturbance.

Dynamic compensation is not easy, and many tuning packages are not readily set up to easily detail the FF gain and lead-lag settings. With the PID in manual, separate tests are done where the feedforward disturbance variable and PID output are stepped to identify the gain, dead time, and time constant in the percent process variable (PV) response to the percent change in the feedforward disturbance variable and the percent PID output.

The feedforward lag is normally set equal to the lag time constant in the PV response to the disturbance and the feedforward lead is normally set equal to the lag time constant of the PV response to the PID output. The lag time should be at least 1/10 of the lead time to prevent erratic action. The feedforward dead time is the disturbance response dead time minus the PID output response deadtime. The feedforward gain is simply the ratio of the dimensionless gain of the PV response to disturbance variable divided by the dimensionless gain of the PV response to PID output. (This assumes that the feedforward scale was set properly.)

Also, feedforward implementation methods vary from one supplier to another. Careful testing is necessary, starting with a very low feedforward gain. To allow for unknowns and nonlinearities, I normally don’t exceed about 80% of the maximum FF gain identified. If there is interaction between loops, the ratio of the PID closed loop time constants or arrest times should be at least five, to reduce interaction. I would normally tune the FB loop first to deal with disturbances, which—for load disturbances on the process input—are tested by momentarily putting PID in manual and making a step change in output, quickly returning the PID to automatic.

If there are some auxiliary disturbances that coincide with the one addressed by the FF, seek to develop a separate FF signal for them. If the primary disturbance arrives on the process output, then the tuning should be done for a setpoint change. I would normally start with a FF gain that is 0.1 times maximum FF gain and increase it in 0.1 steps toward 0.8 times the maximum FF gain and check if FB gain should be decreased about halfway to the maximum. For more guidance, see the Control Talk column “A straightforward explanation of feedforward control.”

2. I would go with the improvements that are “quick hits” or “quick wins” that are suspected as being significant contributors to variability, and that can be addressed by changes in control system design and tuning. The statistical methods that can be used to identify possible improvements can be found in the Control Talk column “Methods for improving process performance and assessing productivity.”

In some cases, better valves or measurements may need to be installed to reduce variability caused by poor valve precision and measurement repeatability. Some measurements may also need to be installed to provide FF signals that are particularly important for self-regulating processes where the open loop time constant is small compared to the total loop dead time.

3. The biggest dead time from controller execution time or scan time or transmitter update time is the summation of ½ of each of these times, assuming the worst-case scenario of them being executed in series. If the control module is complex and the actual signal to the control valve is delayed, the additional time (called latency) and its full value should be added to the total loop dead time.

All significant sources of total loop dead time should be decreased. If the open loop time constant is less than ¼ the total loop dead time, we have a dead time dominant loop that is best improved by reducing total loop dead time from the automation system delay, process transport delay, and valve response, and by the use of FF signals. Whatever the minimum reset time is, I would make sure that it is in the numerator for lambda tuning equation for the controller gain. Normally, I like to limit the reset time to be not less than ¼ the total loop dead time, so that substitution into the lambda equation results in a larger controller gain, and thus more proportional action—which is beneficial for dealing with load disturbances and reducing the amplitude of limit cycles from backlash. The controller execution time should not be greater than ¼ the reset time, which may further restrain how low you can go in reset time.

Michel Ruel’s Answers

1. Feedback and feedforward: Let’s begin with feedback only (feedforward not enabled or feedforward gain set to zero (K_ff=0) … You tune the loop normally using the method of your choice. The lambda tuning method is very convenient for SP changes but often too sluggish for load rejection.

Once the loop is properly tuned, you can add feedforward using modeling if you need to add dynamic compensation or simple observation if you do not add dynamic compensation. Indeed, with many loops, the process dynamic and load dynamic is similar and only static feedforward (a simple multiplier with bias) is needed. If so, observe the feedback response over a certain period of time and you can calculate the feedforward gain to use to compensate a load change. You observe how much the valve has to be moved after a load change to bring back the PV at SP.

If you need dynamic compensation, you will have to model the load model.

2. An interesting question. Some quick wins are generating savings, reducing raw material, and simplifying operators’ tasks.

Commence your journey with simple projects where you will be able to calculate the value. Ask before starting a project how you will calculate the benefits. (Success has many fathers but failure is an orphan, as the saying goes.) Calculate return on investment and present your method before starting the process.

3. I agree with Greg’s answer, and will add that I found lambda tuning numbers quite confusing. With lambda tuning, reset time is based on time constant—and with a dominant dead time process, the time constant could be quite small.

Remember, lambda tuning is well-suited for SP changes. On the other hand, with load rejection tuning methods (you can find probably more than one hundred!), reset time is based on dead time. You will obtain very different results using one or the other. Very simply, if your time constant is quite small, with lambda tuning, you will calculate a small controller proportional mode gain (K_c) and a small reset time (T_i), which is a larger integral gain (K_i). In fact, with stiction, this is problematic—since the controller output will “ramp” in lieu of moving on a load change. If you use a load rejection method, you will calculate a larger controller gain and a larger integral time (a smaller integral gain)… grosso modo, you can for a certain range maintain the product (K_c * K_i) similarly and get similar results.

For example:

K_c=0.1 K_i=60 repeats per minute (T_i = 1s) is similar

to K_c=0.5 K_i=12 repeats per minute (T_i = 5s) also similar

to K_c=0.05 K_i=120 repeats per minute (T_i=0.5s)