Lawrence Lile wrote:

> > From:   Peter Homann[SMTP:peterh@ADACEL.COM.AU]
>
> > I'm investigating using a cheap toaster oven as a SMD reflow oven
> > for prototype boards.
> >
> > The idea is to use a PIC in provide an accurate temperature
> > controller, possibly providing a programmable temperature profile
> > capability.
>
> I just designed a new toaster oven with a PIC at the heart of the
> controller.  The requirement was for cheap, not for accurate, so I
> cut a lot of corners on accuracy.    All the PIC is really doing is
> analog comparing the thermistor voltage to a potentiometer voltage.
> etcettera..

Lawrence! I am truly impressed with the toaster! Does Microchip know
that you ripped off their ultimate design that they had in that ad
campaign for a while?  Just joking.. everything should have a PIC in
it.  I haven't figured out how to get them into common hand tools yet..

Back on PID, I have just finished a motor speed controller using PID and
PWM on a '73.  It was a little squirley for a while, but worked out in
the end.  Post script, I bought one of the books that Andrew suggested a
while back, "Controller tuning and control loop performance' by David W.
St. Clair, 302-731-4699.  Andy truly uncovered a jewel, this book has
nothing on programming it, but getting PID to work in the field might be
described as black majic sometimes, and this book puts it all in
practical measurable terms.

But back on programmin PID, I managed to stay in the 8 bit domain, by
reading motor voltage and command setting, taking the difference for
error, and driving a single ended switch circuit with the PWM output.  I
implemented P, I, PI, and ramp limit (accel decel limit).  I didn't do D
term, as it is rarely needed or used.  The terms are, in the briefest of
review,

P term: the product of the error and a constant:  Use a pot on an input
to allow adjustment.  P term has no internal knowledge of the last
state, and makes it's output calculation based upon each new pass.  If
the loop gain reaches or exceeds 1, the output device will oscillate.
For this reason, the gain must be reduced to a marginal value.  P term
is conceptually incapable of reaching the setpoint, steady state, as if
you ever reached it, the error is zero, and suddenly the output is back
to zero.  It can only ever achieve a percentage, say 80%, of the true
setpoint ( and still be stable).  Just a side note, since I didn't use a
full bridge, and thus didn't use signed math, when the error goes
nagative (indicating slow down) I could do no more than slam to 0 for a
while and let inertia pull the spped down.  True high spped servo
controllers are going to use the full bridge and signed word math.

I term: The I term is a memory function.  I is for integral and as
predicted it integrates the error.  The longer the error is large, the
harder the I term acts to counter the error.  I prefer to think of the
term as the seek term.  Many books have complex units that indicate a
reset time, etc., but I simplify by using TMR0 to count off a time
period, which is pot adjustable, and when the timer kicks it off, you
execute the addition or subtraction of some constant.  I is nice, as you
can achiev your true setpoint within a fine error.  The drawback is that
it will windup, a case where an error will build up an extra output
effort, but when the disturbance passes, the device tends to surge
forward ( or temp peaks hard, or whatever).  My client seemed to
associate this term with torque (I dunno) because if he held the shaft,
it fought to overcome the disturbance.  He liked that.

PI: It is best to combine PI, as I implemented it you just add the two
terms.  For tuning the system properly, I refer you to the book above.
This tends to combine the best features of all of the terms above.

My customer wanted a rate of change limit.  Take care to apply the limit
at the right point in the software.  If you limit the final command
value going to the PWM register, then the I term goes nuts while the
thing is coming up to speed.  It wasn't pretty.  Limit the ramp or rate
of change to the command input.  For any step change, let the internal
command register bleed up or down to the actual conmmand value.  This
way the PID loop can achieve the true speed all of the way along the
ramp.

I cannot post the code, as it belongs to my customer now.  But there is
my two cents, if anyone wants to try out any of my approaches, just mail
private and I can impart the finer details.  Or mail public if you think
people may benefit.

Chris Eddy
Pioneer Microsystems, Inc
Pittsburgh, PA 15106
www.nb.net/~ceddy