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:
formatting link
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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).
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.
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.
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:
As you probably know from control theory, the basic theory of a PID controller is that you have a system described by a set of linear differential equations that is inherently unstable or has some performance problems. As a result you strap a PID controller onto it (with said controller also described by its own linear differential equations), and the resulting system (now described by linear differential equations which are a mathematical mix of the underlying system and the PID controller) has better characteristics.
Did you notice that there is a word that appears many times in my description above?
Want to guess what the word is?
That word is "linear".
A system with a time delay is not described by linear differential equations. Strapping a PID controller onto it is bad math.
One of the more classic examples is a shower or an industrial process that mixes fluids of varying temperature and the sensor is located substantially downstream from the mixing value. This is a pure time delay. My shower at home is like that. I turn the water a little hotter. Nothing happens. I turn it a little more hotter. Nothing happens. Then I turn it a little more hotter. Then the wave of hot liquid hits me and I scream in agony.
Over time, I've adapted to my shower. I don't burn myself anymore.
I think the control algorithms you want to use for a system like yours fall outside the range of PID. I'm sure there is a body of theory that covers it, but I don't know what that is.
I would heat the system full bore for a fixed period of time, then stop and wait to see how the temperature catches up. And work from there.
The best control strategy for that system isn't going to be PID. That is a non-linear system.
Another problem faced with PID controllers is that they are linear. Thus, performance of PID controllers in non-linear systems (such as HVAC systems) is variable. Often PID controllers are enhanced through methods such as PID gain scheduling or fuzzy logic. Further practical application issues can arise from instrumentation connected to the controller. A high enough sampling rate, measurement precision, and measurement accuracy are required to achieve adequate control performance.
I don't know what the best control strategy is, but it ain't PID.
I've been resisting forking this over into the control newsgroup: now it's compelling.
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.
To be linear, a system only needs to satisfy the superposition property. A delay element satisfies superposition just fine.
And while a PID controller may not be the theoretically best controller for a system with delay, in many cases it's not a bad choice at all. PID controllers can and will give perfectly satisfactory service with plants that have significant delay. The thousands, if not millions, of PID controllers in mills and factories around the world that are controlling plants whose responses are dominated by delay certainly belie any declaration that the PID controller isn't a good choice to control a plant with delay.
None of the above is intended to minimize the difficulty in analyzing and designing a truly optimal controller for a plant with pure delay -- that's an exercise that can make your brain hurt, and fast. And nothing of the above is intended to chase you away from taking plant delays more directly into account if a discrete-state controller such as a PID won't let you eke the performance that you need out of your plant.
But in the absence of significant nonlinearities or time varying behavior you can use all the analysis tools that are suitable for linear time invariant systems on a system with delays just fine. You can do good design work, without ever having to explicitly write out the differential equations, much less solving them.
So if you don't want to get lost in Mathemagic Land searching for performance that isn't necessary for your product's success, a good ol' PID controller may be exactly the optimal controller -- in terms of adequate performance and reasonable engineering time -- even if it doesn't satisfy any egghead academic measure of "optimal" for the particular plant you're trying to control.
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.
There's also the time it takes the valve to move.
It's already linear. Just nasty.
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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
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.
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
formatting link
site and uses the IMC, internal model control, equations there for computing the gains. For a FOPDT Kc=3Dt1/((tc+dt)*K) ti=3Dt1 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
formatting link
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=3Dt1/((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
formatting link
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.
Well, if it's already linear you don't linearize it.
Take the system y = h(x, t) ==> y(t) = x(t - td). Testing this with superposition we get
y1(t) = x1(t - td), y2(t) = x2(t - td),
y1(t) + y2(t) = x1(t - td) + x2(t - td)
which is both h(x1, t) + h(x2, t) and h(x1 + x2, t) -- therefore the system is linear.
Note that as Jerry points out a shower isn't necessarily a linear system, unless your shower valve insures a constant flow and the pipes don't have any turbulence. Let a vastly simplified version be
y(t) = x(t - kd * x(t)),
(this doesn't capture the delay behavior in even a perfect pipe)
Speaking of overkill, why not just use an on-off thermostat with some hysteresis? Energy consumption? Lack of cool?
For that matter, how about modeling the whole range of coffeemakers that you expect (or that you're willing to warrant the device as working). Then see if you can get reasonable performance with just one tuning setting*. Then instead of telling the customer he can mess around with autotune, you can tell him he can just plug & play.
I've done this on blood pressure monitor; we expected to need four different tunings for the whole range of cuffs from 'premie arm' to 'fat guy thigh', and ended up needing just one.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.