Help Settle a PID argument

this must be a perennial PID debate, one engineer wants to low-pass filter the control output of a PID controller, using a time constant of
5-10 times the PID update rate, in order to 'smooth' the control output. The other engineer claims this is pointless, as the low pass transfer function can be folded into the PID transfer function by just changing the PID settings, without adding a LP filter.
Who's 'right'? Is there any benefit to LP filtering a PID output that cannot be otherwise derived with changing the PID parameters?
tia!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The other engineer

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
To clarify. If you low-pass filter the control output of a PID controller all you are doing is introducing a lag into the process. That will Not improve the control, it can only make it worse. Tuning the controller right is the answer, not crippling it.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

Normally, if filtering is added, it is put between the process variable and the controller input. But in general, adding a low pass filter in the loop degrades the control response if it does anything. The exception is if it averages peaks enough to prevent output saturation, and thus, improve the linearity of the system. Such filtering can often be used with little degradation if the filter time constant is much shorter then the closed loop dominant time constant.
For instance, I have added process variable filtering on the order of a minute to smooth the electrical white noise and quantization noise of temperature transmitters in high gain (on the order of 200) closed loops that have dominant time constants of approximately 20 minutes. Without the filter, the control response is essentially the same, but the output bounces around so much that it not only hits max and zero quite often, it is very difficult to look at a (sampled) trend of the output and guess what its average value is. And if the operator puts the loop in manual, the output can be frozen at almost any value which can lead to the temperature heading almost anywhere. So, in this case, the slight degradation of the loop response time is paid for by a more steady controller output.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Adding a LP at the output of PID is rare.
That being said, if the process requires that the PID output be "smooth", for example, if the process being controlled has the requirement of delta_control <= detal_max, then a rate limiter can be added at the output of the standard PID output. But often this "rate" limiter is implemented as part of the PID controller. It becomes more complicated with stuff like anti-windup with the introduction of any kind of limiter.
glu

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
glu wrote:

The type of controller that http://users.rcn.com/jyavins/servo.html roughly describes has both an inherent rate limit and a short time constant. It's a simple idea that has made me look good since my analog days.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Great article.
But I fail to comprehend why IPD will outperform PID for 1st order and/or 2nd order servo. If PID here refers to the standard PID formula without all the anti-windup handling (zeroing integral is only one rudimentary way of handling windup) techniques applied, then I can see IPD as described will do better. But a properly designed PID will match IPD performance in any theoretical and/or practical terms (such as bang-bang for large error, bump-less transfer between manual and auto etc) for 1st/2nd order systems.
glu

"smooth",
output
as
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
glu wrote:

By the time you add all that, you end up with the same performance but with more complexity. I've built what I call IPD with a few-op amps and diodes (plus resistors and a capacitor, of course). To get that level of performance with PID, you need a lot of IF ... ELSE and CASE statements. IPD software's simplicity makes it easier to debug and tune.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
A IPD does not out perform a PID in motion applications were the set point or target is ramped smoothly from one point to another. If you want a higher bandwidth then all the PID gains should be in the forward path. If you want a PID that responds nicely to steps in the setpoint or setpoints that are noisey then use the I-PD that Jerry mentions. Our motion controller use both the PID and I-PD depending on the application. Notice I call IPD I-PD because the P and D terms are in the feedback path only. The fact that only the integrator term is in the forward path means the I-PD does not add zeros to the close loop transfer function. You can see below that the PID adds zeros to the closed loop transfer function. It is the zeros that make CLTF respond much better to high frequency motion profiles. However, it is also the zero that make the system jerk violently to step jumps in the set point.
A comparison of PID, PI-D and I-PD forms of PID. ftp://ftp.deltacompsys.com/public/mcd/T0C1%20Bode.htm
There is no perfect PID for all applications. A properly implement PID is very clean and simple. I prefer the incremental or velocity form of PID as it handles saturation well.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rockwell motion controllers have low pass filters on the output. Motion profiles are normally about 5 to 10 Hz. The sampe rate is 1000 to 2000 hz. A low pass filter at the geometric mean works well because it has little effect on the control.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The rate limiter is a bad idea. I makes the system non-linear.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
It's only a bad idea if you don't or don't know how to implement your PID with the rate limiter in the equation.
glu

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

It depends on your situation. If you have implemented the D term with a roll-off then you most likely don't need an extra one. If you have spectacularly noisy data you may need it, however.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
PID output is a function of the input. If your input has inbuilt disturbances that are faster changing than the actual process variable then you should fix that first. If you cant, then don't even worry about PID, Just have an open loop controller.
If you want to go fancy and have the time, you can write a routine to load different sets of PID parameters depending on the Rate of process variable change every scan time. If it's below XX use P.I.D = x,x,x, if it's > XX, use different parameters.
OR better, Instead of executing the PID every scan, make it manually initiated and execute on a timer. Make the timer set value a function of rate of input change.
I hope the above helps

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
PIDs are in theory linear, so it does not matter whether you filter the input or the output. In practice, filtering the input is better, as it aggravates the PID less, and you are less likely to cause non-ideal behaviour.
A low-pass filter of the input (or the output) means essentially low-pass filtering of the derivative action:
K*(1 + 1/(Ti*s) + Td*s)/(Tf*s + 1)
is the same as
k*(1 + 1/(ti*s) + td*s/(Tf*s + 1))
if k = K/(Ti - Tf)/Ti, ti = Ti - Tf, and td = Ti*Td/(Ti - Tf).
Filtering the derivative action is essential in a PID, and the filtering time constant Tf is an important design parameter. Tf can, for example, be chosen (together with the derivative time) using a so called lead-filter design, where you place the maximal phase lead at a frequency where you need it. An ideal PID places the maximal phase lead at infinite frequency, which is, to put it mildly, not the best of choices. This is probably the main reason why derivative action is considered less useful than it actually is.
All real-world implementations of a PID do already include some low-pass filtering of the D-action, simply because ideal D-action cannot be implemented. The filtering time constant it is not always known, and actually choosing it yourself is a step in the right direction.
To conclude with an answer to the original question: - For a PID you need filtering of the derivative action, which can be obtained using low pass filtering of the input or the output. Note that you when doing so also change the proportional and the integral actions, see the equations above. Note also that your implementation might already include some a priori chosen low-pass filtering, Tf = Td/10 is a typical choice in digital PIDs. - For a PI (or a P), you use low pass filtering for measurement filtering, so low pass filtering of the output does not make any sense.
Jari Bling

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

No. This is not a perennial debate, because low-pass filtering of the controller output is usually inherent within the relatively slow dynamic responses of the actuator and/or process being controlled. The question therefore (almost) never arises. Kelvin B. Hales Kelvin Hales Associates Limited Consulting Process Control Engineers Web: www.khace.com
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

Since you have mentioned "PID update rate" I will assume a sampled data system. There really is no good reason to filter the output of continuous time system unless it is to rate limit it and that is better handled at the input. As to the sampled data system, the stepping of the outputs will act as an impulse disturbance which may excite high frequency/high Q modes. In this case a low pass filter may help, however it will cause some loss of phase margin.
So the correct answer is: "It Depends"
--
jeff


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
jeff wrote:

Any properly conceived sampled-data system with analog output will include a reconstruction filter. While that is in fact a low-pass filter, limiting the frequencies in the output to the Nyquist rate, we don't ordinarily think of it as such. What it removes are artifacts of the sampling process. What most people mean by a low-pass filter removes more than that.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.