How can we provide Mechanical and Process Engineering Regulatory Control Guidance Tips (Part 2)?
In part 2 we evaluate a misleading statement about the amount of derivative to use and provide some better guidance. We take a look at how mechanical and process design and operating conditions affect the need for derivative action. We offer a case where the increased need for derivative can be symptomatic of deterioration in equipment, instrumentation, or valve performance. We provide views from 3 industry experts. We finish with possible reasons why some plants won't use the derivative mode.
In the Hydrocarbon Processing Oct 2012 article titled "Why don't we properly train control engineers", the author asks "Do I know that applying derivative action can greatly improve controller performance if the process deadtime is large compared to the lag time?".
In my experience as the deadtime to time constant (lag time) ratio increased and the process became more deadtime dominant, rate time needed to be decreased because of the more abrupt response for a first order plus deadtime process. In the extreme where there is nearly all deadtime and very little lag time, the response is nearly vertical, and any oscillation appears as a square wave. Taking the derivative of a square wave even with the built-in derivative filter severely bumps the output, which seems contradictory to the need to prevent MV overshoot stated in the same article. Maybe the author has greatly decreased the controller gain to reduce MV overshoot creating a situation where derivative would help. Without particulars as to the deadtime to time constant ratio and tuning settings used relative to the settings possible for maximum performance, it is difficult to see the merit behind what seems to be a misleading statement. Let's briefly review expertise on the use of derivative.
On page 159 of Shinskey's Feedback Controllers ... book, the rate time approaches zero as the time constant to deadtime ratio approaches zero in the equation for a PIDn on a self-regulating process if there is no secondary lag.
Now if most of the deadtime in a first order approximation is due to a secondary lag, then an increase in the approximated deadtime could justify an increase in derivative. The secondary lag can be artificially introduced by the addition of a signal filter. While the use of such a filter can seem as if control is improved, the additional lag delays the ability of the controller to react to unmeasured disturbances and gives an attenuated view of the real world. You are often fooling yourself by adding a large filter to enable the use of more derivative action. The exception is the filtering of A/D noise in the 1980s vintage DCS from the use of wide range 12 bit thermocouple input cards instead transmitters.
Coatings and low velocities on heat transfer surfaces, thermowells, and electrodes can add a large secondary lag. Thus the increased need for derivative action can be mitigated by higher velocities that increase the heat and mass transfer coefficient and reduce fouling rate. For cooling systems, this translates to use of a recirculation system for coolant and throttling the make-up cooling water rather than throttling the jacket or coil flow. For batch crystallizers, it means an intelligent cooling profile to limit cooling rate at the beginning to avoid the formation of small crystals on the cooling surfaces. For pH electrodes, it corresponds to installing the electrodes in a pipeline with a 5 to 7 fps velocity rather than a vessel where even the highest agitation provides a bulk velocity of less than 1 fps. The need for an increase in rate time can be a diagnostic for decreased velocity and increased coating.
If an on-off valve is posing as a control valve as described in the Oct 2012 Control Article "Is Your Control Valve an Imposter", the use of derivative action can help the controller get through the backlash and stiction. Coating of the valve stem and internals can also cause stiction. The additional deadtime is the deadband from backlash or the resolution limit from stiction, whichever is largest, divided by the rate of change of the controller output. For step response tests and for significant derivative action, this additional deadtime is not seen. Thus, derivative can help deal with valve problems.
The rate time should be increased by 60% and 70% of the secondary lag for self-regulating and integrating processes, respectively for the ISA form PID. Processes where the open response ramps (integrating processes) (e.g. batch processes) are particularly sensitive to secondary lags. The situation is even worse if the open loop process response accelerates. For an open loop unstable process (e.g. runaway reaction), the maximum controller gain approaches the minimum closing the window of allowable controller gains as the secondary lag approaches the positive feedback time constant. Derivative action is essential to compensate for heat transfer lags.
I summarized my response to 3 industry experts Greg Shinskey, Michel Ruel, and Jacques Smuts and asked what they thought about the indication in the article that the benefit from derivative is greatest if the deadtime to time constant ratio is large.
Greg Shinskey said "I'm satisfied with your response--derivative is most effective on multi-lag processes like heat transfer, certainly not deadtime-dominant processes."
Michel Ruel offered the following points:
"Derivative uses the actual trends to anticipate future... in other words, derivative generates a signal based on actual trend. Indeed, you need to observe a trend to anticipate; a dead time produced by a series of small time constant is a good example."
"In the frequency domain, a series of time constant will look similar to a dead time (steep phase shift but no amplitude reduction) but the largest of small time constant will produces not only a phase shift but also an amplitude reduction; derivative will compensate for the phase shift & the amplitude reduction."
"Derivative is especially useful when dead time is in fact produced by a series of small time constants; using a derivative time equals to the largest of those small time constants will make it disappear. A good example is a temperature loop: with no thermowell, let's say that dead time is 1 minute but with a thermowell (30 sec time constant) dead time appears as 1.5 minute; using a derivative of 30 sec will annihilate the time constant and the PV "seen" in the Series Form PID algorithm will be what the PID would see without thermowell."
"With pure dead time, there is nothing to anticipate so derivative is not a good idea"
Jacques Smuts offered the following in the September 2012 Control Talk Column "Control Loop Improvement" when asked about the use of derivative action.
"The benefit of derivative diminishes as the total loop deadtime becomes greater than the open loop time constant. For derivative to be effective the process response must predictably be in the same direction for at least as long as the derivative time. The improvement offered by derivative is evident, but not dramatic for most processes."
I have heard technicians at some very large plants say derivative action is outlawed. While I think this is generally wrong, I can sympathize with possible bad experiences and marginal benefits. Reasons that may have led to extreme displeasure with derivative are:
- Measurement noise was amplified because there was no built-in derivative filter
- Disconcerting bump occurred for a change in setpoint because the PID structure had "Derivative on Error" and there was no setpoint filter or setpoint rate limit (the bump becomes a spike if there is no built-in derivative filter)
- The A/D steps from poor resolution DCS thermocouple cards were amplified
- The controller gain was so large on large lag and integrating processes and the secondary lags were so small, extremely tight control did not require a 3rd tuning knob
- Control valves were worn out from excessive dither caused by derivative action
- Rate time was inadvertently set larger than reset time causing instability when the PID went from a Series Form to ISA Standard Form in a migration project
Next week we continue to address the question with the start of a list of "What Every Engineer Should Know about Process Control"