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.

>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
16-bit quantity) I would be interested to see it, and I guess other people
would too.

>> 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..

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 course---for 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.

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
eye-opening that I will suggest it to others. I got involved with the process
of using phase-locked loops as FM detectors. PLL's are closed-loop 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 low-pass filter or maybe feed the PLL a signal whose deviation
is too great for the error-correction 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 closed-loop 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 744-7572 Stillwater, OK
OSU Center for Computing and Information services Data Communications Group

> 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

Does anyone have any recommendations for PID control loop articles or theory?
(Proportional-Integral-Derivative)
This seems to be the "standard" for a whole range of valve control algorithms in
industry
James

>Does anyone have any recommendations for PID control loop articles or theory?
>(Proportional-Integral-Derivative)
>This seems to be the "standard" for a whole range of valve control algorithms
>in industry
>James
Check out:

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 trial-n-error. 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.

>Does anyone have any recommendations for PID control loop articles or theory?
>(Proportional-Integral-Derivative)
>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.

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.
--

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 long-term 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?

> 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.

> 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 I-Term, 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 long-term 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 P-Term multiplier is to high. You should also
consider maximizing the summation of error for the I-term.

> 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 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 bang-bang 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}

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 fine-tuned
on the actual system. This factor is usually much, much lower than
the P-factor (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 set-points
where the I-factor 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 ;)

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.

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

|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.

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.