Is there a control engineering expert here?

I could us a bit of help on how to implement a PID autotune function for a
heating application (a small boiler).

My current PID autotune function produces no reliable results. I use the
relay feedback method (Åstrom and Hägglund) but it seems that the ultimate
period Tu - one of the paramters determined with the relay feedback test -
is directly correlated to the relay output step u. u is an arbitrary value
which makes Tu an arbitary value. Since Tu is required to compute Ti and Td
(e.g. Ti = 0.5 Tu = Ziegler-Nichols), autotune is not possible.

I believe this is because the machine heats very quickly (1500W boiler) and
cools down very slowly, so the process value isn't a sinusoid. Here is an
example graphics, green line is setpoint, red plot is process value and the
grey vertical bars represent heat output u:

http://img196.imageshack.us/img196/7409/examplejr.jpg

Regardless of u, the temperature always dips the same, small amount below
setpoint - because the machine cools slowly, the temperature can not fall
far below setpoint before it's reacting to the heat. It then shoots up by an
amount that is proportional to u. As a result, the plot resembles mountains
above setpoint. If u is large, temperature will shoot high above the
setpoint and take very long to cool down. Big mountains, so Tu gets large,
Tu ~ u = my problem.

Since all PID temperature controllers have Autotune, there must be a
solution for this problem. Any ideas? 

Frank W. wrote:

> Is there a control engineering expert here?

You can contact Tim Wescott who is the expert in control systems, 
however the problem is not really a rocket science.

> I could us a bit of help on how to implement a PID autotune function for a
> heating application (a small boiler).

It looks like a huge lag in the control loop. PID approach won't work 
very well. Is your heater on-off type or proportionally regulated?

> Since all PID temperature controllers have Autotune, there must be a
> solution for this problem. Any ideas? 

To begin with, abandon autotune and see if you can get good control by 
manual adjustment of parameters.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Frank W. wrote:
> Is there a control engineering expert here?
> 
> I could us a bit of help on how to implement a PID autotune function for a
> heating application (a small boiler).
> 
> My current PID autotune function produces no reliable results. I use the
> relay feedback method (Åstrom and Hägglund) but it seems that the ultimate
> period Tu - one of the paramters determined with the relay feedback test -
> is directly correlated to the relay output step u. u is an arbitrary value
> which makes Tu an arbitary value. Since Tu is required to compute Ti and Td
> (e.g. Ti = 0.5 Tu = Ziegler-Nichols), autotune is not possible.
> 
> I believe this is because the machine heats very quickly (1500W boiler) and
> cools down very slowly, so the process value isn't a sinusoid. Here is an
> example graphics, green line is setpoint, red plot is process value and the
> grey vertical bars represent heat output u:
> 
> http://img196.imageshack.us/img196/7409/examplejr.jpg
> 
> Regardless of u, the temperature always dips the same, small amount below
> setpoint - because the machine cools slowly, the temperature can not fall
> far below setpoint before it's reacting to the heat. It then shoots up by an
> amount that is proportional to u. As a result, the plot resembles mountains
> above setpoint. If u is large, temperature will shoot high above the
> setpoint and take very long to cool down. Big mountains, so Tu gets large,
> Tu ~ u = my problem.
> 
> Since all PID temperature controllers have Autotune, there must be a
> solution for this problem. Any ideas? 
> 
As someone else said: try manually adjusting parameters, instead. Do you 
really need autotune? If the boiler/heater/load/setpoint don't change 
much, then twiddle the parameters until you like the result.

That said, there are at least a dozen algorithms for autotuning. They 
fall into two basic methods (relay and step), but the parameters they 
generate can be quite different due to the different desired responses 
(e.g. "fastest to reach a certain error after a step change in setpoint" 
vs "little or no overshoot after a disturbance", etc.). You have to be 
clear about what you're trying to do before you bother trying to tune it.

Large delay and overshoot are common to heater control loops. Placing 
the sensor as close as possible to the heater can help, but then you 
might not be measuring the thing you want hot. I just had a (maybe) 
similar problem that included a requirement for a smooth ramp of the 
temperature. That led me to close the loop around the slope (calculated 
with an extremely simple FIR filter) during ramping. The slope-loop 
worked far better than trying get the temperature-loop to follow a 
ramping setpoint.

YMMV
Bob

On Thu, 05 Nov 2009 13:09:43 -0600, Vladimir Vassilevsky wrote:

> Frank W. wrote:
> 
>> Is there a control engineering expert here?
> 
> You can contact Tim Wescott who is the expert in control systems,
> however the problem is not really a rocket science.

Or you can wait for him to get around to doing the newsgroup thang.

(thanks for the plug).

I'll bet there's rockets out there with temperature loops.

>> I could us a bit of help on how to implement a PID autotune function
>> for a heating application (a small boiler).
> 
> It looks like a huge lag in the control loop. PID approach won't work
> very well. Is your heater on-off type or proportionally regulated?
> 
>> Since all PID temperature controllers have Autotune, there must be a
>> solution for this problem. Any ideas?
> 
> To begin with, abandon autotune and see if you can get good control by
> manual adjustment of parameters.
> 
Ditto -- try it by hand, and go from there.

-- 
www.wescottdesign.com

On Thu, 05 Nov 2009 18:37:21 +0100, Frank W. wrote:

> Is there a control engineering expert here?
> 
> I could us a bit of help on how to implement a PID autotune function for
> a heating application (a small boiler).
> 
> My current PID autotune function produces no reliable results. I use the
> relay feedback method (Åstrom and Hägglund) but it seems that the
> ultimate period Tu - one of the paramters determined with the relay
> feedback test - is directly correlated to the relay output step u. u is
> an arbitrary value which makes Tu an arbitary value. Since Tu is
> required to compute Ti and Td (e.g. Ti = 0.5 Tu = Ziegler-Nichols),
> autotune is not possible.

Are you sure you haven't just stopped too soon in turning the output step 
down?  I see where you're having trouble with this; is there some reason 
you can't turn u down even further?  Things may start looking better when 
you get it down to where the temperature curve is roughly symmetrical 
around the average.

> I believe this is because the machine heats very quickly (1500W boiler)
> and cools down very slowly, so the process value isn't a sinusoid. Here
> is an example graphics, green line is setpoint, red plot is process
> value and the grey vertical bars represent heat output u:
> 
> http://img196.imageshack.us/img196/7409/examplejr.jpg
>
> Regardless of u, the temperature always dips the same, small amount
> below setpoint - because the machine cools slowly, the temperature can
> not fall far below setpoint before it's reacting to the heat. It then
> shoots up by an amount that is proportional to u. As a result, the plot
> resembles mountains above setpoint. If u is large, temperature will
> shoot high above the setpoint and take very long to cool down. Big
> mountains, so Tu gets large, Tu ~ u = my problem.
> 
> Since all PID temperature controllers have Autotune, there must be a
> solution for this problem. Any ideas?

Why do you want to use autotune?  If this is a product that you're 
working on, and if the boiler design is the same for all of the parts 
that you ship, then you should just need one tuning.

Autotune is for when you're selling a shrink-wrapped controller that has 
to work for anything -- and autotune is often considered to be a good way 
to get the tuning in the ballpark so that a human can get involved and 
actually make it work right.

Unless you need to adapt to a variety of different, unexpected boiler 
combinations -- that don't change as the boiler is operating -- then 
there's not much value in autotune, IMHO.

-- 
www.wescottdesign.com

"Tim Wescott" <t...@seemywebsite.com> wrote:

> you can't turn u down even further?

A bit. Sensor resolution is the limit. The temperature hardly drops below
the setpoint during relay test iterations because the system cools so slowly
(it drops 0.3 degree below setpoint in case of my machine's 200ml boiler),
so making it nearly symmetric creates a PV signal with very few steps.

>  Things may start looking better when

I didn't say that the results are bad. It's just that I don't know which of
the results to pick since every variation of the relay output step produces
a different ultimate period. The lower u is made, the lower Tu gets (there
is no lower limit).

> Why do you want to use autotune?  If this is a product that you're
> working on, and if the boiler design is the same for all of the parts
> that you ship, then you should just need one tuning.

The algorithm is for a semi-commercial PID controller for coffee machines,
so autotune can not be left out since users expect it. Boiler sizes rougly
vary from 200ml to a few thousand ml. Wattage varies not so much (from
1250W-2500W). 

On Fri, 06 Nov 2009 15:15:08 +0100, Frank W. wrote:

> "Tim Wescott" <t...@seemywebsite.com> wrote:
> 
>> you can't turn u down even further?
> 
> A bit. Sensor resolution is the limit. The temperature hardly drops
> below the setpoint during relay test iterations because the system cools
> so slowly (it drops 0.3 degree below setpoint in case of my machine's
> 200ml boiler), so making it nearly symmetric creates a PV signal with
> very few steps.
> 
>>  Things may start looking better when
> 
> I didn't say that the results are bad. It's just that I don't know which
> of the results to pick since every variation of the relay output step
> produces a different ultimate period. The lower u is made, the lower Tu
> gets (there is no lower limit).
> 
>> Why do you want to use autotune?  If this is a product that you're
>> working on, and if the boiler design is the same for all of the parts
>> that you ship, then you should just need one tuning.
> 
> The algorithm is for a semi-commercial PID controller for coffee
> machines, so autotune can not be left out since users expect it. Boiler
> sizes rougly vary from 200ml to a few thousand ml. Wattage varies not so
> much (from 1250W-2500W).

It sounds like an ideal application for autotune -- you have a wide and 
uncontrolled product range, so you can't just make a 'one size fits all' 
tuning.  On the other hand your plants are constrained to a certain class 
of systems, so your basic problem isn't so wide open as to be impossible.

Any sort of tuning exercise involves making some assumptions about the 
system you're controlling, poking it with some excitation, seeing how it 
responds, then formulating a controller for the thing.  In some cases you 
have a step in there where you create a mathematical model of your plant, 
in others you don't.  The process is the same with autotuning, except 
that you hope to have a machine doing the tedious bits for you, instead 
of you having to run around the world tuning up coffee makers.

The Aostroem-Haggluend method never develops that explicit model, nor 
does it work with just any old excitation -- it just pokes the system in 
a specific way, extracts some parameters that aren't really closely 
related to what control theorists are used to (but which are practically 
quite useful), then gets PID tuning parameters from those measured system 
parameters.

Your problem is that you're not really poking the system in quite the 
right way, so the Aostroem-Haggluend method is breaking down for you.

Clearly there are two ways you can go:  one, poke the system the _right_ 
way, and two, abandon the A-H method.  You _could_ use excitation and 
response with more 'university' style adaptive control methods to derive 
a system model and develop a controller -- this is not a bad way to go if 
you're comfortable wrangling the math.  Or you can try to fix your 
excitation, or you can use the open-loop A-H method of data collection.

Have you tried turning your drive way down and adding some substantial 
hysteresis to your relay function?  I.e. instead of the relay being a 
static rule that says "output = on if above threshold, output = off if 
below", you make the rule say "go from off to on if above a low 
threshold, go from on to off if above a high threshold".  Make the two 
thresholds far enough apart (5 or 10 degrees?) to insure you capture good 
data, then find a value for your drive that seems to give good results 
for a variety of boiler sizes.

Or you can use the open-loop A-H -- this is actually the original method 
that Ziegler and Nichols used (as far as I know).  In it you start from 
steady state, make a step change in the drive, and look for a ramp 
response in the output.  You deduce gain and delay from the slope of the 
ramp and the delay from that ramp to an ideal 'immediate' ramp.  In your 
case you probably want to take off from a fairly hot temperature, so you 
may want to get up to your launch temperature with a really, really slow 
integrator-only loop or some other means that'll get you at a steady 
temperature safely.  Once you're at a constant temperature and drive, you 
can step the drive and start collecting data points on the response.

Or hire me :-).

-- 
www.wescottdesign.com

"Tim Wescott" <t...@seemywebsite.com> wrote:

> you're not really poking the system in quite the right way

Possible. The original method is: if the process value crosses sepoint, the 
heat is turned on (below setpoint) or off (above). One has to determine 
steady state output (us) first and apply steps to the heating element on 
this basis: heat = us +- u. This limits heat output if you want to avoid 
getting into saturation: if us = 6%, as it is in my case, then you can not 
have larger output steps than 6% (to avoid getting below 0%), ie. power 
swings from 0% to 12%. Since that's too low to generate peaks that I can 
measure with good resolution, I deviate from the inherent step limit of the 
original algorithm and excite the system with larger steps (e.g. 0 - 25% = 
+-12.5%). I'm now trying to minimize the possible effect of this deviation 
my incrementally reducing u until I have swings that are just big enough to 
be measured with resaonable resolution.

> Or you can use the open-loop A-H -- this is actually the original method
> that Ziegler and Nichols used (as far as I know).  In it you start from
> steady state, make a step change in the drive, and look for a ramp
> response in the output.

I don't think this would work any better because this test requires special 
osciallations, too. There are very fast PV rises in my system because the 
sensor is on the outside of a thick, small die-cast aluminium boiler and 
close to strong heating elements. And there are very slow declines, dictated 
by the small, natural heat dissipation of a water-filled boiler (no flow). 
That means I can't find the special P that creates oscillations because all 
do: even a small P will cause forced oscillatations of PV because the system 
is dampend so much in one direction. 

On Mon, 09 Nov 2009 08:36:52 +0100, Frank W. wrote:
	<begin restored context>
> "Tim Wescott" <t...@seemywebsite.com> wrote:
> 
>> you can't turn u down even further?
> 
> A bit. Sensor resolution is the limit. The temperature hardly drops
> below the setpoint during relay test iterations because the system cools
> so slowly (it drops 0.3 degree below setpoint in case of my machine's
> 200ml boiler), so making it nearly symmetric creates a PV signal with
> very few steps.
> 
>>  Things may start looking better when
> 
> I didn't say that the results are bad. It's just that I don't know which
> of the results to pick since every variation of the relay output step
> produces a different ultimate period. The lower u is made, the lower Tu
> gets (there is no lower limit).
> 
>> Why do you want to use autotune?  If this is a product that you're
>> working on, and if the boiler design is the same for all of the parts
>> that you ship, then you should just need one tuning.
> 
> The algorithm is for a semi-commercial PID controller for coffee
> machines, so autotune can not be left out since users expect it. Boiler
> sizes rougly vary from 200ml to a few thousand ml. Wattage varies not so
> much (from 1250W-2500W).

It sounds like an ideal application for autotune -- you have a wide and 
uncontrolled product range, so you can't just make a 'one size fits all' 
tuning.  On the other hand your plants are constrained to a certain class 
of systems, so your basic problem isn't so wide open as to be impossible.

Any sort of tuning exercise involves making some assumptions about the 
system you're controlling, poking it with some excitation, seeing how it 
responds, then formulating a controller for the thing.  In some cases you 
have a step in there where you create a mathematical model of your plant, 
in others you don't.  The process is the same with autotuning, except 
that you hope to have a machine doing the tedious bits for you, instead 
of you having to run around the world tuning up coffee makers.

The Aostroem-Haggluend method never develops that explicit model, nor 
does it work with just any old excitation -- it just pokes the system in 
a specific way, extracts some parameters that aren't really closely 
related to what control theorists are used to (but which are practically 
quite useful), then gets PID tuning parameters from those measured system 
parameters.

Your problem is that you're not really poking the system in quite the 
right way, so the Aostroem-Haggluend method is breaking down for you.

Clearly there are two ways you can go:  one, poke the system the _right_ 
way, and two, abandon the A-H method.  You _could_ use excitation and 
response with more 'university' style adaptive control methods to derive 
a system model and develop a controller -- this is not a bad way to go if 
you're comfortable wrangling the math.  Or you can try to fix your 
excitation, or you can use the open-loop A-H method of data collection.

Have you tried turning your drive way down and adding some substantial 
hysteresis to your relay function?  I.e. instead of the relay being a 
static rule that says "output = on if above threshold, output = off if 
below", you make the rule say "go from off to on if above a low 
threshold, go from on to off if above a high threshold".  Make the two 
thresholds far enough apart (5 or 10 degrees?) to insure you capture good 
data, then find a value for your drive that seems to give good results 
for a variety of boiler sizes.

Or you can use the open-loop A-H -- this is actually the original method 
that Ziegler and Nichols used (as far as I know).  In it you start from 
steady state, make a step change in the drive, and look for a ramp 
response in the output.  You deduce gain and delay from the slope of the 
ramp and the delay from that ramp to an ideal 'immediate' ramp.  In your 
case you probably want to take off from a fairly hot temperature, so you 
may want to get up to your launch temperature with a really, really slow 
integrator-only loop or some other means that'll get you at a steady 
temperature safely.  Once you're at a constant temperature and drive, you 
can step the drive and start collecting data points on the response.
	<end restored context>

> "Tim Wescott" <t...@seemywebsite.com> wrote:
> 
>> you're not really poking the system in quite the right way
> 
> Possible. The original method is: if the process value crosses sepoint,
> the heat is turned on (below setpoint) or off (above). One has to
> determine steady state output (us) first and apply steps to the heating
> element on this basis: heat = us +- u. This limits heat output if you
> want to avoid getting into saturation: if us = 6%, as it is in my case,
> then you can not have larger output steps than 6% (to avoid getting
> below 0%), ie. power swings from 0% to 12%. Since that's too low to
> generate peaks that I can measure with good resolution, I deviate from
> the inherent step limit of the original algorithm and excite the system
> with larger steps (e.g. 0 - 25% = +-12.5%). I'm now trying to minimize
> the possible effect of this deviation my incrementally reducing u until
> I have swings that are just big enough to be measured with resaonable
> resolution.
> 
>> Or you can use the open-loop A-H -- this is actually the original
>> method that Ziegler and Nichols used (as far as I know).  In it you
>> start from steady state, make a step change in the drive, and look for
>> a ramp response in the output.
> 
> I don't think this would work any better because this test requires
> special osciallations, too. There are very fast PV rises in my system
> because the sensor is on the outside of a thick, small die-cast
> aluminium boiler and close to strong heating elements. And there are
> very slow declines, dictated by the small, natural heat dissipation of a
> water-filled boiler (no flow). That means I can't find the special P
> that creates oscillations because all do: even a small P will cause
> forced oscillatations of PV because the system is dampend so much in one
> direction.

I hear an attempt at a logical, 'software engineer's' description of the 
behavior of the system.  "First event A happens, which causes event B, 
then event C happens, which causes event D, etc.".  This is sensible for 
most problems that one solves with embedded code, but it isn't a way that 
works for most control loops -- mostly because in a dynamic system like 
this, even if the driving force can be separated into discrete events, 
the response to the driving force gets spread out all over everything.

I do not believe that your temperature response to heat input is as 
nonlinear as you think it is.  This is partially because in my experience 
thermal systems themselves are pretty linear (and therefore act the same 
in both directions), and partially because looking at your graph I don't 
see any true signs of underdamped behavior -- I see a system that is 
responding to asymmetrically, yes, but it looks like a linear response to 
an asymmetrical input.

To hazard a guess, I'd say that one way or another when you command a 6% 
drive to your heater you're getting 1/4 as much heat as when you command 
a 12% drive -- almost as if you're commanding a steady voltage to the 
heater, or you're commanding the timing on an SCR drive, or something.  
The response that you're getting looks very much like the response you'd 
expect with a 3/4 'on' drive, and a -1/4 'off' drive, which is consistent 
with an ambient cooling at your set point temperature that's 1/4 as 
strong as the heating you get when the thing is on.

If you're really exciting a nonlinearity in the heating system you want 
to find it and characterize it now, rather than struggling with 
mysterious voodoo code for the rest of your career.

My recommended method would be to do it by analysis, but since you're 
already set up for measurements, making a chart of heater commands vs. 
final temperature, from 0 up through whatever gets to the maximum water 
temperature you can tolerate (I'd go for a gentle simmer, unless that 
causes some non-reversible safety mechanism to go off).  If the chart 
shows a curved line you have a nonlinearity in your drive that you need 
to deal with (otherwise you have a nonlinearity somewhere else).

-- 
www.wescottdesign.com

"Tim Wescott" <t...@seemywebsite.com> wrote:

> To hazard a guess, I'd say that one way or another when you command a 6% 
> drive to your heater you're getting 1/4 as much heat as when you command a 
> 12% drive

95C steady state with 7% heat and 80C steady state with 3.5% heat. Heating 
from room temperature to 95C takes ~1min, cooling takes hours (cooling from 
95C to 80C takes 15min).

Ultimate gain can be computed just fine, it doesn't matter much what output 
steps are used during autotuning. The  Åström/Hägglund result is always ~25% 
Kc gain and that works fine and seems right; manual tuning suggests a 
similiar value.

It was only ultimate period that gave me problems. Different excitations 
during autotuning result in different periods. However, after the recent 
changes (minimizing excitation with the goal of creating autotuning peaks 
that are as small as possible but large enough to exceed sensor resolution, 
thus turning the curve more into a sinus), it seems I get fairly consistent 
results that work: Td is calcluated as 2.5s. Manual tuning suggests 1.6s. 
That's good enough for me, so I consider the case closed. Thanks for your 
help, Tim.