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