Fixing PID, Part 2
Proportional-integral-derivative controllers may be ubiquitous, but they’re not perfect.
Part 1 of this series (Control Engineering, Nov. 2012) looked at several issues that limit the performance of the theoretical PID algorithm in real-world applications of feedback control.
All of these problems are exacerbated by uncertainty. Sometimes the controller lacks sufficient information about the controlled process to know how much and how long to apply a control effort. Sometimes the controller can't even tell if it's done a good job or how to do a better job in the future when sensor placement, physical limitations of the sensing technology, or measurement noise make the process variable hard to measure.
Measurement noise is particularly troublesome for a PID controller's derivative action. To compute the "D" component of its next control effort, the controller computes the latest change in the error (the difference between the process variable and the setpoint) and multiplies that by the derivative gain or rate parameter.
When random electrical interference or other glitches in the sensor's output cause the controller to see fictitious changes in the process variable, the controller's derivative action increases or decreases unnecessarily. If the noise is particularly severe or the derivative gain is particularly high, the controller's subsequent chaotic control efforts may be not only unnecessary, but also damaging to the actuator and perhaps even to the controlled process itself.
The simplest solution to this problem is to reduce the derivative gain when measurement noise is high, but doing so limits its effectiveness. The measurement noise itself can sometimes be reduced by fixing the sensor or by filtering the process variable measurement mathematically. A process variable filter essentially averages the sensor's most recent outputs to produce a better estimate of the process variable's actual value.
However, process variable filters have their limitations. They only work if the measurement noise is truly random, sometimes increasing and sometimes decreasing the sensor's output in equal measure. If those positive and negative blips also occur with equal frequency, then the filter's averaging operation will tend to cancel them out. But if the measurement noise tends to skew the sensor's output consistently in one direction or the other, the filtered process variable will tend to run consistently too high or too low, thereby deceiving the controller into working too hard or too little.
A process variable filter also slows the controller's reaction time. If the filter is configured to average a particularly long sequence of sensor outputs, it will do a better job of cancelling out random blips, but it will also tend to miss the most recent changes in the actual process variable. The filter needs to see a sustained change in the sensor's output before it can report a new value of the process variable to the controller. The controller can't even see, let alone react to rapid, short-term changes in the process variable, as discussed in the "Filtering" section below.
As a compromise, some PID controllers can be configured to filter the process variable to differing degrees when computing the proportional, integral, and derivative actions. The derivative action requires the most filtering since that's where measurement noise causes the most problems. The proportional action may benefit from less filtering (that is, a filter incorporating a shorter sequence of sensor outputs) in order to remain responsive to short-term changes in the process variable. And since the integral action itself serves as a filter, it may require no process variable filtering at all.
Alternately, a filter can be applied to the control effort instead of the process variable. Doing so permits the measurement noise to enter into the PID calculations (especially the "D"), but the noisy control effort that results is smoothed by the filter before reaching the actuator. A filter can also help slow down the control effort to prevent overly dramatic fluctuations in the process's behavior in cases where the process is particularly sensitive to the actuator's movements.
On the other hand, a filter on the control effort can make the process appear more sluggish than it really is. An operator looking for faster closed-loop performance might try re-tuning the controller to be more aggressive without realizing that the problem is the damping effect of the filter, not the process. The controller tuning and the control effort filter sometimes end up battling each other unnecessarily when different operators have implemented one without checking for the other.
The effects of measurement noise can also be mitigated by simply ignoring insignificant changes in the sensor's output under the assumption that they're probably just artifacts of the measurement noise and are too small to make a difference in the controller's choice of control efforts anyway. So long as the error between the process variable and the setpoint remains within a range known as the deadband, the controller simply does nothing.
The trick is determining how much of a change in the error is small enough to ignore. If the deadband is set too large, significant changes in the behavior of the process may be overlooked. But if it is set too small, the controller will react unnecessarily to every fictitious blip in the sensor's output, even if the actual process variable has already reached the setpoint.
Unfortunately, a deadband also glosses over small changes in the setpoint. If an operator tries to move the process into a higher or lower operating range that falls within the current deadband, the resulting change in the error will be ignored and the controller will do nothing. If the deadband is too large, the controller's precision will suffer. That is, it may be able to make a refrigerated space five degrees colder, but not just one.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.