PID autotuning - not working for heating application
in [Embedded]
|
Prev: Artesyn BAJA PPC 750
Next: FPGA Soft Core CPUs
From: Frank W. on 6 Nov 2009 09:15 "Tim Wescott" <tim(a)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).
From: Tim Wescott on 6 Nov 2009 20:17 On Fri, 06 Nov 2009 15:15:08 +0100, Frank W. wrote: > "Tim Wescott" <tim(a)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
From: Frank W. on 9 Nov 2009 02:36 "Tim Wescott" <tim(a)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.
From: Tim Wescott on 9 Nov 2009 11:33 On Mon, 09 Nov 2009 08:36:52 +0100, Frank W. wrote: <begin restored context> > "Tim Wescott" <tim(a)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(a)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
From: Frank W. on 9 Nov 2009 14:32
"Tim Wescott" <tim(a)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. |