Truncated match.
PICList
Thread
'PID Control with PIC'
1998\10\29@220038
by
Facundo Cestona
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
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
Hi Imre,
working on PIDcontrollers with PIC I«m highly interested in some codings
too!
Please send me an email according to your experiences.
Thanx in award and greetings from MŸnster!
Wolfgang
UrsprŸngliche Nachricht
Von: Dr. Imre Bartfai <spam_OUTrootTakeThisOuTPROF.PMMF.HU>
An: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU <PICLISTKILLspamMITVMA.MIT.EDU>
Datum: Montag, 2. November 1998 19:57
Betreff: Re: PID Control with PIC
{Quote hidden}>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
>>
>>
>
1998\11\03@042620
by
Stefan SczekallaWaldschmidt
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 SczekallaWaldschmidt
.....sswKILLspam.....oikossw.de
1998\11\04@063232
by
Dr. Imre Bartfai
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 SczekallaWaldschmidt wrote:
{Quote hidden}> 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 SczekallaWaldschmidt
>
EraseMEsswspam_OUTTakeThisOuToikossw.de
>
>
1998\11\04@074618
by
Gerhard Kammerer
Hello,
the numbers are:
AN531 ... Intelligent Remote Positioner for PIC 16cXXX
AN532 ... Servo Control of a DCBrush Motor for PIC 17cXX
Hope that helps
Gerhard
{Quote hidden}>
> 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 SczekallaWaldschmidt wrote:
>
> > 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 SczekallaWaldschmidt
> >
sswspam_OUToikossw.de
> >
> >
1998\11\05@103135
by
Dr. Imre Bartfai
Hi All,
the AN531 & AN532 contain an example how to do the job.
Imre
1998\11\20@081657
by
Dr. Imre Bartfai
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

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 slowdown 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 PIDbased 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 PIDmodeled systems have over more
applicationmodeled ones?
1998\12\28@141838
by
Peter L. Peres

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 PIDmodeled systems have over more
> applicationmodeled 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
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 PIDmodeled systems have over more
>applicationmodeled 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
rulebased 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
pidlike algorithm.
BTW, does anybody have experience with fuzzyimplementations?
ge
1998\12\28@192452
by
Darren Logan
What ?
'PID control with PIC'
1999\01\06@151051
by
Ryan Miller

I have a project where I'm trying to improve a PID controller. The
controller controls the temp in a produce storage shed using 420mA 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 420mA
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

{Quote hidden}> I have a project where I'm trying to improve a PID controller. The
> controller controls the temp in a produce storage shed using 420mA 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
> 420mA
> to drive the door.
>
> My first PIC project was a PID controller, talk about diving in at the
> deep end....
> There seems to be two schools of throught on PID control design. One says
> you sit down for days and make many lengthy calculations about loops
> gain, phase margin etc. The other says fiddle with loop parameters until
> it works ok. I went for the second approach and it worked for me!
>
> 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)
>
Correct.
{Quote hidden}> 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.
>
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 antiwindup.
> 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 RigbyJones
@spam@mrjonesKILLspamnortelnetworks.com
1999\01\07@085245
by
Justin Grimm

RigbyJones, 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

<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 RigbyJones
1999\01\07@110111
by
Anders Friberg
> 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 valuenew process value).
In a servo application however (setpoint not constant) the DGain term should be
calculated as above, DGain(previous errornew 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

>> 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 nonnonsense book by David St. Clair that discusses how to go
about tuning a system. Email me at KILLspamlcalkinsKILLspamismi.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...