Truncated match.
PICList
Thread
'PID control'
1996\04\10@031416
by
Eric Smith

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
1996\04\10@033737
by
Keith Dowsett

>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
16bit quantity) I would be interested to see it, and I guess other people
would too.
Keith.
==========================================================
Keith Dowsett "Variables won't; constants aren't."
Email: kdowsettKILLspamrpms.ac.uk
Phone: 01817403162
Fax: 01817433987
Snail mail: MRC Clinical Sciences Centre, Cyclotron Unit.
Hammersmith Hospital. London W12 0NN.
1996\04\10@040107
by
Andrew Warren
1996\04\10@044956
by
Eric Smith
Keith Dowsett <kdowsettspam_OUTRPMS.AC.UK> wrote:
>Mike Sunners <@spam@mikesKILLspamCAA.ORG.AU> wrote:
>>PID is a standard type of closed loop control system. Let's take as an
A little care with the attributions would be nice. I wrote that.
Mike was asking what PID was.
Eric
1996\04\10@053030
by
David Knell
>If anyone has code which implements PID control on a PIC (ideally for a
>16bit quantity) I would be interested to see it, and I guess other people
>would too.
It's in the Applications handbook  there's a complete work on controlling
a DC motor using a 17C42.
Dave

David Knell
Tel: 01843 846558
Fax: 01843 846608
Email: KILLspamdaveKILLspamdaveltd.co.uk
1996\04\10@084334
by
Thomas Coonan

>> 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
1996\04\10@110741
by
Przemek Klosowski

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 coursefor 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
1996\04\10@151213
by
Martin McCormick

In message <TakeThisOuTm0u6u7h0000nfCEraseMEspam_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
eyeopening that I will suggest it to others. I got involved with the process
of using phaselocked loops as FM detectors. PLL's are closedloop 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 lowpass filter or maybe feed the PLL a signal whose deviation
is too great for the errorcorrection 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 closedloop 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 7447572 Stillwater, OK
OSU Center for Computing and Information services Data Communications Group
1996\04\11@030716
by
Mike Sunners
On Wed, 10 Apr 1996, Martin McCormick wrote:
> Thanks for a good definition. I don't have an engineering background
> so I wasn't familiar with the specific term "PID."
I do have an engineering background, and I wasn't familiar with the
specific term "PID" :). That is, I did some control theory about 14
years ago. Given that an engineering half life is about 5 years ...
Anway, thanks to Andy, Eric and others for their definitions.
________________________________________________
Mike Sunners <RemoveMEmikesTakeThisOuTcaa.org.au> W +61 8 223 2519
'PID Control'
1996\05\29@115041
by
James Musselman
Does anyone have any recommendations for PID control loop articles or theory?
(ProportionalIntegralDerivative)
This seems to be the "standard" for a whole range of valve control algorithms in
industry
James
1996\05\29@173245
by
Thomas Coonan
>Does anyone have any recommendations for PID control loop articles or theory?
>(ProportionalIntegralDerivative)
>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 trialnerror. 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
1996\05\29@201519
by
Hugo Ahrens
>Does anyone have any recommendations for PID control loop articles or theory?
>(ProportionalIntegralDerivative)
>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:
StraightLine Control Co., Inc.
3 Bridle Brook Lane
Newark, DE 197112003, USA
Or email to: EraseMEdwstclairaol.com
Regards,
Hugo Ahrens
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hugo Ahrens, IAI Industrial Automation Inc.
email > RemoveMEhahrensEraseMEEraseMEdirect.ca
fax > 6045963994
phone > 6045963994
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'PID control'
1997\04\09@090608
by
Justin Grimm
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
1997\04\09@091608
by
David BALDWIN
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 B6000 Charleroi Fax : +32 (0)71 442905
(Belgium) RemoveMEbaldwinspam_OUTKILLspametca.alcatel.be
'PID control'
1999\04\16@112030
by
Lawrence Lile

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 longterm 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.
1999\04\16@114745
by
Bill Danielson

> 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 ITerm, 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 longterm 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 PTerm multiplier is to high. You should also
consider maximizing the summation of error for the Iterm.
> 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.ohiostate.edu/matlab/PID/PID.html.
Hope that helps.
Bill
1999\04\16@120236
by
Lawrence Lile
1999\04\16@154622
by
Roland Andrag

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 bangbang 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}
1999\04\19@012347
by
Tjaart van der Walt

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 finetuned
on the actual system. This factor is usually much, much lower than
the Pfactor (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 setpoints
where the Ifactor 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)116228686 Fax: +27(0)116228973
 WGS84 : 26¡10.52'S 28¡06.19'E 

1999\04\19@094339
by
Lawrence Lile

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
>
>
1999\04\22@173255
by
John Payson

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.
1999\04\22@215948
by
Gerhard Fiedler

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
More... (looser matching)
 Last day of these posts
 In 1999
, 2000 only
 Today
 New search...