PID Heater Control

Excellent, I forgot to add that it has to be in the linear zone, at full power, it's power times heat capacity.

Half of me needs to find a new job, but if I stay where I am then a computer controlled thermal loop is in the future. An excuse to buy your book.

George H.

Tim, you aren't grasping the situation. I am not designing a controller. Someone else is. I have asked him why he is using a PID controller in the way he is and he isn't interested in discussing it. So I'm trying to understand why a PID controller might be used in that way. Adding a PWM to it doesn't help me understand how a PID can be used in the way it is being used.

I'm not seeing how it would turn the heater on and off again in the smaller cycles. If there was a decision made to turn the heat on with the temperature update, that heat would most likely remain on until the temperature reading was updated, no? I suppose it is possible that the D term might result in the threshold being crossed at the start and then reversed at the next cycle when the D term goes to zero. In fact, I can see this causing the heat to turn on when it is *not* desired because the temperature is above the set point.

Of course this is largely hand waving because a PID controller is not so easy to analyze with words. So if you say it may have a very slight advantage, I won't argue that point. But at best it seems it would be a vanishingly small advantage and even that would require the PID controller to be very well tuned to the task which might even require tuning for different items places in the oven giving very different thermal masses to the overall device.

This is not a "project" in any professional sense. An amateur is doing this has a home project. I just wanted to understand how the PID might be useful. So far I am still pretty convinced a set point controller will give virtually as good a result with less work and complication.

Lol. Without having faces I have a hard time remembering names and personalities. I have learned a few like John Larkin and Joerg. But I often mix up Tim Wescott and Jim Thompson just because the names "feel" similar to me. I believe Jim is the one with the far right politics that he shares a lot. I hope I'm not offending anyone by mixing up the two of you. Hmmm, I just realized you are the same guy I see in c.a.e. Thanks for the insight.

--

Rick

PWM-ing the heater, as long as it's faster than the relevant time constants, makes it act more like it's being driven in a linear fashion. In the extreme, if you PWM the thing within the heating element's time constant, it'll act close to "real" linear control.

The guy's design does sound way more elaborate than is necessary or even desirable -- if you did need a PID controller you could implement the PID part in about ten lines of code, and the Sigma-Delta modulator in another ten -- with room for comments.

Unless something strange is going on it wouldn't go in smaller cycles -- but the pulses could be shorter than the temperature read time.

Overall I think it would lead to a slight improvement, but "slight" is definitely the operative word.

Somewhere in one of the sub-threads I address that: yes, using linear control ends up meaning that you're subject to the need to tune. Having the on/off element saves you from that to some extent.

I think that applies to a lot of thermal loops. I have implemented thermal loops with PID control in the past, but that's where (1) the temperature control needed to be very fine indeed, (2) the cooling element was throttleable, and (3) the plant was fixed, with no need to work for anything from an empty oven to one filled with a turkey (or a crucible, or whatever).

Well, my left-wing friends all think I'm a right-wing wacko.

Of course, my right-wing friends all think I'm a left-wing wacko.

I am glad that they have something to agree on, I just wish it was something else.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

Next time I can save you some trouble typing. On Reddit they just type

TLDR

--

Rick

Bottom line as i see it,,,

your band bang controller can be thought of as only the P part of a PID controller.

If you add the I and the D parts you __may__ get faster and / or tighter control of the temperature at the expense of more complexity.

It sounds like you don't need the tighter control and don't want the additional complexity.

Fair enough.

Nothing to argue about

Mark

The classic PID controller drives a heater to any value from zero to 100%; it will cheerfully park heater output at 37% if that maintains a steady state (basically, within the offset-voltage errors of the temperature sensor).

But, a 'bang bang' controller will turn the heater fully ON (ramping upward in temperature), then fully OFF (ramping downward in temperature) and makes a triangle-wave temperature versus time curve.

The D part inhibits overshoot/undershoot, and the I part makes the temperature not go below the setpoint when heating is required, and not go above the setpoint when cooling is required.

If the gain (P) is 1.00 per C, then at 0.37 heat (that's the thirty-seven-percent point) the error temperature for a P controller, (T - Tset), is

T - Tset = - 0.37 / P = -0.37 Celsius

With an I term of 1 per Celsius-second, that deviation vanishes in a few milliseconds.

Yup.

I think it's best not to conflate the "dimensions" of the control algorithm itself (proportional to error, integral of error, and time-differential of error) with the quantization of the control output (two-state as in bang-bang, multi-state off/low/medium/high, or continuous). Consider 'em separately and then figure out how they interact.

I have an GPS-disciplined frequency standard whose internal TCVCXO is somewhat sensitive to room temperature (its oven isn't perfect). The controller output is a near-continuous function - it tweaks the voltage control for the oscillator with extremely fine granularity.

The original control algorithm was purely proportional. When room temperature was changing, it was *always* "behind" - its adjustments would follow the temperature change but wouldn't catch up until the temperature stabilized. That's inevitable - a P algorithm has no memory and can't "see the trend", and it can't issue a correction unless there's an error.

By switching to a PI algorithm, the average error was reduced by about

95% at these times. There's a bit of overshoot and some well-damped "ringing", but on average it's a great deal closer.

I think one would consider a classic thermostat with an anticipator to be a PD controller, with a two-state (full-on, full-off) output. The anticipator will reduce overshoot by providing an (estimated) differential term. Since there's no "I" term, a thermostat of this sort will tend to lag temperature drift from external causes.

On the original question: frankly, I don't think there's anything significant to be gained by running a PID-controller algorithm faster than the temperature sensor takes new samples, *if* you have a continuously-variable (or finely-quantized) control output (i.e. one which allows for proportional output).

If you don't - if e.g. the heater is necessarily bang-bang (e.g. a solid-state relay controlling an electric heater) then you can run at least a portion of the PID code more frequently, to PWM the heater and thus simulate true proportional control. The PID code wouldn't need to recalculate the output proportion more than once per sensor- measurement period, though - I don't see there's a reason to do so since it won't have any new information available between samples.