Hi everybody, my name is Carlos Marcano, I am an
electronics engineer from Venezuela (south america), I
am new to the list and I hope to be helpfull as
posible. Right now I am working on a little experiment
wich involves a PID controller working on a 16F84.
Ok, here is the thing: I want to keep a metallic ball
between two bands and I am using an electromagnet to
make the ball "float" between those bands; if the ball
passes the lower band the magnet should increase its
magnetic field and if the ball passes the upper band
the magnet should decrease its magnetic field. I am
getting the position of the ball using a couple of
LDRs, one for the upper band and other for the lower
band. They are polarized by an adjusting circuit in a
way to get 5 volts from each when the ball is between
the bands, that is letting the LDRs get full light.
When the ball is attratcted to the magnet it will
avoid certain amount of light to get to the top LDR
and the voltage across it will drop. The sums of the
voltage from the LDRs will give an aproximation of the
position of the ball. After the sum there is an
adjusting circuit wich responds to: Position= 5-
[(V1-V2)+5]*0.5 where V1 and V2 are the voltages
across the top and bottom LDRs respectively. This will
produce a
voltage from 0 (the ball completely over the bottom
LDR and living full lighted the top one) to 5 Volts
((the ball completely over the top LDR and living full
lighted the bottom one). This means that when the ball
is between the LDRs ("floating") the resulting voltage
will be: Position= 5-[(5-5)+5]*0.5 = 5-2.5= 2.5 V.
That means that 2.5 is de ideal setpoint for my
system. I did this using just analog electronics a
couple of years ago, but I lost my schematic circuits
and annotations. Recently I came with the idea of
using a PIC to control de system, implementing the PID
on it. I would use an ADC to convert the position
voltage and get it into the PIC, calculate the
response with the PID, and then use a DAC to actuate
the electromagnet. Well, this is pretty much
everything, PLEASE FORGIVE MY ENGLISH, it is not my
first language and I am still learning, and as ussual
any sugestion will be welcome...
Carlos Marcano.
(proud venezuelan).
_________________________________________________________
Do You Yahoo!?
Informacisn de Estados Unidos y Amirica Latina, en Yahoo! Noticias.
Vismtanos en http://noticias.espanol.yahoo.com
> Right now I am working on a little experiment
> wich involves a PID controller working on a 16F84.
> Ok, here is the thing: I want to keep a metallic ball
> between two bands and I am using an electromagnet to
> make the ball "float" between those bands;
> ...
> any sugestion will be welcome...
Bare PID might not be the optimum method since the magnetic field is
highly non-linear with position. The force on the ball is very nicely
proportional to the current, but not to position. I would start with a
low level interface that can put an arbitrary fixed force on the ball
regardless of position. The PID controller will work much better if its
job is to compute desired force as a function of ball position (and
derivative and intergral thereof).
The inner loop that adjusts current as a function of position and desired
force will probably need to be much faster than the outer PID control
loop. Whether a PIC is up to it depends on the mass of the ball, and how
much the magnetic field strength varies from one end of the travel to the
other at the same current. This is probably best done with lookup tables.
The 16F84 may not be sufficient. You would have much more room for lookup
tables in a 16F876. If you need more power, the next step would be the
18F252.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Carlos Marcano wrote:
>
> Hi everybody, my name is Carlos Marcano,
> Ok, here is the thing: I want to keep a metallic ball
> between two bands and I am using an electromagnet to
> make the ball "float" between those bands; if the ball
> passes the lower band the magnet should increase its
> magnetic field and if the ball passes the upper band
> the magnet should decrease its magnetic field.
Hi Carlos! :o)
You will find this is MUCH harder to do with a
constant magnetic field. It is a lot easier if
you turn the top (pull) magnet on and off very
fast and there is some tiny movement of the ball.
Commercial "desk toy" type designs usually oscillate
fast enough that it is not obvious until you
examine it very close.
-Roman
--- Roman Black <.....fastvidKILLspam.....EZY.NET.AU> escribis: > >
>
> Hi Carlos! :o)
> You will find this is MUCH harder to do with a
> constant magnetic field. It is a lot easier if
> you turn the top (pull) magnet on and off very
> fast and there is some tiny movement of the ball.
> Commercial "desk toy" type designs usually oscillate
> fast enough that it is not obvious until you
> examine it very close.
> -Roman
Hi again Roman, it is nice to find you here...
About the little thing I have been doing, so you are
proposing to make a sort of "on/off" control? Do you
mean like producing and average magnetic field product
of turning off and on the electromagnete with a
constant current and a constant freq? I suposse that
the big trouble about this is finding out the proper
values for current and frequency to make the ball
float... In the other hand no feedback sensors (i.e.
the postion sensors) would be needed so it would be an
open loop system; would this guarantee (not sure I
wrote it right!) stability in the system?
Olin Lathrop proposed to me that I should change
the PID focus and use an scheme based on look up
tables because the magnetic fields isn4t as linear as
the position. What do you think about that?
thanx for your time,
Carlos
_________________________________________________________
Do You Yahoo!?
Informacisn de Estados Unidos y Amirica Latina, en Yahoo! Noticias.
Vismtanos en http://noticias.espanol.yahoo.com
> Olin Lathrop proposed to me that I should change
> the PID focus and use an scheme based on look up
> tables because the magnetic fields isn4t as linear as
> the position.
What I suggested was adding a layer beneath the PID that provides a linear
force interface. The PID output signal would drive the desired force on
the ball.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Funny, I thought this to be a rather routine PID application. Granted it
would have to be fast, the proportional band width will be the key, and I
think it can certainly be done with one loop.
We do fast PID for temp control that has a cycle time of about 50mS (not
really so fast, when you think about it, only fast compared to off-the-shelf
process controllers) and the proportional band width needs to be narrow
enough for the system to respond quickly, but wide enough to not overshoot
wildly. That would equate to being narrow enough to keep the ball from
dropping out of range, but fast enough to recover quickly. I never did get
this process to run smoothly with anything but a zero derivative, so maybe
what's needed here also is PI control....
By the time you figure out how you can actualize the on/off cycling in a
wide enough range to keep the ball afloat, you might as well have stayed
with the analog ouput and a fast PI algorithm.
If someone had some spare time, this could probably be accomplished with a
100 or 50mS packaged process controller with an analog output....then the
PID data extracted and used in your PIC program...
> The inner loop that adjusts current as a function of position
> and desired
> force will probably need to be much faster than the outer PID control
> loop.
If the PID cycled fast enough, couldn't you do that with one loop and DAC?
> > Olin Lathrop proposed to me that I should change
> > the PID focus and use an scheme based on look up
> > tables because the magnetic fields isn4t as linear as
> > the position.
>
> What I suggested was adding a layer beneath the PID that
> provides a linear
> force interface. The PID output signal would drive the
> desired force on
> the ball.
>
>
>
> application. Granted it
> would have to be fast, the proportional band width
> will be the key, and I
> think it can certainly be done with one loop.
> We do fast PID for temp control that has a cycle
> time of about 50mS (not
> really so fast, when you think about it, only fast
> compared to off-the-shelf
> process controllers) and the proportional band width
> needs to be narrow
> enough for the system to respond quickly, but wide
> enough to not overshoot
> wildly. That would equate to being narrow enough to
> keep the ball from
> dropping out of range, but fast enough to recover
> quickly. I never did get
> this process to run smoothly with anything but a
> zero derivative, so maybe
> what's needed here also is PI control....
> By the time you figure out how you can actualize the
> on/off cycling in a
> wide enough range to keep the ball afloat, you might
> as well have stayed
> with the analog ouput and a fast PI algorithm.
>
> If someone had some spare time, this could probably
> be accomplished with a
> 100 or 50mS packaged process controller with an
> analog output....then the
> PID data extracted and used in your PIC program...
I got the idea... I think that I can get as fast as
a 10 mS or even a little less cycle time for a PI
controller, but i am now tempted to use the on/off
control...
** Carlos **
_________________________________________________________
Do You Yahoo!?
Informacisn de Estados Unidos y Amirica Latina, en Yahoo! Noticias.
Vismtanos en http://noticias.espanol.yahoo.com
> If the PID cycled fast enough, couldn't you do that with one loop and
DAC?
Perhaps you could. The problem I was worrying about is that the force on
the ball is highly dependent on its position due to the non-linear nature
of magnetic fields. The PID constants that worked well at one point would
probably not work well at a different point because of this. That's why I
suggested providing a linear interface to force that the PID drives. That
should allow one set of control contstants to work over the entire
positional range of the ball.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> About the little thing I have been doing, so you are
> proposing to make a sort of "on/off" control? Do you
> mean like producing and average magnetic field product
> of turning off and on the electromagnete with a
> constant current and a constant freq? I suposse that
> the big trouble about this is finding out the proper
> values for current and frequency to make the ball
> float... In the other hand no feedback sensors (i.e.
> the postion sensors) would be needed so it would be an
> open loop system; would this guarantee (not sure I
> wrote it right!) stability in the system?
Yes, you do need the negative feedback to get the
ball nice and stable. You can remove the bottom light
sensor and just use one sensor, and for that matter
you only need one electromagnet. the lifting one.
For the moment the biggest issue is the mechanics,
not the PID method. :o)
If you try a constant magnetic field you find the
field strength needed to hold the ball weight suspended
is VERY close to the field that will slam the ball
full upwards. To make it work in that way you need
VERY fine control of field strength which is a real
pain especially since you are using relatively slow
LDR sensors.
A better technique is to use a strong field in an
on-off fashion, switched very fast based on a simple
comparator using the LDR. This will rely on the
relatively high inertia of the ball, so it never
has time to lift or fall too far.
I think you can use something as simple as a LDR
+ comparator that switches for a set (monostable)
off period whenever the ball gets too high, so when
the ball gets to set point it switches off, and
the off period and gravity are known so the ball
falls a known amount, then it switches back on.
I have seen commercial desk toys using just a few
transistors, and noticed micro oscillation of the
load. Basically it is just a mechanical oscillator
regulated by ball position. :o)
-Roman
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> I got the idea... I think that I can get as fast as
> a 10 mS or even a little less cycle time for a PI
> controller, but i am now tempted to use the on/off
> control...
You should be able to do better than that for a simple PI controller.
One of my projects runs two layered PID controllers in a 16F876. The
lower one adjusts the PWM output to a DC motor to control its position,
and the upper one adjusts the motor position, which is connected to a
throttle of a gasoline engine, to control the engine's speed based on some
input parameters. Both are full PID with a few other features added, and
both use software 24 bit floating point. A new computation is done every
10mS, although the worst case computation time is about 7mS.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> Yes, you do need the negative feedback to get the
> ball nice and stable. You can remove the bottom
> light
> sensor and just use one sensor, and for that matter
> you only need one electromagnet. the lifting one.
>
> For the moment the biggest issue is the mechanics,
> not the PID method. :o)
>
> If you try a constant magnetic field you find the
> field strength needed to hold the ball weight
> suspended
> is VERY close to the field that will slam the ball
> full upwards. To make it work in that way you need
> VERY fine control of field strength which is a real
> pain especially since you are using relatively slow
> LDR sensors.
>
> A better technique is to use a strong field in an
> on-off fashion, switched very fast based on a simple
> comparator using the LDR. This will rely on the
> relatively high inertia of the ball, so it never
> has time to lift or fall too far.
>
> I think you can use something as simple as a LDR
> + comparator that switches for a set (monostable)
> off period whenever the ball gets too high, so when
> the ball gets to set point it switches off, and
> the off period and gravity are known so the ball
> falls a known amount, then it switches back on.
>
> I have seen commercial desk toys using just a few
> transistors, and noticed micro oscillation of the
> load. Basically it is just a mechanical oscillator
> regulated by ball position. :o)
> -Roman
Thanks for the ideas, I4ll give it a try and will
tell you how did it go...
* Carlos *
_________________________________________________________
Do You Yahoo!?
Informacisn de Estados Unidos y Amirica Latina, en Yahoo! Noticias.
Vismtanos en http://noticias.espanol.yahoo.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
--- Olin Lathrop <olin_piclistEraseME.....EMBEDINC.COM> wrote: >
>
> You should be able to do better than that for a
> simple PI controller.
>
> One of my projects runs two layered PID controllers
> in a 16F876. The
> lower one adjusts the PWM output to a DC motor to
> control its position,
> and the upper one adjusts the motor position, which
> is connected to a
> throttle of a gasoline engine, to control the
> engine's speed based on some
> input parameters. Both are full PID with a few
> other features added, and
> both use software 24 bit floating point. A new
> computation is done every
> 10mS, although the worst case computation time is
> about 7mS.
Well, should improve my algorithms... I think I
will try Roman4s idea first... Thanks for your
advices...
* Carlos *
_________________________________________________________
Do You Yahoo!?
Informacisn de Estados Unidos y Amirica Latina, en Yahoo! Noticias.
Vismtanos en http://noticias.espanol.yahoo.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
Olin, I'm interested in PID PIC-based controllers - just from a learning
point of view - I don't have any particular application in mind at this point.
I've run across some references and articles on PID on the net, but most of
this is just theory - I've not seen any examples showing how one would do
PID stuff in code. Can you point me to anything?
Thanks
Larry
Larry Bradley
Orleans (Ottawa), Ontario, CANADA
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> Olin, I'm interested in PID PIC-based controllers - just from a learning
> point of view - I don't have any particular application in mind at this
point.
>
> I've run across some references and articles on PID on the net, but most
of
> this is just theory - I've not seen any examples showing how one would do
> PID stuff in code. Can you point me to anything?
I can't give you any code if that's what you're asking. It was written for
a paying customer, so I'm not going to release it for free. If you
understand the theory, then implementing the code isn't any different from
realizing any other algorigthm in firmware.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
I understand the principles involved. I won't go so far as to say that I
really understand how I would implement it in hardware using opamps even. I
was just wondering if you knew of any material on PID, especially in the
digital world, that I could read up on.
> > Olin, I'm interested in PID PIC-based controllers - just from a learning
> > point of view - I don't have any particular application in mind at this
>point.
> >
> > I've run across some references and articles on PID on the net, but most
>of
> > this is just theory - I've not seen any examples showing how one would do
> > PID stuff in code. Can you point me to anything?
>
>I can't give you any code if that's what you're asking. It was written for
>a paying customer, so I'm not going to release it for free. If you
>understand the theory, then implementing the code isn't any different from
>realizing any other algorigthm in firmware.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com hint: PICList Posts must start with ONE topic:
>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
Larry Bradley
Orleans (Ottawa), Ontario, CANADA
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
Proportional control means that the correction is proportional to the
error.
Correction = -1 * P * Perror = -1 * P * (Setpoint - CurrentValue)
Integral control means that the correction depends on the present and past
error. More exactly, the Integral of the error, which can be represented
as the sum of the errors so far. If Ierror0 is the error at the previous
measurement time and error is the Ierror at the present time then:
By putting it all together and everything in the middle of a loop that
repeats at fixed time intervals:
Ierror = 0 // initial error integral is zero
do
// Read input value
CurrentValue = Read(Measure Feedback Value)
// PID process
Error = (Setpoint - CurrentValue) // the error
// Integral term
if(Error != 0)
Ierror += Error // integral
else
Ierror = 0; // reset integrator if the we have reached the setpoint
// Limit integral value
if(Ierror > MAXIERROR) // limit integrator
Ierror = MAXIERROR;
if(Ierror < -1 * MAXIERROR)
Ierror = -1 * MAXIERROR;
// Derivative error term
Derror -= Error // derivative (differential)
// Limit it
if(Derror > MAXDERROR)
Derror = MAXDERROR;
if(Derror < -1 * MAXDERROR)
Derror = -1 * MAXDERROR
// Compute PID correction
Correction = -1 * ( P * Error + I * Ierror + D * Derror )
Derror = Error // store the 'previous' derivative for the next pass
// Output correction
Write(Correction)
while forever
Note: All the variables are signed.
Note2: The integral term will cause a lot of trouble. It is customary to
zero it whenever Error is 0 and to limit its growth both in the high
direction and in the low direction, to reduce trouble. The Derror is also
limited sometimes in the high and low direction to avoid giant kicks when
the input Setpoint changes by a large value.
Note3: PID tuning is a course by itself. It requires that the user
understand the mechanical equivalents of inertial mass and friction
losses.
Note4: If PID is applied to a mechanism that has backlash then the loop
will oscillate. Typical example: model servos.
The integral model used here is not very accurate (squares = Riemann sum).
Precision PID would use a better integration method.
Agreed 100%. I would just add that when all else fails, apply
experience....and also.....There will be hysteresis in EVERY control
loop..it's just a matter of how much is acceptable.
> Short PID 101:
>
> PID = Proportional Integral Derivative
>
> Proportional control means that the correction is proportional to the
> error.
>
> Correction = -1 * P * Perror = -1 * P * (Setpoint - CurrentValue)
>
> Integral control means that the correction depends on the
> present and past
> error. More exactly, the Integral of the error, which can be
> represented
> as the sum of the errors so far. If Ierror0 is the error at
> the previous
> measurement time and error is the Ierror at the present time then:
>
> Ierror = Ierror + (Setpoint - CurrentValue)
> Correction = -1 * I * Ierror
>
> Derivative control means that the correction depends on the
> change rate of
> the error. Therefore if Derror was the previous error:
>
> Derror = Derror - (Setpoint - CurrentValue)
> Correction = -1 * D * Derror
> Derror = (Setpoint - CurrentValue)
>
> By putting it all together and everything in the middle of a loop that
> repeats at fixed time intervals:
> -----Original Message-----
> From: Peter L. Peres [SMTP:EraseMEplpACTCOM.CO.IL]
> Sent: Friday, November 29, 2002 3:56 PM
> To: RemoveMEPICLISTEraseMEEraseMEmitvma.mit.edu
> Subject: Re: [pic]: PID
>
> Note2: The integral term will cause a lot of trouble. It is customary to
> zero it whenever Error is 0 and to limit its growth both in the high
> direction and in the low direction, to reduce trouble. The Derror is also
> limited sometimes in the high and low direction to avoid giant kicks when
> the input Setpoint changes by a large value.
>
Wether you can zero the integral term depends very much on what you are
controlling. For a system where the controller output is zero when the
error is zero, this is acceptable (e.g. positional controls), but for e.g. a
temperature controller the controller always has some output even when error
is zero, so the integral cannot be zeroed.
> I understand the principles involved. I won't go so far as to
> say that I
> really understand how I would implement it in hardware using
> opamps even. I
> was just wondering if you knew of any material on PID,
> especially in the
> digital world, that I could read up on.
>
Because the output moves relative to the calculated output (i.e.
new_output=old_output+calculation) for every scan cycle, you can and have to
zero the integral term when the error is zero. Also integral is the area
under the curve between now and the last time the error was zero.
> -----Original Message-----
> From: Justin Grimm [SMTP:EraseMEJustin.GrimmspamspamBeGoneSOUTHCORP.COM.AU]
> Sent: Tuesday, December 03, 2002 5:28 AM
> To: RemoveMEPICLISTKILLspammitvma.mit.edu
> Subject: Re: [pic]: PID
>
> Because the output moves relative to the calculated output (i.e.
> new_output=old_output+calculation) for every scan cycle, you can and have
> to
> zero the integral term when the error is zero. Also integral is the area
> under the curve between now and the last time the error was zero.
>
> Justin
>
Ah right, I see what you mean. However, that;s just one form of PID, you
don't have to accumulate the output. The form I am used to working with is:
Hi Michael,
Derivative has nothing to do with the error, it's only on the rate of change
of the measured variable.
If you didnt sum the new calculated output to the old output, when there is
no error the output will be zero, which is not good. This is because the
derivative term is zero, the integral term is zero and the proportional term
is zero.
What happens with PID control is the gain responds to an error in the
variable compared to setpoint and the integral will add to the output when
the variable is away from setpoint for an amount of time. As it stays away
longer and longer it adds (or subtracts) more and more to the output. When
it reaches setpoint the integral term goes to zero thereby not adding any
more to the output.When the variable gets to setpoint, the output stays
where it is .
As you can see you add (or subtract) to the output every scan cycle.
This is the way all PID controllers I have seen work.
At home ive got some calcs I did ages ago, I'll see if I can find them.
dMV=[gain * error]+[gain * error * integral constant * (area between PV and
SP since last cycle)]+[gain * derivative constant * slope of PV]
I cant remember if this is right I'll have to check.
> -----Original Message-----
> From: Justin Grimm [SMTP:Justin.GrimmSTOPspamspam_OUTSOUTHCORP.COM.AU]
> Sent: Tuesday, December 03, 2002 9:22 AM
> To: spamBeGonePICLISTSTOPspamEraseMEmitvma.mit.edu
> Subject: Re: [pic]: PID
>
> Hi Michael,
> Derivative has nothing to do with the error, it's only on the rate of
> change
> of the measured variable.
>
I understood that the derivative term was the rate of change of error. At
least every text on PID I have ever seen states this. Measuring the rate of
change of the plant value is meaningless without reference to the set-point.
> If you didnt sum the new calculated output to the old output, when there
> is
> no error the output will be zero, which is not good. This is because the
> derivative term is zero, the integral term is zero and the proportional
> term
> is zero.
>
The integral term be would only be zero if you have deliberately zeroed it.
In the algorithm I showed, the integral terms holds the output at the steady
state condition when there is zero error. I have implemented this in many
(tens of thousands) of devices that are functioning correctly, so this does
definately work as a PID controller. I just wondered if there was any
advantage in "integrating" the controller output and zeroing the integral
term over the method I used.
Mike
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
I understood that the derivative term was the rate of change of error. At
least every text on PID I have ever seen states this. Measuring the rate of
change of the plant value is meaningless without reference to the set-point.
You're right, I'm rambling on tonight, 16 hour shifts do that to you ;)
I will go through this stuff again though.
Mike
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*>> -----Original Message-----
*>> From: Peter L. Peres [SMTP:KILLspamplpspamBeGoneACTCOM.CO.IL]
*>> Sent: Friday, November 29, 2002 3:56 PM
*>> To: EraseMEPICLISTEraseMEmitvma.mit.edu
*>> Subject: Re: [pic]: PID
*>>
*>> Note2: The integral term will cause a lot of trouble. It is customary to
*>> zero it whenever Error is 0 and to limit its growth both in the high
*>> direction and in the low direction, to reduce trouble. The Derror is also
*>> limited sometimes in the high and low direction to avoid giant kicks when
*>> the input Setpoint changes by a large value.
*>>
*>Wether you can zero the integral term depends very much on what you are
*>controlling. For a system where the controller output is zero when the
*>error is zero, this is acceptable (e.g. positional controls), but for e.g. a
*>temperature controller the controller always has some output even when error
*>is zero, so the integral cannot be zeroed.
The integral is the integral of the error and the error is zero when the
setpoint is reached (as reported by feedback). Zeroing the integrator at
this point makes up for integrator induced drift, offset and other
'niceties'. In a temperature controller the final temperature must first
be reached before proper regulation starts. But thermostats are often PD
type regulators (PID with I=0) since the I term is supplied by the thermal
mass.
Peter
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> -----Original Message-----
> From: Peter L. Peres [SMTP:@spam@plp@spam@spam_OUTACTCOM.CO.IL]
> Sent: Monday, December 02, 2002 9:12 PM
> To: spamBeGonePICLISTKILLspammitvma.mit.edu
> Subject: Re: [pic]: PID
>
> The integral is the integral of the error and the error is zero when the
> setpoint is reached (as reported by feedback). Zeroing the integrator at
> this point makes up for integrator induced drift, offset and other
> 'niceties'. In a temperature controller the final temperature must first
> be reached before proper regulation starts. But thermostats are often PD
> type regulators (PID with I=0) since the I term is supplied by the thermal
> mass.
>
> Peter
>
>
I can understand is for a purely analog control loop, but drift in a digital
PID loop is surely pretty much non-existant? I also can't understand how
the "I" term can be supplied by the thermal mass, as without energy input it
cannot change temperature (i.e. there will still be an error due to just
having a proportional term).
*>> -----Original Message-----
*>> From: Peter L. Peres [SMTP:.....plpspam_OUTACTCOM.CO.IL]
*>> Sent: Monday, December 02, 2002 9:12 PM
*>> To: TakeThisOuTPICLIST.....TakeThisOuTmitvma.mit.edu
*>> Subject: Re: [pic]: PID
*>>
*>> The integral is the integral of the error and the error is zero when the
*>> setpoint is reached (as reported by feedback). Zeroing the integrator at
*>> this point makes up for integrator induced drift, offset and other
*>> 'niceties'. In a temperature controller the final temperature must first
*>> be reached before proper regulation starts. But thermostats are often PD
*>> type regulators (PID with I=0) since the I term is supplied by the thermal
*>> mass.
*>>
*>> Peter
*>>
*>>
*>I can understand is for a purely analog control loop, but drift in a digital
*>PID loop is surely pretty much non-existant? I also can't understand how
*>the "I" term can be supplied by the thermal mass, as without energy input it
*>cannot change temperature (i.e. there will still be an error due to just
*>having a proportional term).
The I term comes from the thermal resistance between the heater and the
mass to be heated. This forms a 'low pass' filter that acts like an
integrator. It is equivalent to a RC lowpass cell (R series C to gnd). In
fact things are more complicated with real systems but usually one can
simplify and assume that if the system is near equilibrum and the D term
compensates the I term induced by the thermal system then the loop will
function pretty well. It is like compensating for a lowpass circuit with a
highpass in analog electronics.
The drift etc in the integrator comes from the analog (usually) feedback
source and from the inaccuracy of the integration. Consider the case where
the loop cannot reach equilibrium because the input changes all the time.
In theory the input should change slowly enough that at one time the error
will be zero and then you can null the integrator. But this is hard to
ensure. So you cannot be sure that the integrator will be nulled (you can
make sure of this using a state machine that compares the direction of the
error and nulls the integrator if this changes sign and a null was not
seen meanwhile).