Full throttle batch and startup response

Improvements in practices for starting up a loop with a large process time constant, or slow ramp time compared to the dead time, can save 25% or more in batch cycle and startup time. Read how.

2 of 2 1 | 2 > View on one page

For integrating and runaway responses, the process variable won’t go anywhere until the valve is positioned beyond its FRV. This leads to Practice 4, in which the valve is set to an extreme position allowed by the process to give the fastest approach to set point. Next, the brakes are slammed on, so the process variable doesn’t run over the set point. It’s kind of like driving in Italy. The question is when do you hit those brakes?

The Wait
Short of having an Italian taxi driver operate your loop, what can be done to get the loop to its destination the fastest way possible?

The plot for Practice 4 shows the response for a technique briefly described in “Peak Concerns,” Control Talk, CONTROL, April ’05. The rate of change is computed from the change in the process variable (PV) over a time large enough to get a good signal-to-noise ratio. The old value of the PV, created by passing the PV through a dead time block, is subtracted from the new PV. The Δ PV is divided by the block dead time to create a rate of change. The rate of change multiplied by the process dead time is then the predicted change in the PV that, when added to the new PV, is the predicted end point shown in Equation 1. When the end point equals or exceeds the final set point, the controller output is switched from maximum throttle to its FRV. It’s held at this FRV for one process dead time, and is then released for feedback control. This method compensates for nonlinearities and disturbances that are evident when it’s time to hit the brakes.

PVf = [(PVn – PVo) / DT] * td + PVn

PVf  = predicted PV one dead time into the future (%)
PVn = new PV (%)
PVo = old PV (output of dead time block) (%)
DT = DT block dead time (sec)
td= total loop dead time (sec)

If the process dead time is underestimated, the loop will overshoot the set point. Therefore, it’s important to be generous in the dead time estimate. It’s especially important the dead time not be too short for zero-load integrating process (as described in the “Peak Concerns” column), where the FRV is zero and there’s nothing to bring back the process variable to set point. Also, a safety margin should be added to the dead time estimate for runaway processes since the process is accelerating.

Without Dead Time I’d Be Jobless
If the loop dead time is zero, the loop could switch to the FRV when the PV reached set point. Furthermore, the sky’s the limit for the controller gain, and feedback action could provide instantaneous correction. My lifestyle is largely the result of dead time. A better term than process dead time is “total-loop dead time” because there are many sources of dead time outside the process.

The biggest source of slow ramp times and process time constants is measurement and valve resolution. The time it takes for the change to get through the resolution limit is dead time. Dead time from the measurement and valve resolution are inversely proportional to the rate of change of the process variable and controller output, respectively. Consequently, for closed-loop tests, identified dead time depends on the controller tuning and size of the set point’s change. Fortunately, changes in valve position are quite large, and dead time from resolution is minimal for the optimal switching method described in Practice 4.

Other sources of instrument dead time include measurement transportation delay, sensor lags, transmitter dampening, analog and digital filters, module execution time, valve dead band, and actuator pre-stroke dead time.

An adaptive controller can identify the total-loop dead time accurately, if the trigger point, in terms of output changes, are large enough. Note that the ultimate proof of the pudding is the output change, rather than the set point change, because it includes the effect of tuning, and is ultimately what’s driving the process. Given the measurement and valve resolution, the adaptive controller, with its knowledge of the integrating process gain, can correct the observed dead time to give a value closer to the output changes associated with the optimal switching. For a 12-bit A/D and 1 sign bit, the measurement resolution is 1 in 11 bits, or about 0.05% of span. Consequently, large temperature spans from using multiplexed I/O instead of dedicated transmitters are a major source of dead time in reactor temperature loops. The valve resolution can vary from 0.1% for a sliding stem valve with a digital positioner to 10% for a ball valve with high friction packing and no positioner. Since valve resolution caused many failures of adaptive controllers, newer technologies identify the valve resolution online. A digital positioner can give a position reading back to the control system to make this identification much faster.

An adaptive controller also can identify the integrating process gain. This can be used with the current ramp rate and the pre-positioned extreme controller output to estimate the FRV in Equation 2. Note that, if the extreme output (OUTx) is less than the FRV, the signs of each expression are reversed to get a positive FRV. Of course, limits should be enforced on the calculated value and it may be desirable to use a portion of the difference between the calculated FRV and the last captured FRV added to the last captured FRV to estimate the new FRV. For primary loops in a cascade control system, the extreme output must match up with the set point limits of the secondary loop and the FRV is a set point of the secondary loop. It’s necessary to keep the units of the process variable and output and the process integrating gain consistent. If process integrating gain is in %/sec/%, the process variable and output must both be in %. For integrating processes and OUTx > FRV:

FRV = OUTx – [(PVn – PVo) / DT] / Ki

FRV = final resting value (%)
Ki = integrating process gain (%/sec/%)
OUTx = output at extreme allowed by process (%)
PVn = new PV (%)
PVo  = old PV (output of dead time block) (%)
DT = DT block dead time (sec)

With a little ingenuity, similar equations can be developed for estimating the FRV of self-regulating and runaway processes based on an identified process gain. These equations can be put online in the observation mode to see how well they estimate the FRV before it’s actually used for Practice 4. If the FRV is too variable and can’t be accurately captured or calculated, it’s best to revert back to Practice 2. Practice 2 depends more heavily on the controller’s tuning and in particular on the relative amount of proportional and reset action because the tuning is responsible, not just for correcting the FRV, but for taking the output all the way from its extreme to the FRV. It’s important that gain dominates reset action in the approach to set point. Proportional action must kick the output to the allowable extreme, and then back it off as the PV approaches set point, despite the effect of reset action, which works to force the output to its limit until the PV crosses set point.

Optimal Switching
This graph demonstrates the operations of a module for optimal switching in Practice 4.

Next Destination
The optimal switching technique based on rate of change of the PV is ideally suited for an integrating or ramping process, but works well for self-regulating and runaway processes, where the fastest possible approach to set point is desired. For runaway processes, the dead time used for prediction should be increased since the PV is accelerating. These and other process control techniques can save 25% or more in batch cycle and startup time. Generosity in the dead time estimate is rewarded by helping you get to your next destination, which just might  be happy hour.


  About the Author
Greg McMillanGreg McMillan is a CONTROL columnist and Process Automation Hall of Fame inductee. He is retired from Monsanto and is a prolific author on process automation. He can be reached at gkmcmi@austin.rr.com.
2 of 2 1 | 2 > View on one page

Join the discussion

We welcome your thoughtful comments. Please comply with our Community rules.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • Thanks for enunciating what I've been trying to tell my husband when I control the climate knob in the car. The Italian taxi driver analogy is perfect! Thanks.


RSS feed for comments on this page | RSS feed for all comments