Post by thread:PID control

Mike Sunners <spam_OUTmikesTakeThisOuTCAA.ORG.AU> wrote: > Andy, can you tell us what PID is, or give a text reference? PID is a standard type of closed loop control system. Let's take as an example a mechanical positioning system. You have a desired position and a sensor that provides feedback of the current poition. You need to generate a control signal to the positioner to control its velocity (including its direction). The difference between the current position and the desired position is called the error. The control signal is computed as the weighted sum of three terms derived from the error: P: Proportional to the error I: Integral of the error D: Derivative of the error Perhaps someone more knowlegeable than I will be able to explain the specific reasons for each term. The simple answer is that if only the proportional term is used, the system will experience overshoot, oscillation, and other nasty effects. Cheers, Eric

>Mike Sunners <.....mikesKILLspam@spam@CAA.ORG.AU> wrote: >PID is a standard type of closed loop control system. Let's take as an >example a mechanical positioning system. You have a desired position >and a sensor that provides feedback of the current poition. You need to >generate a control signal to the positioner to control its velocity >(including its direction). > >The difference between the current position and the desired position is >called the error. The control signal is computed as the weighted sum of >three terms derived from the error: > > P: Proportional to the error > I: Integral of the error > D: Derivative of the error If anyone has code which implements PID control on a PIC (ideally for a 16-bit quantity) I would be interested to see it, and I guess other people would too. Keith. ========================================================== Keith Dowsett "Variables won't; constants aren't." E-mail: kdowsettKILLspamrpms.ac.uk Phone: 0181-740-3162 Fax: 0181-743-3987 Snail mail: MRC Clinical Sciences Centre, Cyclotron Unit. Hammersmith Hospital. London W12 0NN.

>> Andy, can you tell us what PID is, or give a text reference? > >PID is a standard type of closed loop control system. Let's take as an >example a mechanical positioning system. You have a desired position >and a sensor that provides feedback of the current poition. You need to >generate a control signal to the positioner to control its velocity >(including its direction). ... I seem to remember a nice tutorial aimed at Embeeded people in a Circuit Cellar within the last two years - Circuit Cellar OR perhaps, Embedded Systems Programming magazine. The PIC Embedded handbook has that PID Servo example in it, also. I've done a number of PIDs over the years, despite the fact I'm not a true "Controls Engineer". I find PID to be almost trivial to implement. The hard part of course, is analysing the system and getting the optimal set of P/I/D terms (and all those poles, zeros, etc.) Implementation Note: You know, you can rewrite the PID equations into a FIR form, which opens up some interesting possibilities for say, a DSP approach or combining PID response with other filtering functions.. RemoveMEThomas.CoonanTakeThisOuTSciatl.com

Mike Sunners <spamBeGonemikesspamBeGoneCAA.ORG.AU> wrote: > Andy, can you tell us what PID is, or give a text reference? The difference between the current position and the desired position is called the error. The control signal is computed as the weighted sum of three terms derived from the error: P: Proportional to the error I: Integral of the error D: Derivative of the error The P term is present in any control loop: more error needs more restoring force. The I term is interesting: if the system cannot reach the desired operating point for a long time, that means the P part of the control signal is not strong enough. 'I' term simply accumulates the error signal over time to overcome this. The D term improves the response of the system to large and/or rapid disturbances: it boosts the restoring force if the error signal rapidly changes. On the minus side, it introduces the possibility of oscillating behavior. This simplistic view doesn't help much while thinking about the stability of the control loop, of course---for that, a rigorous (zero/pole) analysis that others alluded to is necessary. Please read textbooks on control theory. Again, others have mentioned some of those. przemek

In message <TakeThisOuTm0u6u7h-0000nfCEraseMEspam_OUTdc.cis.okstate.edu>, Eric Smith writes: >PID is a standard type of closed loop control system. Thanks for a good definition. I don't have an engineering background so I wasn't familiar with the specific term "PID." I do remember my first brush with control theory which I had about 25 years ago and which was so eye-opening that I will suggest it to others. I got involved with the process of using phase-locked loops as FM detectors. PLL's are closed-loop systems that have all the classic characteristics being discussed, here. They generate an error signal which is fed back to the VCO and must also be filtered in order to get the proper response from the system. If you use the wrong value of low-pass filter or maybe feed the PLL a signal whose deviation is too great for the error-correction to track, you get all kinds of examples of what can go wrong. Motor speed controls and the human heart are two more examples of closed-loop systems that use error to control themselves. This is one of those ideas that you see everywhere once you have seen it once. Martin McCormick 405 744-7572 Stillwater, OK OSU Center for Computing and Information services Data Communications Group

>Does anyone have any recommendations for PID control loop articles or theory? >(Proportional-Integral-Derivative) >This seems to be the "standard" for a whole range of valve control algorithms >in industry >James Check out: http://www.newport.com It has tutorials on PID. These are folks who make controllers, panel meters, etc. Nice WWW site. There was once a PIC appnote on Servo control, I think. Did you want to hear about any PID specifics? That subject has probably been pummelled into the ground, so as brief as possible.. The mechanical algorithm is almost trivial, out = KP*error + KI*sum_error + KD*delta_error. Get error from setpoint minus your A/D. Much of the world picks KP, KI, and KD based on trial-n-error. You can use tools to figure out analytically (like MATLAB, which actually has toolbox for this). I've been lucky - customers manually entered there own constants into my PID widget. Thomas.CoonanEraseME.....Sciatl.com

>Does anyone have any recommendations for PID control loop articles or theory? >(Proportional-Integral-Derivative) >This seems to be the "standard" for a whole range of valve control algorithms in >industry >James > Here is a book I've found quite helpful in gaining a real practical understanding of PID, and especially PID tuning: "Controller Tuning and Control Loop Performance, A Primer" No code, and little math, but you will get a lot of good 'feel' for what's going on in a PID controller. I think cost is about $12. Address: Straight-Line Control Co., Inc. 3 Bridle Brook Lane Newark, DE 19711-2003, USA Or e-mail to: EraseMEdwstclairaol.com Regards, Hugo Ahrens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hugo Ahrens, IAI Industrial Automation Inc. e-mail --> RemoveMEhahrensEraseMEEraseMEdirect.ca fax --> 604-596-3994 phone --> 604-596-3994 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Justin Grimm wrote: > > Gday > > I was just wondering if anyone has had any luck implementing PID > control code into a PIC. > Im interested in building a PID controller and would be grateful for > any code extracts anyone might have. > > Regards > Justin Hi, have a look at the Microchip app. notes, there is one about a DC brush motor that's controlled with a PID regulator. It's quite nice. Regards. -- _____________ \ / David BALDWIN \ ALCATEL / Design engineer \TELECOM/ \ / SdM (Societe de Microelectronique) \ / \ / B.P. 4205 Phone : +32 (0)71 442932 V B-6000 Charleroi Fax : +32 (0)71 442905 (Belgium) RemoveMEbaldwinspam_OUTKILLspametca.alcatel.be

I've been struggling a little with a PID control scheme (actually it's just PI, I've been warned that D terms promote instability!) I've got a proportional scheme that looks like this: Measure oven temperature Calculate theoretical oven setpoint Lookup theoretical duty cycle that should achieve setpoint Calculate current difference between actual and theoretical temperature divide by a constant P term which I'll set experimentally (right now its about 8) add the DIfference / P to the duty cycle if oven is too cold set duty cycle to 100% if difference is greater than X for fast warmup set duty cycle to zero if oven is too hot Turn on heaters for (duty cycle) counts (heaters are either on or off - no in between) turn off heaters for (256 - duty cycle) counts. 1 count = (2 minutes / 256) Do it again How do you develop an integral term in something like this? When I start messing with it it seems to get too complicated quickly. I imagine the intergral term would add up a long-term difference between actual and setpoint temperatures, and if the oven didn't achieve its setpoint over a long period (ten loops ) the oven would compensate. It gets complicated when I try to account for extremely cold or extremely hot actual temperatures - the integral term really adds up fast in these circumstances - and that's not where I need it to kick in...... It seems like I've seen a link to a PID control scheme, but I've lost track of it. any ideas? PS yes this is with a PIC.

> I've been struggling a little with a PID control scheme (actually it's > just PI, I've been warned that D terms promote instability!) I've got a > proportional scheme that looks like this: The D term is important to smooth out the change in error - helps prevent extremes in overcompensation. I actually like the D term more than I like the I term. The I term is important to eliminate the error, but without it - the error will stay mighty small with some good multipliers. I would suggest you reconsider your view on the D term. {Quote hidden}> Measure oven temperature > Calculate theoretical oven setpoint > Lookup theoretical duty cycle that should achieve setpoint > Calculate current difference between actual and theoretical temperature > divide by a constant P term which I'll set experimentally (right now its > about 8) > add the DIfference / P to the duty cycle if oven is too cold > set duty cycle to 100% if difference is greater than X for fast warmup The PID loop should automatically take care of this. Just be sure that you have a maximum "drive". {Quote hidden}> set duty cycle to zero if oven is too hot > Turn on heaters for (duty cycle) counts (heaters are either on or off - > no in between) > turn off heaters for (256 - duty cycle) counts. > 1 count = (2 minutes / 256) > Do it again > How do you develop an integral term in something like this? When I start > messing with it it seems to get too complicated quickly. Start with a super low I-Term, then work it up a little bit at a time till you are satisfied with results. > I imagine the intergral term would add up a long-term difference between > actual and setpoint temperatures, and if the oven didn't achieve its > setpoint over a long period (ten loops ) the oven would compensate. Sounds like your P-Term multiplier is to high. You should also consider maximizing the summation of error for the I-term. > It gets complicated when I try to account for extremely cold or > extremely hot actual temperatures - the integral term really adds up > fast in these circumstances - and that's not where I need it to kick > in...... > It seems like I've seen a link to a PID control scheme, but I've lost > track of it. any ideas? Here is a good link for PID loops. http://rclsgi.eng.ohio-state.edu/matlab/PID/PID.html. Hope that helps. Bill

Hello Lawrence, Here is a hand wavy explanation... it doesn't make up for root locus plots etc., but will have to do: Let's start with a plain P implementation: 1. Get the setpoint (say 100 deg C) 2. Get the actual temperature (say 70 deg C) 3. Subtract them to get the error (30 C) 4. set on duty = K + P x Error 5. goto 1 K here is a constant which should be a guess at the steady state duty cycle to keep the temperature at the setpoint value. The closer K is to the duty that would actually achieve the set temperature, the smaller your steady state error in a straight P controller will be. You could start with a value of 50 % (128) as a first guess. 'Error' can be either possitive or negative, and will then increase or decrease respectively the duty cycle in step 4. Straight P as above will never exactly reach the setpoint - there will always be an error. The higher you make P, the smaller this error will become, but eventually you approach bang-bang control - heat will be permanently on if the temperature is too high, permanently off if too low. In this case your system will end up oscillating above and below the setpoint since the heat is only switched off once the temperature reaches the setpoint, and your oven temperature will increase some more because of the heat stored in the elements, and vice versa when cooling down. To eliminate the steady state error, we introduce an I term: 1. Get the setpoint (say 100 deg C) 2. Get the actual temperature (say 70 deg C) 3. Subtract them to get the error (30 C) 4. I = I + K2 x Error 5. set on duty = K + P x Error + I 6. goto 1 As before 'error' can be negative, and so can I. In this case the I term will over time force the duty cycle to that required to reach the setpoint exactly. As long as the temperature is too low, the I term will keep increasing, in turn increasing your duty cycle, until eventually your setpoint temperature is reached. A smaller value of K2 will cause this to take longer, and too large a value will cause the temperature to overshoot and oscillate once again. A good idea would be to limit the size of the I term so that it can only introduce a change of a few degrees C in the oven - just enough to eliminate the maximum steady state error encountered using P alone. ie., if your oven only reaches 95 deg using P control alone (setpoint 100), at a duty cycle of 214 (214/255), and you know that the oven reaches a steady state 100 deg at a duty of 224, then limit your I term so it can't get bigger than 10 or smaller than -10. This will prevent it from 'winding up' while the temperature is far above or below the setpoint, causing large overshoots. The D term is added similarly, but can be based either on just the setpoint (only acts on changes in the setpoint), or based on the error (also acts on someone opening the door introducing a sudden temperature changes). I'm a bit tired of typing right now, so you'll have to ask if you have any more questions, which I will gladly answer. Cheers Roland PS. What you originally implemented looked more like an I controller than a P controller - your P term grew like the I term above, if I understood you explanation. {Original Message removed}

Lawrence Lile wrote: > > I've been struggling a little with a PID control scheme (actually it's just > PI, I've been warned that D terms promote instability!) I've got a > proportional scheme that looks like this: The I term is great for forcing the system to equilibrium, but also great for inducing unwanted oscillations. You *have* to make provision for a I term multiplication factor that can be fine-tuned on the actual system. This factor is usually much, much lower than the P-factor (and the D factor if you use it). A good starting point for you experiments, is 0.1 . You can handle this horrible math (in PIC terms) by not adding the difference to your accumulator on every sample, but only on every tenth (hence 0.1) sample. If you want almost zero oscillation, you can set one or two lower set-points where the I-factor is reduced even further. > PS yes this is with a PIC. Of course! I did a PID controller for a linear motor as my very first PIC project (ever). I worked my butt off, and it worked. I was sooooooo proud of it! I never got paid for it, but it did land me a good job ;) -- Friendly Regards /"\ \ / Tjaart van der Walt X ASCII RIBBON CAMPAIGN tjaartSTOPspamspam_OUTwasp.co.za / \ AGAINST HTML MAIL |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| | Mobile : spamBeGonetjaartSTOPspamEraseMEsms.wasp.co.za (160 text chars) | | http://www.wasp.co.za/~tjaart/index.html | |Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973| | WGS-84 : 26¡10.52'S 28¡06.19'E | |--------------------------------------------------|

Reginald - I've used a similar scheme with an 8 number lookup table. I had fair results, not great. The problem is that with 8 numbers, and setpoints of 275, 300, ....450F you only have a 25F degree distance between points of control. My oven would typically drop two of these points or 50 degrees F after a food load was added. I'm trying for a much more precise method. Maybe I could simply use a 32 position lookup table and save on complexity. Right now, though, I have implemented a PI control alorithm and I'm going to test it in a real oven (I've been using an emulator and a faked thermistor reading for test) and look at the dymnamic responses. I need to bone up on some of these methods of setting control loop parameters. Why PI and not PD or PID? PD would generate an oven with minimum overshoot. I actually want this oven to overshoot, because many receipes are based on cooking times with conventional ovens. A conventional thermostatic oven controller corresponds roughly to a PI control scheme (this is a REAL rough analogy guys, don't pick it apart) To cok a frozen pizza in the correct amount of time, the oven has to behave like an old crude thermostat. Typically, they will overshoot once, then settle into a regular oscillating pattern. Reginald's Educated Erudition was: ----->> {Quote hidden}> A lot depends on the accuracy requirements and whether the contents of > the oven have a significant effect on its thermal inertia. I got good > results from a much simpler (conceptually) scheme: > > a) if temp is more than x degrees from setpoint, set heater duty cycle > to 100% if below or 0% if above temperature. > > b) if temp is below setpoint, when it approaches within x degrees start > decreasing duty cycle according to an experimentally determined lookup > table. Similarly for approaches from above. This prevents overshoot > if the thermal characteristics of the system are predictable, which > is a good approximation for many ovens. > > If it's going to take more horsepower than that, a good pragmatic guide > to control loops is: > > Controller Tuning and Control Loop Performance" by David W. St. Clair. > http://members.aol.com/pidcontrol/booklet.html > > I think it was somebody on this list that turned me on to it. Hope this > is helpful -- good luck! > > Reg Neale > >

|I've been struggling a little with a PID control scheme (actually it's just |PI, I've been warned that D terms promote instability!) I've got a |proportional scheme that looks like this: In most ovens, the heater will heat up some mass which will in turn heat up whatever's in the oven (including the thermostat). The rate at which the oven's interior temperature is changing is in part an indication of the temperature difference between the thermal mass and the oven. If you won't want oscillations, you'll pretty much need a "D" term. Otherwise, until the oven reaches the correct temperature you'll be trying to heat the thermal mass; once you reach the correct temperature the mass will heat it further (until the mass cools down, etc.) For your system, I think you may be best off trying to estimate, at any given time, the peak temperature the system would reach if you were to completely cease heating it. If that temperature is below your target, switch the heater on. If the temperature is above your target, switch the heater off. If done properly, this should yield good performance without too much work.

At 16:35 04/22/99 -0500, John Payson wrote: >|I've been struggling a little with a PID control scheme (actually it's just >|PI, I've been warned that D terms promote instability!) I've got a >|proportional scheme that looks like this: > >For your system, I think you may be best off trying to estimate, at any >given time, the peak temperature the system would reach if you were to >completely cease heating it. If that temperature is below your target, >switch the heater on. If the temperature is above your target, switch >the heater off. If done properly, this should yield good performance >without too much work. in a sense (you've got to stretch it a bit here :), that's what a correctly tuned pid algorithm does. and as you say correctly, for slow processes like an oven heating, it's often the 'i' part which introduces instability and not the 'd' part. often the 'd' part is so small that it gets almost negligible when you're close to the setpoint (and the temperature changes are small); it serves primarily to avoid overshooting when approaching the setpoint. ge