# 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.

05/08/2006

1 vote
Text size: - +

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.

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

Where:
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:

1 vote