Forums

PID autotuning - not working for heating application

Started by Frank W. November 5, 2009
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" <tim@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" <tim@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" <tim@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" <tim@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" <tim@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" <tim@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 &#2013265925;str&#2013266166;m/H&#2013265924;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.