In other words, some poor workman decided to blame his tools.
Basically. More specifically, “fuzzy logic” was all the rage, and some programmer who didn’t know jack shit about process control decided that fuzzy logic was all you needed to know. Like some other fads that have come and gone, it was seen as such a natural and elegant solution to all imaginable computational problems that they forgot that you still need to know your subject matter too if you want to write programs that work.
Kind of like “Object Oriented Programming” today which is sometimes seen as such a miracle programming technique that it’s all you need to know, and then all your programming problems will just like magic, solve themselves. :smack:
There are fuzzy logic systems that are used to tune PID controllers. That makes more sense than fuzzy logic ab-initio. As noted above, PID controllers are funny devices to tune right. But something like an oven is likely to be well within the capability many of the modern self tuning algorithms, as it is neither hard, nor unusual.
The idea of modelling the oven and compensating ahead of time is feedforward as opposed to feedback. Where is gets incestuous is when you can determine the model parameters by measuring the reaction of the oven to the controller working. In principle it is more complex than a PID controller since each element is modelled, whereas a PID only has one integrator and one differentiator. But the heat flow and capacity terms may turn out be quite closely modelled by the PID terms. Enough that is really doesn’t matter. I have always liked feedforward, it has a certain level of intuitive satisfaction to it. It also lacks the stability problems inherent in feedback systems. But there is no one right answer. Where feedforward is really nice is that it can respond to transient events better - as you can tell it what the event is - for instance add an oven door open input to it. But this takes you to a whole new world.
Yea, I’ve used PID controllers that have a “self tuning” mode. The controller runs through a routine where it measures the response of the temperature sensor when heater power is pulsed, and then back-calculates the PID constants. Seemed to work O.K.
As others have mentioned, achieving very tight temperature control can be very difficult in an oven. For any practical system, you can design it in such a way that the average of the error is zero over a given time interval, but there will always be short-term fluctuations. These can be reduced by increasing mass, and/or by reducing the thermal resistance between the heater, sensor, and specimen. The sensor should have very small mass and minimal thermal resistance.
A heater is “active heating.” One thing that hasn’t been mentioned is the use of active heating and active cooling. In our temperature metrology lab, we have a stirred liquid bath that has an electric heater and cooling lines (LN[sub]2[/sub]). For temperatures above ambient you can use just the heater, but the accuracy really sucks for temperatures between ambient and 50 °C. Over this range it is much more accurate if you apply constant cooling and then control the heater via a PID controller.
Something else that hasn’t been mentioned is cascade control. Why have just one feedback loop when you can have many? 
The perfect oven controls, ‘Hey Siri cook that leg of lamb to medium well’, Reply ‘OK that will be ready in 2 hours and 7 minutes, would you like mashed potatoes with that?’
How much of a oven’s cooking ‘character’ is caused by temperature cycling and not a exactly held temperature? Would something about the food characteristics be lost if we had a perfect oven?
The gas vs electric oven choice seems to indicate that electric is better for baking, the more constant temperature seems to be preferred here, but for roasting some prefer gas.
Strictly speaking, if cycling helps, you can cycle more accurately using electric as well. (whatever cycling frequency and amplitude you want!)
Basically, the people who “prefer gas” probably won’t be able to tell the difference, or would prefer the electric, if given a blind test. So they don’t know jack. Unless gas does something I’m missing here.
Plenty. Or do you mean losing that je ne sais quoi, that indescribable frisson in cooking knowing that the final pièce de résistance will have been achieved in the face of the uncertainties, nay, the very aporia at the heart of all human tasks that attempt omniscience?
[ * slaps self, returns to senses * ]
A Google Scholar search for “home gas oven control baking,” (Google Scholar) reveals umptyillion patents and research.
It’s cool (heh) that someone who works in (? – or consults with) a temperature metrology lab just happens to hang around SD. On that score, I grabbed this (cite URL doesn’t work for some reason):
Computerized electronic temperature control system for thermal efficiency during baking in food research
D. L. Viljoen1, M. Muller1, J. B. De Swardt2, A. Sadie3 andM. C. Vosloo1
Article first published online: 18 JUL 2008
Abstract
A more sophisticated temperature control system than the capillary thermostat in conventional electric ovens is necessary for laboratory research on foods. The aim of the study was to develop a computerized temperature control system (CTCS) for conventional electric ovens and to determine whether the CTCS could effect comparable and consistent results in two ovens with regard to oven and product characteristics of baked products. No significant differences were found between the two ovens with regard to average oven temperature, texture and height of products. In most instances there were also no significant differences between the ovens with regard to instrumental colour measurement and moisture loss. The regression results also illustrated the effectiveness of the CTCS, i.e. that an increase in set oven temperature of 1°C has a significant effect on specific oven and product characteristics. The CTCS therefore significantly improved the reproducibility of quality characteristics of baked products. Thus, more consistent and repeatable results can be obtained to improve the reliability of consumer-driven food research.
I put together a PID controller for my smoker. It was a little more complex environment as it had an always-on smoke generating element and a sometimes-on heater element. I didn’t know anything about figuring the PID values out for myself so I let the learning mode have at it. It did a fine job. Overshoot was minimal to none, it held temps within 1 degree, and recovered well from opening the door. Was nifty. I gave it away when I moved and now regret it.
As long as you kept those project files somewhere, you didn’t really lose the system…
I thank everyone for the posts so far in this thread. Who would have thought that such a topic would garner so much intelligent discussion. As a machine, a resistive heater isn’t exactly the most complex system around.
Only on the 'Dope. Bravo.
DON’T take it to school with you.
Could one of you techie-talking Dopers indulge the naïf with a one-post-sized beginner’s description of what PID is and how it works?
A PID controller is an example of a feedback control system (also known as closed loop). Feedback control systems measure the output (say, the temperature of the oven) and use that to change the control input (say, the burners) such that the output matches the setpoint.
PID stands for Proportional-Integral-Derivative. These refer to the three terms in the PID formula. Our input is not the output value alone, but the error value–how far above or below our setpoint we’re at. If the oven is at 20 C and the target is 100 C, then the error value is -80 C.
The P term is just a constant times the error. For an oven, the constant will be negative, because the farther below the setpoint we’re at, the higher we want the burner setting. The P term gives us our baseline oven setting, and for some controllers, it’s all that’s needed. It’s just the fairly intuitive fact that we turn the burners on if it’s too cold and turn them down if it’s too hot.
The I term is a constant times the integral of the error. Imagine that you have a helicopter that you want to hover at a particular altitude, and that we’re just using a P term. When the helicopter is far below the target, it will turn the engines on full blast, as you’d expect. But as we approach the setpoint, we have a problem: the helicopter will only be stable hovering below the target. That’s because if we’re at the target, then the engine speed is necessarily zero, since the error is zero. Only at some point below the target will the engine speed match what we need for a stable hover.
What the I term accomplishes is that it looks at this error term over time, and adds in an extra boost to account for it. Even a very tiny error will add up over time (it’s an integral, remember), and give a small boost to correct for it. The I term means there can’t be any error over the long run. The I constant is again negative.
Finally, the D term, which as you guessed is a constant times the derivative of the error. The D term is there to prevent overshoot. The problem with the I term is that it can build up to very large values, and sometimes will blow straight past our target (see the image from beowulff). So the D term looks at how quickly we’re approaching the target, and decreases the control input if we’re getting there too fast. Like I mentioned above, it’s hitting the brakes before we hit the wall. This doesn’t cause problems with long-term error, because when we’re close to the target our speed will be low, and so the D term will be negligible, and the I term can still do its job.
PID controllers don’t always need all of these terms, depending on the system. P, PI, PD, and PID controllers all exist. For instance, you might not need the D term if there’s a lot of air resistance, because the air itself acts as a limiter.
I guess that’s about it. I probably missed something, so let me know if you have further questions.
PID is basically feedback control. Your controller measures the difference between the setpoint that you want and the actual measured value, and creates a signal that is proportional to the error. This is the P in PID (proportional). So let’s say for example you are controlling the temperature of an oven (the subject of this thread), and you want your oven to be at 400 deg F. This is your setpoint. If you measure the temperature and it is 395 deg F then your proportional error is 5 deg F.
By running your oven in a feedback loop, if the error is lower than the setpoint, the error signal causes you to increase the output to the heating element. If the error is higher than the setpoint, then the error signal causes you to decrease the output.
You can do simple proportional control like this, but it tends to not work well in a couple of different ways. First of all, proportional control only tends to end up with the output being just a little off from the setpoint. To handle this, we add in an integrating component to the error signal. The integral is the I in PID. If the error is a bit off from the setpoint and stays that way, the error integrates (adds), and this integration causes the output to be forced towards the setpoint in the long term.
Now you’ve got a PI controller (proportional-integrative). And PI controllers are used in the real world. The issue with PI controllers is that they often don’t respond very quickly to changes. To make them respond better to changes, you add in a differential signal, which is the D in PID. The differential is the rate of change, so a change causes a jump in the error signal that forces the PID controller to respond more quickly.
So P (proportional) handles the error in general, I (integral) handles the long term errors, and D (derivative) handles the instantaneous changes. All of it works together to make much more accurate control than what you would get with just a proportional feedback loop.
PID works for the control of a whole bunch of things, not just temperature control.
ETA: Ninja’d by Dr. Strangelove.
Always good to have multiple perspectives. You mentioned something that I missed: that the D term also helps to respond to quick changes. If you suddenly find yourself moving away from your setpoint, the D term gives a boost in the opposite direction.
A PD controller (without the I) can be useful if there’s no expectation of consistent bias. For instance, a car on a flat road won’t need an I term, because we expect the throttle to be zero if the car is already at the setpoint. If the road is sloped, though, we need the I term.
So the D term is really handy for when somebody changes the thermostat setting from 350 to 450 to put that final browning on the roast. The controller says: “WOW, we just got 100 degrees low somehow!. Fire the burners to Max to get moving already”
Which also points out that the error value can quickly change due to either a change in the actual value (e.g. somebody opens the oven door and lets a lot of heat out) or a change in the desired value (e.g. somebody turns up the temp knob).
Okay, thanks Dr. Strangelove, engineer_comp_geek, and LSLGuy for the brief intro tutorial. Ignorance diminished! Why, it sounds perfectly elementary! 
Why, I almost think I could go out and start programming PID controllers myself already, with (at the very least) better results than the “fuzzy logic” approach described in Post #20 – which, as I heard the story told, made no use of integrals or derivatives, apparently because (a) the programmer hadn’t a clue, except that (b) fuzzy logic was supposed to take care of all that. Somehow.
Do you have to have an á priori mathematical model of the process you’re controlling? That is, do you need to have a function that gives (at least nominally) temperature (or whatever you’re controlling) over time, so you have something to integrate or differentiate? Or is it strictly numerical, integrating and differentiating the most recently collected data w.r.t. time? The latter, I would guess?
Why, I do believe that with just a bit of practice at this, I could even program the mysterious StairMaster controller! 
FWIW, fuzzy logic was designed to control non-linear systems, the classic example being an inverted pendulum. No PID controller can adequately balance an inverted pendulum, no matter how it’s tuned and so more sophisticated control schemes are necessary.
However, temperature control is an eminently linear problem and so a PID is a perfectly appropriate tool for it. An adequately tuned fuzzy logic controller can exactly mimic a PID controller but it would be overkill in this circumstance.
For computer-based PID controllers, it’s strictly numerical. But PID controllers existed long before the transistor, let alone digital computers.
Just as an example, the speedometer in an older car is a totally analog way of computing a derivative (the derivative of distance is speed, of course). As you might know, it uses a magnet in an aluminum cup to convert spinning motion into a torque; the torque is applied to a spring and the net result is a roughly linear relationship between rate of rotation vs. angular displacement. You could, with some care, use the same technique to compute the D input for our controller.
And of course you can do this with analog electronics as well. If you want to measure the rate of change of a current, you can put an inductor in line and the voltage across the inductor will be proportional to the change in current.
So in short, there are lots of ways of computing the integral and derivative that aren’t numerical, but they are still based on the measured error value.
A mathematical model might help with tuning the initial parameters, as well as determining stability, but isn’t strictly necessary. As noted above, PID tuning science is more art than science.