Searching \ for 'PID Control with PIC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=PID
Search entire site for: 'PID Control with PIC'.

Truncated match.
PICList Thread
'PID Control with PIC'
1998\10\29@220038 by Facundo Cestona

picon face
Hi, anyboby had worked with a PID control algorithm for the PIC 16Cxxx
family.
Thanks

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

1998\10\30@024800 by Dr. Imre Bartfai

flavicon
face
Hi,

there is an AN for this. Look at Microchip website and/or their CD. I use
the algorithm and it works fine.

Imre


On Thu, 29 Oct 1998, Facundo Cestona wrote:

> Hi, anyboby had worked with a PID control algorithm for the PIC 16Cxxx
> family.
> Thanks
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
>


'PID Control with PIC'
1998\11\03@034144 by Wolfgang Willenbrink
flavicon
face
Hi Imre,
working on PID-controllers with PIC I«m highly interested in some codings
too!
Please send me an e-mail according to your experiences.

Thanx in award and greetings from MŸnster!

Wolfgang

-----UrsprŸngliche Nachricht-----
Von: Dr. Imre Bartfai <spam_OUTrootTakeThisOuTspamPROF.PMMF.HU>
An: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU <PICLISTspamKILLspamMITVMA.MIT.EDU>
Datum: Montag, 2. November 1998 19:57
Betreff: Re: PID Control with PIC


{Quote hidden}

1998\11\03@042620 by Stefan Sczekalla-Waldschmidt

flavicon
face
Hallo Imre,

"Dr. Imre Bartfai" wrote:
>
> Hi,
>
> there is an AN for this. Look at Microchip website and/or their CD. I use
> the algorithm and it works fine.
>
> Imre
>

kannst Du bitte die Nummer der AN Posten ?
(engl.: could you pls. post the # of the mentioned AN ?)

Viele Gruesse

       Stefan Sczekalla-Waldschmidt
       .....sswKILLspamspam.....oikossw.de

1998\11\04@063232 by Dr. Imre Bartfai

flavicon
face
Hello all,
morning I will send the number of that AN. (Morgen werde ich die Nummer
des besagten AN's offenbaren.)

Imre

On Tue, 3 Nov 1998, Stefan Sczekalla-Waldschmidt wrote:

{Quote hidden}

1998\11\04@074618 by Gerhard Kammerer

flavicon
face
Hello,

the numbers are:

AN531 ... Intelligent Remote Positioner for PIC 16cXXX
AN532 ... Servo Control of a DC-Brush Motor for PIC 17cXX

Hope that helps

Gerhard

{Quote hidden}

1998\11\05@103135 by Dr. Imre Bartfai

flavicon
face
Hi All,

the AN531 & AN532 contain an example how to do the job.

Imre

1998\11\20@081657 by Dr. Imre Bartfai

flavicon
face
Hi All,

the AN531 & AN532 contain an example how to do the job.

Imre


'PID Control with PIC'
1998\12\28@133703 by John Payson
flavicon
face
|Hi, anyboby had worked with a PID control algorithm for the PIC 16Cxxx
|family.
|Thanks

Out of curiosity, what is so "magical" about PID loops?  If
the behavior of the system is not accurately known when the
loop is set up, it's likely to perform poorly and it would
seem that if the loop characteristics are known, it should
be possible to do better.

Certainly, if one is trying to design an analog positioning
circuit, a PID loop may be much easier than alternative meth-
ods, but within the digital domain it would seem like many
other techniques become available that should produce better
performance (and/or will produce comparable performance more
easily).

For example, if you are trying to move an object as quickly
as possible to a certain position, subject to the requirement
that accelleration/deccelleration as well as maximum speed need
to be kept below a certain level, a very simple algorithm would
be:

 Accellerate maximally until either speed is at maximum or unit
 has reached the point where maximal safe decelleration will land
 it at the desired point.

 If unit is not yet at the "start deccelerating" point above (i.e.
 if we stopped accelerating simply because we hit top speed) then
 just keep on cruising.

 Once we hit the point where we have to stop braking, do so.

As written, the algorithm leaves no room for error, but will produce
the fastest possible motion within the desired parameters.  To make
the routine safer, the slow-down section could be written somewhat
like the ways people might approach a stop sign in a car:

 Cruise until a point is reached where continuous "comfortable"
 deccelleration would result in a stop slightly before the stop
 sign.  Then start comfortably deccellerating there.

 Continuously evaluate the car's actual speed/velocity/decceler-
 ation to judge where it's going to stop if current trends con-
 tinue.  As the car slows down, set the "target" point closer and
 closer to the actual target.

Although a PID-based approach will often produce "smoother" motion
than approaches like the above "go as fast as safely possible"
methods, I don't know how much benefit there is in practice; cer-
tainly, running a system at the extreme edges of its operating range
may reduce lifespan, but it should be possible to determine values
comfortably within that range which should only be exceeded in case
of emergency.

Alternatively, if the smoothest possible operation is desired, it
should be possible for a microcontroller which knows the acc/dec
properties of the system as well as the deadline for completing
the motion to arrange for the move to happen as gently as possibly
while still meeting the deadline.  Again, this sort of thing may be
quite hard to do in the analog domain but should be fairly simple
to do digitally.

Is the preference for PID systems primarily a result of inertia, or
is there some other benefit that PID-modeled systems have over more
application-modeled ones?

1998\12\28@141838 by Peter L. Peres

picon face
On Mon, 28 Dec 1998, John Payson wrote:

> Is the preference for PID systems primarily a result of inertia, or
> is there some other benefit that PID-modeled systems have over more
> application-modeled ones?

PID servos can be designed in about 10 minutes using one of scores of
specialized code generators (which I've never used), and are, in general,
considered to be THE ground Rhino horn potion.

In reality, even a poor backlashing gear train in a model servo (between
the motor and the position pot) will ruin any chance of a good PID
approach to do its job, especially at inversion points and at small
deflections. A pure PID matched to a slow, heavy load used with a
backlashing gear train will oscillate when idle with almost 100%
probability, at least when settling.

There are also several people who sell newsletters on PID for $10 (?) in
newsgroups, same for Fuzzy logic. If someone is surfing in search for a
servo solution, he will pick either PID or Fuzzy and drop Fuzzy because it
is more complex. This leaves him with PID although he may actually need PD
or PI in reality (A PID with a zero in the resp. coefficient will do that
however, and the code generators sold, do that quietly, or so I am told).
So PID it is.

Peter

1998\12\28@160405 by Gerhard Fiedler

picon face
At 12:37 12/28/98 -0600, John Payson wrote:
>Is the preference for PID systems primarily a result of inertia, or
>is there some other benefit that PID-modeled systems have over more
>application-modeled ones?

if you know your acc and dec precisely, your approach is probably close to
optimum, but often that is not the case. if you don't know it, your
approach gets a bit more complicated, and probably eventually it becomes a
rule-based system like fuzzy.

i would tend to think that you're right and in many cases a pid approach is
not the best solution in the digital domain -- but it's easy to implement,
if you have the right parameters. which may not be so easy to get...

if i had to do a control loop, i would not go pid as a first approach, but
i can imagine that in some (many?) cases i would end up with some kind of
pid-like algorithm.

BTW, does anybody have experience with fuzzy-implementations?

ge

1998\12\28@192452 by Darren Logan

picon face
What ?


'PID control with PIC'
1999\01\06@151051 by Ryan Miller
flavicon
face
I have a project where I'm trying to improve a PID controller. The
controller controls the temp in a produce storage shed using 4-20mA output
to open and close a door to let in outside air for cooling (the produce
provides the heat). I'm using a PIC17C44, which gets the plenum temp, does
the calculations and then puts out a pwm signal which is converted to 4-20mA
to drive the door. The PID algorithm is based on the MChip app note and is,
as far as I can tell:

Output = PGain(error) + IGain(sum of errors) + DGain(previous error- new
error)

I had all this theory in school but its a long way from Z transforms to PIC
assembler so I have a few questions and hope that someone can enlighten me:

1. Is the integral ever intentionally cleared? It seems that the only way to
get rid of that value is to have a neg error for a while or to clear it.
Sitting at setpoint with no error, you can still have this factor working on
the system. I also found that it worked best to not even have an I term
until I was within one degree of setpoint.

2. Does anyone have a good way to scale the results of the above equation
(24bit) into a useful (8bit) number? I use the output for a pwm value and I
think this is where part of my problem is as the small corrections "get
lost".

3. Is the sampling time the "dt" in the integral and derivative or are those
values calculated at a different time? For example, my boss thinks that we
should calculate the integral on one second time intervals and then generate
an output every five seconds at which time the integral value is cleared.
This actually works fairly well until it gets really cold out and then the
temp drifts. I feel you lose the integral completely if you do this and it
is really an additional proportional gain.

Any insights would be appreciated.

Ryan

1999\01\07@035606 by

flavicon
face
{Quote hidden}

Correct.

{Quote hidden}

I never intentionally cleared the integral.  The integral is there to remove
offsets in the output which are an inevitable consequence of using a
proportional term.  Don't forget that even with zero error, the controller
still has to have some output.  The proportional term requires an error to
make this output, thus the offset.  The integral term will have an output
even when the error term is zero.

An important issue with integral terms is windup.  This occurrs if there is
a persistant large error, the integral term builds up and up.  This has two
possible implications.  The variable used to hold the I term could roll
over, causing very strange oscilations.  Even if this didn't happen, a
change in set point with a huge number in the I term would cause a massive
overshoot.  The thing to do here is to clamp the I term at a suitable value.
This is called anti-windup.

> 2. Does anyone have a good way to scale the results of the above equation
> (24bit) into a useful (8bit) number? I use the output for a pwm value and
> I
> think this is where part of my problem is as the small corrections "get
> lost".
>
All I did was to clamp it to ensure it could never exceed the range of my
A/D converter (10 bits in my case).  By choosing appropriate P,I and D terms
the output should not need scaling, thats the whole point of the exercise.

> 3. Is the sampling time the "dt" in the integral and derivative or are
> those
> values calculated at a different time? For example, my boss thinks that we
> should calculate the integral on one second time intervals and then
> generate
> an output every five seconds at which time the integral value is cleared.
> This actually works fairly well until it gets really cold out and then the
> temp drifts. I feel you lose the integral completely if you do this and it
> is really an additional proportional gain.
>
You should update the output every time you have a valid error term.  You
may want to sample the inputs more than once for filtering purposes if there
is any noise in the system.  Lawrence Lile will be only too pleased to tell
you about the benefits of a median filter and will even give you some code
:o)

As I said before, regularly zeroing the integral term defeats the whole
purpose of it's use.

A good starting point for finding the Proportional term is to zero the I and
D terms, and then progressively increase the P term until the system *just*
starts oscillating.  The use half that value.
There is a way to calculate the I & D term from the frequency for the
osciallation, but I don't have details here.  I just progressively increased
I until I had minimum error with an acceptable step response i.e. no massive
overshoots and good settling time.

You may well find that you don't even need the Derivative term.  It is there
to speed the response of the loop for rapidly changing inputs.  Thermal
systems often have a very slow response anyway
and makes the use of the D term redundant.

Hope this helps a bit

Mike Rigby-Jones
@spam@mrjonesKILLspamspamnortelnetworks.com

1999\01\07@085245 by Justin Grimm

flavicon
face
Rigby-Jones, Michael [PAI01:4837:EXCH] wrote:

> > I have a project where I'm trying to improve a PID controller. The
>
> You may well find that you don't even need the Derivative term.  It is there
> to speed the response of the loop for rapidly changing inputs.  Thermal
> systems often have a very slow response anyway
> and makes the use of the D term redundant.
>
>

The derivative term is used to speed up the response for an extremely slow
loop ie. temperature. If derivative were used on a fast changing process
variable the output would be out of control. This is because derivative
acts on the "rate of change of the input", the higher the rate of change,
the more the output is boosted. When the input stops changing, the output
returns to its PI value and derivative is disabled. When the temp is rising the
d term will boost the output up to provide an inrush of cool air until the temp
settles then the output will drop its "boost" and continue controlling with the
PI terms.
I suggest for long lags use the derivative term.

PID equations--

dMV = G[dE + E*T1*I + D* (dE/dT2)]

where:

dMV = Change in MV
G   = Gain
E   = Error (SP - PV reverse action) (PV - SP direct action)
dE  = Error this scan - error last scan
T1  = Time since error occured (min) (cleared when error = 0)
dT2  = Time between scans (min)
I   = Integral time (repeats/min)
D   = Derivative time (min)


--
JUSTIN GRIMM
Eclipse Energy Systems
http://www.geocities.com/SiliconValley/Ridge/1839/

1999\01\07@105905 by

flavicon
face
       <snip>

> The derivative term is used to speed up the response for an extremely slow
> loop ie. temperature. If derivative were used on a fast changing process
> variable the output would be out of control. This is because derivative
> acts on the "rate of change of the input", the higher the rate of change,
> the more the output is boosted. When the input stops changing, the output
> returns to its PI value and derivative is disabled. When the temp is
> rising the
> d term will boost the output up to provide an inrush of cool air until the
> temp
> settles then the output will drop its "boost" and continue controlling
> with the
> PI terms.
>
       <snip>
> --
> JUSTIN GRIMM
> Eclipse Energy Systems
> http://www.geocities.com/SiliconValley/Ridge/1839/
>
I'll admit, this makes sense.  However, the system I was using had a thermal
time constant of maybe 4 or 5 seconds, and we needed accuracy over and above
response time.   Adding a derivavtive term did not in any way improve the
response time of the system, and in fact slightly worsened the stability.
This seemed to be because the proportional term had enough gain to drive the
output to maximum for relatively modest errors.  The sytem being controlled
was a tunable laser, heated or cooled by a thermo electric cooler and it had
to keep the laser within 0.1 C of it's setpoint over the range 0 to 80 C
which it did achieve.  Apart from switch on, there should be no sudden large
errors , just a small long term drift which can be compensated by the P and
I terms.  Another reason we chose not to use Derivative is that the TEC can
take a lot of current (up to 1.5 amps) and the addition of a D term would
mean small errors could cause large current spikes, something we wished to
avoid.

What I am trying to say is that Derivative *may* not be needed, depending on
the application.   If you could accept the response may be slowed, the
reduction in complexity of the code and setting up may be worth it.

Regards

Mike Rigby-Jones

1999\01\07@110111 by Anders Friberg

flavicon
face
> Output = PGain(error) + IGain(sum of errors) + DGain(previous error- new
> error)

In a regulator application (constant setpoint) you may want to calculate the
DGain term differently depending on whether the error change was caused by a
change in setpoint or a change in the process value. The general idea is that
the DGain term will be disabled in the case of setpoint change, this eliminates
problems with large output swings etc after a possibly large (step) change in
setpoint. One way to ackomplish this could be to calculate the DGain term as
DGain(previous process value-new process value).

In a servo application however (setpoint not constant) the DGain term should be
calculated as above, DGain(previous error-new error) regardless of the cause of
the error change.

Maybe this is in the Microchip AN (have not read it yet)?

Regards,
Anders Friberg

1999\01\08@101636 by Lou Calkins

flavicon
face
>> 1. Is the integral ever intentionally cleared? It seems that the only way
>> to
>> get rid of that value is to have a neg error for a while or to clear it.

It is important to look at the system you are trying to control.  If you
have an air damper that you are controlling the position of somewhere
between opened and closed, then the damper itself is acting like the
integral term.  So when your process (actual temperature) reaches your
desired setpoint within some dead band, you would clear the integrating
action because the position of the damper is essentially the integral.

>Don't forget that even with zero error, the controller
>still has to have some output.  The proportional term requires an error to
>make this output, thus the offset.  The integral term will have an output
>even when the error term is zero.

No true in his situation with a damper control.  Well, it could be true if
the output of your algorithm is the position of the damper, then yes, there
would need to be some integral to hold the damper at the correct position
to maintain control.  Most dampers I am aware of use motors to drive in one
direction or the other to move them.  And then they stay still to hold
their position.

>An important issue with integral terms is windup.  This occurrs if there is
>a persistant large error, the integral term builds up and up.

Because the integral is used to account for losses in the system it really
is not useful when the setpoint is far away from the current temp.  So as
you stated earlier, I would clear the integral until the temp gets within
some band of the setpoint.

>> 2. Does anyone have a good way to scale the results of the above equation
>> (24bit) into a useful (8bit) number? I use the output for a pwm value and
>> I
>> think this is where part of my problem is as the small corrections "get
>> lost".

This is where it is desireable to have some integral function.  If there
are sustained errors especially small ones, they will remain unless the
integral is there to nudge the control to correct the error.

>> For example, my boss thinks that we
>> should calculate the integral on one second time intervals and then
>> generate
>> an output every five seconds at which time the integral value is cleared.

The only reason I can see for sampling more often than you are correcting
is to filter or smooth the input as stated below.

>You should update the output every time you have a valid error term.  You
>may want to sample the inputs more than once for filtering purposes if there
>is any noise in the system.

>As I said before, regularly zeroing the integral term defeats the whole
>purpose of it's use.

Not if the damper is holding a position and does not need to be moved.  You
really have to determine the type of actuator in the control loop.  If it
maintains its position with no signal to it, then it (the actuator's
position) effectively becomes the integral.

>A good starting point for finding the Proportional term is to zero the I and
>D terms, and then progressively increase the P term until the system *just*
>starts oscillating.  The use half that value.

Yes.  This is an excellent way to start.  When you are tuning I would
recommend a non-nonsense book by David St. Clair that discusses how to go
about tuning a system.  E-mail me at KILLspamlcalkinsKILLspamspamismi.net for more info if you
want it.

>You may well find that you don't even need the Derivative term.  It is there
>to speed the response of the loop for rapidly changing inputs.  Thermal
>systems often have a very slow response anyway
>and makes the use of the D term redundant.

Yes, and remember that there are lags and there are thermal mass delays
(not the same thing).  In the case of the produce temp controller, you
might have a lag if it is a long distance from the air inlet to the
temperature sensor.  Ideally, the distance should be as short as possible.
Also be careful not to update the controller output any more often than the
lag time.  So if it takes 5 seconds for the cooler air to get to the temp
sensor, there is no reason to correct the controller output any more often
than that.

>The derivative term is used to speed up the response for an extremely slow
>loop ie. temperature. If derivative were used on a fast changing process
>variable the output would be out of control. This is because derivative
>acts on the "rate of change of the input", the higher the rate of change ...

I would not recommend this.  The derivative should act on the rate of
change of the process (temperature).  Alternately, you could have the
derivative act on the rate of change of the error.  But not the rate of
change of the setpoint alone.

Boy, this group has more interesting discussions on controllers than the
sci.engr.control newsgroup.  That's because those guys are using
controllers - we are designing them!  I would recommend starting out simple
with your algorithm.  You will see where you need to make changes as you
evaluate its ability to maintain control.  Good luck.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...