PID autotuning - not working for heating application

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?

"Tim Wescott" <> 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).

"Tim Wescott" <> 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.

"Tim Wescott" <> 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.

"Frank W." wrote:

>"Tim Wescott" <> 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

Did you consider possible long time constants for "steady state"? Slow
warming of enclosures can ruin your model extraction.

And what is "heat", IOW how do you control the heater - phase angle,
full wave? As Tim wrote, there might be a nonlinear function. And if
you control a SCR without mains synchronisation, you might get huge
uncertainties for low power values.

>from room temperature to 95C takes ~1min, cooling takes hours (cooling from
>95C to 80C takes 15min).

1k/min : 70k/min = 1.4%, that's not so far off from 3.5% to assume
nonlinear behaviour. And your cooling experiment might be influenced
by a hot environment.

Oliver
--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

"Oliver Betz" <> wrote:
> And what is "heat", IOW how do you control the heater - phase angle,
> full wave?

Full wave. Phase angle is not permitted here with so much wattage.

> you control a SCR without mains synchronisation, you might get huge
> uncertainties for low power values.

The relay has a ZC circuit. 50hz power and 1s cycle time means 100 zero
crossings/cycle, ie. 1% granularity, equals 0.5% average error.

Datesfat Chicks wrote:
> "Tim Wescott" <> wrote in message
> news:...
>>
>> Systems with delay can be perfectly linear, as well as time invariant
>> -- they just can't be described by ordinary differential equations with a
>> finite number of states.
>
> Hi Tim,
>
> I might have missed something significant here.
>
> It is my assumption that a system with a pure time delay is inherently
> non-linear.

Superposition is sufficient proof of linearity. What comes out of a pipe
(assuming that there is no mixing in transit) is almost a delayed linear
superopsition of what is pushed into it, but it is not linear because it
is not a pure delay. When the input velocity increases because both hot
and cold water are flowing, the delay time decreases. Superposition
doesn't strictly apply because the time to look isn't well defined.

Any delay pushes a servo system toward unstable. That's not a linearity
problem.

> Let's take my shower example with a pure delay in the pipes ...
>
> With no delay, you can just say that
>
> Temperature(t) = Valve_Position
>
> or perhaps with a little thermal mass thrown in you can say that:
>
> d Temperature / dt = K * (Valve_Position - Temperature)
>
> where of course I'm assuming that valve position and water temperature
> are the same thing.

There's also the time it takes the valve to move.

> The first is I think a 0'th order linear differential equation and the
> second is a 1st-order LDE.
>
> But how would you linearize a system with a pure time delay, exactly?

It's already linear. Just nasty.

> The shower example with a pure pipe delay between the shower valve and
> my skin is fine.

But, as I wrote above, a pipe is onlt a pure delay as long as the flow
is constant.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On Nov 5, 9:37*am, "Frank W." <frankw_use...@mailinator.com> wrote:
> Is there a control engineering expert here?
Yes.
> Since all PID temperature controllers have Autotune, there must be a
> solution for this problem.
Some auto tuning algorithms are pretty crude and I think some
companies implement the simplest auto tuning algorithms just to say
they have one. It is a marketing thing. How are the customers to
know the difference? If they knew the difference they wouldn't need
the auto tuning.

> Any ideas?
Turn down the gain for one. It looks like the control output , gray
bar, amplitude is variable and not a simple on/off SSR.
Because the plant responds so quickly to the output I think the PID
update time should be faster but then the lack of resolution
will be a limitation. Using the derivative gain may be handy to but
again the lack of resolution will be a factor.
A tried and true method is the feed forward. If one know how much
control output is require for every temperature then one can compute
the control output and be with a percent or two without even using the
PID gains. The PID gains are just used to correct for errors in the
feed forward predictions.
You should be able to get very close with a feed forward and a
proportional gain. The integrator will simply remove the last bit of
error.

Auto tune works great when the plant matches the model AND the system
is properly excited. If not then auto tune doesn't work so well. Are
the water levels in the boiler constant? If not can the water level
be detected? Obviously the temperature will rise more slow or not as
fast if the boiler is full of water as opposed to being empty.

Does the tuning need to be better for a coffee machine? Manual tuning
should be easy enough.

When I get serious I prefer to make a model of the system. The
excitation requires a few steps in the control output. The steps
should be big enough so the response is clearly more significant than
the noise. The dead time should be clearly visible and the same goes
for the rise time. One can often get the plant gain, time constant and
dead time by inspection. If not then one must log the control output
and the response. Then one fits a FOPDT or SOPDT model to your coffee
machine. I do this using Scilab's optim or lsqrsolve. Then one goes
to the www.controlguru.com site and uses the IMC, internal model
control, equations there for computing the gains. For a FOPDT
Kc=t1/((tc+dt)*K)
ti=t1
Where:
Kc is the controller gain. It should have units of %output per
degree.
ti is the integrator time constant which is usually in minutes.
t1 is the plant time constant
dt is the dead time
K is the plant gain. This has units of degree per % control output.
tc is the closed loop time constant. tc is made smaller for more
aggressive tuning and longer for more conservative tuning. The value
for tc is dependent on the plant time constant and dead time. The
formula for tc on on the www.controlguru.com site.

You can see from the equation that the dead time reduces the gain.
Also, if the plant gain changes due to the water level then K will be
a function of water and the controller gain will then be modified as a
function of water level.
Kc=t1/((tc+dt)*K(WaterLevel))



I would start here. Once the plant gain, time constant and dead time
are know there are other options. On the www.controlguru.com site
there are formulas for adding the derivative time constant td. One
can also implement a Smith Predictor. A Smith Predictor isn't that
hard to implement. The hard part is finding the plant parameters.

I talked to someone else on the phone about making a high end coffee
or espresso machine a few months back. Our product was gross overkill
but would have made a nice research tool.

Peter Nachtwey

On Nov 10, 2:59*pm, Tim Wescott <t...@seemywebsite.com> wrote:
> Speaking of overkill, why not just use an on-off thermostat with some
> hysteresis?
Good idea, then there are no gains to tweak so coffee can be made
right away and the coffee drinking can begin. How accurate must the
temperature control be on a coffee maker and who would be able to tell
the difference between 85 and 86 degrees C? 85-86 degrees seems to be
a few degrees too low unless Frank W knows something the rest of the
world doesn't.

Peter Nachtwey

pnachtwey" <> wrote:

> unless Frank W knows something the rest of the world doesn't

Don't speak for the rest of the world if you are an ignoramus.

- With a thermostat, temperature swings are far more pronounced than you
claim. It's not just two degrees: The PID has reduced temperature swings of
~15 degree Celsius with the original thermostat to nearly nothing. Such
variations had a noticeable influence on taste (cold = sour). Here's a
PID-vs-thermostat temperature plot for a different, slightly higher-end 500$
home coffee machine which has even bigger 23.9C swings:
http://www.espressoparts.com/espress...a_tempplot.jpg
- An equally important benefit is that with a PID instead of a thermostat,
the PV is adjustable. Different beans/roasts call for different brew
temperature - roughly between 85 and 99 degree Celsius.