Forums

PID Control programming Questions

Started by RogerN September 27, 2013
On Sat, 28 Sep 2013 19:34:21 -0500, the renowned Tim Wescott
<tim@seemywebsite.please> wrote:

>On Fri, 27 Sep 2013 19:40:07 -0700, Don Y wrote: > >> At all times, you want to be sure you aren't asking your controller to >> do more than is possible (i.e., if the output is "at its limits", AT ANY >> INSTANT then the loop is probably in trouble). > >I have not found this to be the case in practice. Particularly with >motion control loops going from point A to point B, if you design your >anti-windup logic correctly you can be at the rails at various spots in >the trajectory and be fine.
Sure, to expand on Tim's example, consider a temperature control loop. Normally the output will be at its limit for a considerable time during start-up. A badly implemented controller can overshoot like crazy, but the solution isn't to put a megawatt heater in there for something that requires a kW steady-state, it's to fix the controller-- meaning it's no longer a textbook PID, but has some barnacles such as Tim mentions below.
>Even with fairly primitive anti-windup, you can often have the output at >the rail for a small part of the trajectory without undue problems.
Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
"Tim Wescott" <tim@seemywebsite.please> wrote in message
news:UvydncxdEOV769rPnZ2dnUVZ_qydnZ2d@giganews.com...
> On Fri, 27 Sep 2013 19:19:53 -0500, RogerN wrote: > >> I have a program being ran every 20 milliseconds and I'm trying to >> implement PID control. So P = SetPoint - Actual, I = I + P ? , and D = >> P - Old_P???? On D, should "Old_P" be from the previous round or should >> it be a value from a certain length of time ago? Also, is "I" just >> summed up or is it the sum of I over a certain length of time? >> >> I'm trying to find out if I need to set up arrays to accumulate 50 >> samples per second of time for setting I and D values. Also, are Kp, >> Ki, and Kd just multipliers? I can calculate a value for I and D each >> scan to scan but it seems like it could be more stable if I use a time >> period that fights the process's oscillation period. >> >> RogerN > > You've gotten lots of good answers. Doing PID control "right" takes a > lot of knowledge, but doing it "kinda right" is often more than enough > and doesn't take a lot at all. > > Unfortunately, if you don't have much control smarts you don't always > have the tools to know if "kinda right" is going to be good enough > without giving it a whirl. > > Try reading this: > > http://www.embedded.com/design/prototyping-and-development/4211211/PID- > without-a-PhD > > I'm going to have to put this up on my website: it seems like they're > changing the link on a monthly basis these days. > > It kinda-sorta contradicts things that Bruce and Spehro said. That's > because I'm 100% right and they're a couple of -- uh wait. That's > because there's a lot of different ways to skin this particular cat. I > hope my article helps. > > -- > Tim Wescott > Control system and signal processing consulting > www.wescottdesign.com
Yes, that is indeed a good article. One point in it noted, and Tim is quite correct, if you do use derivative it's good to derive it from the measurement input rather than the error signal, so that you don't get large output spikes when the setpoint is changed (often in steps). In fact, it's sometimes good to have the *proportional* treated in this way as well, so that when a target change is made, the controller ramps to the new state at the integral time rate. Very applicable in process plants to keep operators happy, not so good if you're working with missile control. Expanding a bit on derivative, industrial system algos generally used what's referred to as 'filtered derivative'. It's derived by applying a filter to the input (measurement or error as above), then subtracting the filter output from the filter input. The result is then multiplied by an arbitrary constant (typ 4 - 6) and this is the derivative term. It has the advantage over classical forms that if there's an 'infinitely fast' change in the input, the change in the output isn't 'infinitely' great.
On Sun, 29 Sep 2013 14:22:17 +0800, Bruce Varley wrote:

> "Tim Wescott" <tim@seemywebsite.please> wrote in message > news:UvydncxdEOV769rPnZ2dnUVZ_qydnZ2d@giganews.com... >> On Fri, 27 Sep 2013 19:19:53 -0500, RogerN wrote: >> >>> I have a program being ran every 20 milliseconds and I'm trying to >>> implement PID control. So P = SetPoint - Actual, I = I + P ? , and D >>> = P - Old_P???? On D, should "Old_P" be from the previous round or >>> should it be a value from a certain length of time ago? Also, is "I" >>> just summed up or is it the sum of I over a certain length of time? >>> >>> I'm trying to find out if I need to set up arrays to accumulate 50 >>> samples per second of time for setting I and D values. Also, are Kp, >>> Ki, and Kd just multipliers? I can calculate a value for I and D each >>> scan to scan but it seems like it could be more stable if I use a time >>> period that fights the process's oscillation period. >>> >>> RogerN >> >> You've gotten lots of good answers. Doing PID control "right" takes a >> lot of knowledge, but doing it "kinda right" is often more than enough >> and doesn't take a lot at all. >> >> Unfortunately, if you don't have much control smarts you don't always >> have the tools to know if "kinda right" is going to be good enough >> without giving it a whirl. >> >> Try reading this: >> >> http://www.embedded.com/design/prototyping-and-development/4211211/PID- >> without-a-PhD >> >> I'm going to have to put this up on my website: it seems like they're >> changing the link on a monthly basis these days. >> >> It kinda-sorta contradicts things that Bruce and Spehro said. That's >> because I'm 100% right and they're a couple of -- uh wait. That's >> because there's a lot of different ways to skin this particular cat. I >> hope my article helps. >> >> -- >> Tim Wescott Control system and signal processing consulting >> www.wescottdesign.com > > Yes, that is indeed a good article. One point in it noted, and Tim is > quite correct, if you do use derivative it's good to derive it from the > measurement input rather than the error signal, so that you don't get > large output spikes when the setpoint is changed (often in steps). In > fact, it's sometimes good to have the *proportional* treated in this way > as well, so that when a target change is made, the controller ramps to > the new state at the integral time rate. Very applicable in process > plants to keep operators happy, not so good if you're working with > missile control.
Yes, I would have mentioned having the proportional run off of just the process output -- but I had a 5000 word limit, which I ran over and had to edit down to. I think that article had over 4900 words in it.
> Expanding a bit on derivative, industrial system algos generally used > what's referred to as 'filtered derivative'. It's derived by applying a > filter to the input (measurement or error as above), then subtracting > the filter output from the filter input. The result is then multiplied > by an arbitrary constant (typ 4 - 6) and this is the derivative term. It > has the advantage over classical forms that if there's an 'infinitely > fast' change in the input, the change in the output isn't 'infinitely' > great.
Also known as bandlimited derivative. I don't know if I mention it in the article -- I do in a related talk, but the talk has changed so many times over the years I couldn't say what's been said when. Using a "naked" derivative term in a controller that's being sampled significantly slower than the desired bandwidth can also cause high frequency oscillations. This is highly dependent on the plant, of course, but bandlimiting the derivative can allow you to use higher derivative gains and keep the system stable. Using a "naked" derivative term also causes problems if you have measurement noise -- noise is, by nature, broad-band, and derivative action, by nature, amplifies the high frequency. Put measurement noise and derivative together and you can get a control output that has so much noise that the desired control output is lost. All in all, derivative control is something best approached with caution, and the right tools. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com