Thermal control loop working (sort of)

Classes start tomorrow, so I spent yesterday making sure that the incubator control project was feasible. I had gotten the fan feedback control working well back in September, but I’d put the project aside for Fall quarter and only got back to it this week.  As a reminder, here are the previous posts on the project:

• Temperature-control project for freshman design seminar describes an idea for a possible project for the freshman design seminar.
• PWM for incubator gives a bit more detail on the temperature-control project.
• More on incubator design continues the incubator design.
• Thermal models for power resistors presents thermal models for 3 power resistors without heatsinks.
• Thermal models for power resistor with heatsink applies the simple thermal model to a power resistor with a heatsink, where it does not fit quite as well.
• PWM heater and fan talks about doing PWM for a fan and for a resistor as heater.
• PWM heater and fan continued continues the previous design work, reducing the electrical noise and making PI control loops for the fan and the heater.
• Controlling the heater and fan talks about progress on the control loops and gives the schematic for the circuit discussed in the two previous posts.
• Putting the heater in a box shows the physical layout of the partially completed incubator and discusses the (meager) progress today.
• Improving feedback for fan shows the working control loops, and compares on/off, hysteresis, PI, and PI with anti-windup.

Here is the interior of the styrofoam box, with the lid open. The 6″×12″ aluminum plate covers the bottom. The thermistor is on the left, propped up by a rubber foot, the resistor in is the center, and the fan is sitting on a foam pad on the right. (The foam is to reduce noise until I can get the fan proper mounted in a baffle.)

I left the foam out this time, which made for a somewhat noisy fan, and I still haven’t built a baffle—I’m still using the bent-wire-and-paper deflector shown in the photo. What I worked on yesterday was the software—since the temperature changes are fairly slow, it takes a long time to tune the control loops.

One thing I did was to try to reduce measurement noise further on the thermistor measurements. I now add 60  analog-to-digital readings. They’re 10 bits on the Arduino-compatible board (a Sparkfun redboard), so adding 60 still fits in an unsigned 16-bit word. I now get noise of about ±0.05°C, which is half the least-significant-bit of the converter.  I doubt that I can do better in precision without switching to a processor with a better analog-to-digital converter, though I could do digital filtering with a 1Hz low-pass filter to smooth out the remaining noise.

I copied the fan feedback control loop (with the anti-windup provisions) described in Improving feedback for fan for temperature control, but made two changes:

• I changed the integration time and K_p for the thermal control loop, since the temperature response is much slower than the fan response.
• Because of the huge asymmetry in the temperature response (the resistor and metal plate can heat up much more quickly than they cool down), I turn off the heater the moment it gets over temperature, no matter with the PI loop suggests, but I only switch to full-on when the air temperature is 3°C too cold. For the fan, I used a symmetric window around the set point for using the PI loop rather than full-on/full-off.

Here are some results from tuning experiments:

The blue curve switched to PI control at 23.5°C, the other two at 22°C. The green curve has pretty tight control over the temperature, but does overshoot a bit.

The initial temperatures were not all identical, because I wasn’t always willing to let everything cool down all the way to room temperature after each tuning run. I could only do about 1 tuning run an hour, which could pose problems for the freshman design seminar, as we don’t have long lab times—only the 70-minute lecture-schedule meeting times.

I continued the best of those runs with another step, up to 35°C, then let it cool down.

The step to 35°C has more ringing than the step to 25°C. I terminated the run before it had finished cooling, because the 32-bit µs timer wrapped around.

The cool-down at the end fits a 0.0069 °C/s line better than it fits an exponential decay to the ambient temperature.  If I do fit an exponential decay curve, I get a time constant of around 1975 seconds.

A simple thermal-resistance, thermal-capacity model is not a very good one for predicting how the system will behave, particularly since we’re not measuring the temperature of the large thermal mass (the aluminum plate and power resistor), but of the air, which has a large thermal resistance from the plate.  The time constant for the aluminum-air transfer is larger than the time constant for the electricity-aluminum transfer, which is why we get so much overshoot when we turn off the power to the resistor—the aluminum plate has gotten much hotter than the air, and continues to transfer heat to it, even though no more heat is being added to the aluminum.

Still, it is worth seeing what we get if we model the box a simple thermal mass and thermal resistor. The steady-state 35°C seems to need about 9W (PWM of 51/256) and the 25°C 3W (PWM of 17/256) with an ambient temperature of about 19°C, implying that the styrofoam box has a thermal resistance of about 1.9°C/W.

To see what is really going on, I’ll have to heat the box to 35°C, then start the cool down with a reset 32-bit timer.

Single-step warming from 16.9°C to 35°C. The steady state at 35°C is about 9.32W, for a thermal resistance of 1.8°C/W. The rise of 0.0451°C/s at 45W implies a thermal capacity of 998 J/°C.

Heating at 45W (9V, 1.8Ω) results in a temperature rise of about 0.0451 °C/s. This warm-up rate at 45W implies a thermal capacity of about 998 J/°C. We may want to adjust our thermal capacity estimate, since some of the 45W put in escapes through the box—maybe about 3–4W at the temperatures where the rise was measured. This reduces the thermal capacity estimate to about 910 J/°C.

The cool down from 35°C starts out as a straight line (about -0.0074°C/s or -26.5°C/hour), but gradually starts behaving more like the exponential we would expect from a thermal-resistance and thermal-capacity model.

The time constant for the cooling is about 1380s, but the initial cooling is too slow for a simple exponential.

The time constant of 1380 s, combined with a thermal capacity of 910 J/°C gives a thermal resistance of 1.5 °C/W, a bit lower than the 1.8°C/W I estimated from the steady-state power.

I continued the cooling (with the timer wrapped around) to see if I got a clean exponential at low temperature differences:

The exponential seems to fit well here, with a time constant of 2300s. Combined with the 910 J/°C, this gives a thermal resistance of 2.5°C/W, which seems a little high compared to the other estimates.

So I’ve made some progress on the thermal control loop (though I’d like to reduce the overshoot and ringing) and I have a crude model for the box: a thermal mass with capacity about 910 J/°C and thermal resistance 2±0.5 °C/W.

Still on my to-do list for this project:

• Consider using a PID controller for the temperature to get faster response without overshoot.  (If I can reduce the noise problem.) I should be able to reduce the noise with a digital filter, but I’m already pushing well beyond what I’m comfortable covering in a freshman class. Tuning a PID controller is even trickier than tuning a PI controller, which is already going to take most of the quarter to teach.
• Design and build baffling for the fan to get better airflow in the box. This might be a good thing to get students to do, particularly if we can get them to learn how to use the laser cutter. But even handsaws would suffice, given some thin plywood or masonite, some angle irons, and nuts and screws.
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems. Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course. The more I work on this project, the more I realize that I and the students will have to be happy with them having explored the options, without getting all the problems solved.
• Add changes to the cumulative error term whenever K_P or T_I are changed, to keep the PWM output the same after the changes—currently changing any of the control loop parameters adds a huge disturbance to the system. I don’t know how important this is—I’ve been doing my tuning of the thermal loop by recompiling, rather than by changing parameters on the fly. The quick changes were handy for the fan loop, where I could see things happening quickly, but for the thermal loop each experiment took about an hour, so there was no need for a fast parameter change.
• Research control algorithms other than PI and PID, particularly for asymmetric systems like the temperature control, where I can get fairly quick response to the inputs when heating, but very slow response when cooling. The asymmetric window for switching between on/off and PI control seems to have helped here, but there is probably a more principled way to handle asymmetric control inputs. Maybe I should ask some of the control-theory faculty for some pointers.
• Develop a more detailed thermal model with separate components for the aluminum plate and the air in the box. It may be worth adding another thermistor, taped to the aluminum plate, to monitor that temperature. The extra thermistor would also allow much tighter temperature control, avoiding overshoot on air temperature.

 

Improving feedback for fan

I wanted to look at the step response of the fan and of the heater, so that I could see if I could derive somewhat reasonable control parameters by theory, rather than by cut-and-try parameter fiddling.  Most of the tutorials I’ve looked at give empirical ways of tuning PID controllers, rather than theoretical ones, even ones that use Laplace transforms to explain how PID controllers work and how to determine whether or not the control loop is stable if you are controlling a linear time-invariant system with a known transfer function.

When I first looked at the fan response, I noticed a problem with my tachometer code:

The tachometer gives two pulses per revolution, but the markers used are not perfectly spaced, so I get different estimates of the speed depending which falling-edge-to-falling-edge pulse width I measure. The difference between the two speeds is about 1.6%.

I rewrote the tachometer code to trigger on all four edges of a revolution, and to record the time at each edge in a circular buffer. This way I can use a full revolution of the fan for determining the speed, but get updated estimates every quarter revolution, available in micros_per_revolution:

volatile uint32_t old_tach_micros[4];  // time of last pulses of tachometer
	// used as a circular buffer
volatile uint8_t prev_tach_index=0;    // pointer into circular buffer
volatile uint32_t micros_per_revolution; // most recent pulse period of tachometer

#define MIN_TACH_PULSE  (100)   // ignore transitions sooner than this many
				// microseconds after previous transition

void  tachometer_interrupt(void)
{   uint32_t tach_micros = micros();

    if (tach_micros-old_tach_micros[prev_tach_index] < MIN_TACH_PULSE) return;
    prev_tach_index = (prev_tach_index+1)%4;  // increment circular buffer pointer
    micros_per_revolution= tach_micros-old_tach_micros[prev_tach_index];
    old_tach_micros[prev_tach_index] = tach_micros;
}

In setup(), I need to set up the interrupt with attachInterrupt(FAN_FEEDBACK_INT,tachometer_interrupt, CHANGE);

I think that this improved tachometer code may be a bit too much for first-time programmers to come up with. Circular buffers use a bunch of concepts (arrays, modular arithmetic) and are likely to cause a lot of off-by-one errors. Interrupts alone were a complicated enough concept for students to deal with. I don’t know whether the improvement in speed measurement would be justifiable in the freshman design course.

The new tachometer code did smooth out the measurements a lot, though, as expected—it reduces the fluctuation in measured speed to about 0.3%, which is limited by the resolution of the micros() timer I’m using on the Arduino board. I then tried recording some step responses, both for upward steps and downward steps. The upward steps are reasonably approximated by an exponential decay (like a charging curve):

The low speed with PWM=0 (always off) is 724.7 rpm, and the high speed with PWM=255 (always on) is 6766.3rpm. The exponential fit is not perfect, but it is certainly a good enough approximation for designing a closed-loop system.

The response to a downward step, however, is not well modeled by a simple exponential decay:

The fan spins down gradually at first (with a time constant about 1.6s), but at low speed the speed changes faster (as if the time constant dropped to about 0.6s).

Note that the fan slows down much more gradually than it speeds up, which means that it is not a linear, time-invariant system. In a linear system, superimposing a step-up and a step-down would cancel, so the responses to the step up and step down should add to a constant value—the fan most definitely does not have that property.

I was curious whether the difference was just apparent for large steps, or also for small ones, so I tried steps between PWM duty cycles of 100/256 and 160/256:

A small upward step is again quick, with almost the same time constant as before.

The small downward step is faster than before, though still substantially slower than the upward step of the same size, and with an initially slower response than the final convergence.

I’m going to try writing a couple of ad hoc controllers for the fan, to see if they behave better than the PID controller I’ve been using: open-loop control using just  PWM=(setpoint-740)/25; a simple on/off control with a single threshold; hysteresis, using two thresholds instead of 1; PI control with no anti-windup; and a controller that goes to full on or full off when the error is large, to make a quick transition,  switching to approximately the right PWM value,  when the error is small, with PI control thereafter.

I think that the open-loop controller will have a steady, but wrong speed; the  crude on/off controllers will make an audible pulsing of the fan motor; the PI controller will suffer from overshoot when making big steps, and the on/off/PI controller should make nice steps, if I can tune it right.

I implemented all the controllers and ran a test switching between setpoints of 1000RPM and 5000RPM every 30 seconds.  Here are plots of the behavior with different control algorithms:

The PWM values computed by the various control algorithms show the integrator windup problem for PI clearly after the downward transitions—PI takes a long time to recover from the errors during the downward edge.

The mixed algorithm does a very good job of control, with little overshoot. The simple PI algorithm has substantial overshoot, particularly when the control loop wants a PWM value outside the range [0,255]. Open loop has significant offset and wanders a bit. On/off control oscillates at about 10hz, and adding hysteresis makes the oscillation larger but slower (about 5Hz).

The errors for the mixed controller are only about ±0.3% and overshoot or ringing at the transitions <40RPM.  The simple PI controller overshoots by 340RPM and takes 20 seconds to recover from the integrator windup on the downward transition.  The open-loop controller has offset errors of about 1% and a fluctuation of about ±0.7% at the high speed, and an offset of 1% and fluctuations of about ±0.5% at the low speed.  The on/off controller has an offset of  about 0.5% at high speed with fluctuations of ±2%, and an offset of 28% with fluctuations of ±28%.  Adding hysteresis slows down the oscillations, but makes them larger (0.2% offset, fluctuations ±3% at high speed, and 44% offset with fluctuations of ±70% at low speed).The mixed algorithm which uses on/off control for large errors and PI for small errors, with back-calculation of the integral error when switching to the PI controller seems to work very well.  But would I be able to get freshmen to the point of being able to develop that themselves within a 2-unit course?  Probably not, but I might be able guide them through the development in a series of exercises that started with on/off control, then went to modeling and open-loop control, then the PI control, and finally the mixed control.  It would take most of the quarter.

Putting the heater in a box

Continuing the saga of the incubator project in the recent posts:

• Temperature-control project for freshman design seminar describes an idea for a possible project for the freshman design seminar.
• PWM for incubator gives a bit more detail on the temperature-control project.
• More on incubator design continues the incubator design.
• Thermal models for power resistors presents thermal models for 3 power resistors without heatsinks.
• Thermal models for power resistor with heatsink applies the simple thermal model to a power resistor with a heatsink, where it does not fit quite as well.
• PWM heater and fan talks about doing PWM for a fan and for a resistor as heater.
• PWM heater and fan continued continues the previous design work, reducing the electrical noise and making PI control loops for the fan and the heater.
• Controlling the heater and fan talks about progress on the control loops and gives the schematic for the circuit discussed in the two previous posts.

On my to-do list for the project

• Put the whole thing into a styrofoam box, to see whether extra venting is needed to allow things to cool down, and to see how tightly temperature can be controlled. Find a smaller bread board or prototype board to put the controller on—my current bread boards are all 6.5″ long, and the box only has room for 6″, especially since I put the resistor in the center of the 6″×12″ aluminum plate, which just fits the box. I suppose I could drill a couple more holes in the plate and mount the resistor off center, but I rather like the idea of building the controller as an Arduino shield, so that the Arduino + controller is a single unit. Another possibility is to drill a hole in the styrofoam box and run cables through the box for the resistive heater, the fan, and the thermistor. Even if the grounds are connected outside the box, this is only 8 wires. Putting the control electronics outside the box would reduce the clutter in the box and make tweaking easier
  

  I got this done today, by drilling a hole in the box and soldering long wires onto the resistor and the thermistor, so that all the active electronics could live outside the box. Incidentally, “drilling” did mean using a drill bit, but I held it and turned it with my fingers—styrofoam is so soft and grainy that I feared a power drill would tear out big chunks.

  

  Here is the interior of the styrofoam box, with the lid open. The 6″×12″ aluminum plate covers the bottom. The thermistor is on the left, propped up by a rubber foot, the resistor in is the center, and the fan is sitting on a foam pad on the right. (The foam is to reduce noise until I can get the fan proper mounted in a baffle.)

  As expected, I can heat up the thermistor fairly quickly, but if I overshoot on the temperature, it takes a very long time for the closed box to cool back down. Cooling off just 1°C took over half an hour.

• Add some low-pass filtering to the temperature measurement to reduce noise. Just adding 4 measurements in quick succession would reduce the noise and give the illusion of extra precision.

  I did this also. With the box closed, the thermistor reading is fairly stable, with fluctuations of less than 0.1°C (which was the resolution with a single thermistor reading before adding 4 successive reads).

• The fan controller occasionally has a little glitch where the tachometer either misses a pulse or provides an extra one (I think mainly an extra one due to ringing on the opposite edge).  I could try reducing this problem in three ways: 1) changing which edge I’m triggering on, 2) using more low-pass filtering before the Schmitt trigger in the edge detector, or 3) using median filtering to throw out any half-length or double-length pulses, unless they occur as a pair.  (Hmm, the half-length pulses would occur as a pair, so this might not help unless I go to median of 5, which would be a lot of trouble.)

  I fixed this also, using two techniques:

  1. In the program I have 3 states for the interrupt routine that catches the edges: normally, I check that the edge is within 3/4 to 3/2 of the previously recorded pulse—if so I record it and continue. If it is less than 3/4 as long, I skip it, and change to a skip state. If it is more than 3/2 as long, I skip it and switch to a force state. In the skip state, I ignore the reading and switch to the force state. In the force state, I accept the pulse length (whatever it is), and switch to the normal state. With this state machine, I ignore a double-length pulse or a pair of half-length pulses together.
  2. The rising edge of the pulse from the tachometer is very slow (thanks to the RC filter of the pullup), but the falling edge is sharp. Extraneous pulses are more likely to occur if I trigger on the slow edge rather than fast edge, so I switched the polarity to make sure that I was using the falling edge (which is the rising edge of the output of the Schmitt trigger).

  I think that changing which edge I used made a bigger difference than trying to suppress the erroneous reads digitally. I no longer hear the occasional hiccup where the control algorithm tries desperately to double or half the fan speed because of a misread timing pulse.

• Improve my anti-windup methods for both thermal and fan controllers, to reduce overshoot.

  I changed from using conditional integration and back calculation of the integration error to using a decay of the integration error based on the difference between the computed PWM setting and the limit when the limits were exceeded. I’m not sure this improved anything though, and it introduces yet another parameter to tune, so I may go back to the previous method. I did play around with the tuning parameters for the fan loop today, and realized that I still don’t have good intuition about the effect of parameter changes. I noticed that the fan control was oscillating a little (small fluctuations around the desired speed, but big enough that I could hear the changes), and I found ways to reduce the oscillations, but at the expense of slower response to step changes.

• Improve my modeling of the thermal system, so that I can do more reasonable back calculation on setpoint change.

  I still need to do more thinking about the thermal modeling, since it is clear that I can’t afford overshoot when heating (though overshoot during slow cooling is unlikely to be a problem).

Still on my list with no progress:

• Consider using a PID controller for the temperature to get faster response without overshoot.  (If I can reduce the noise problem.)
• Design and build baffling for the fan to get better airflow in the box. I’ve made a little paper and wire baffle, to get better air flow over the resistor, but I’ve not done the full baffling to get good airflow in the box.
  
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems. Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course. The more I work on this project, the more I realize that I and the students will have to be happy with them having explored the options, without getting all the problems solved.
  

I want to add to the list today:

• Add changes to the cumulative error term whenever K_P or T_I are changed, to keep the PWM output the same after the changes—currently changing any of the control loop parameters adds a huge disturbance to the system.
• Separate the control algorithm better from the rest of the code, so that I can use the same code base and quickly switch between different control algorithms: on/off, on/off with hysteresis, proportional control, proportional control with offset, PI control, PI control with anti-windup variants, PID control.
• Add an option for recording the response of the system over a long time, so that I can plot input and output of the system with gnuplot. This would be nice for the fan control loop, but I think it will be essential for the temperature control loop.
• Research control algorithms other than PI and PID, particularly for asymmteric systems like the temperature control, where I can get fairly quick response to the inputs when heating, but very slow response when cooling.

Controlling the heater and fan

Here is the circuit for the heater and fan that I’ve been developing for incubator project for the freshman design course:

Here is the circuit I’ve been using for playing with control loops. (The 74HC14N Schmitt trigger inverter does not have an enable input, but SchemeIt has a very limited and idiosyncratic set of schematic symbols, so I used the closest one.)

Yesterday and this morning, when I was developing the controller software for the fan and resistive heater, I ran into a lot of problems with overshoot when changing the setpoints. For the fan controller I wrote “One thing that helped was not accumulating integral error when the PWM signal was pinned at the lowest or highest values.”  I also switched to using RPM rather than pulse duration as the measured variable, because RPM is nearly linear with the PWM input (RPM approximately 24.1 PWM + 878). Another thing “that helped was to make a guess at the target PWM setting when the setpoint was changed (using d RPM/ d PWM =24 and the current PWM setting and RPM value), then setting the cumulative error to what it would be in steady state at that PWM. I then set the PWM to five times as far from current PWM as the target PWM to make the transition as fast as possible without increasing overshoot, making sure to clip to the legal 0..255 range.”  Because I have a reasonable model for RPM as a function of PWM, it was easy to estimate what the target PWM should be so that the cumulative error from the integrator would set the PWM value correctly once the error dropped enough that the desired PWM value was no longer pinned at the limits.

Today I decided to do a little reading to find out what other people have done about the problem of the controller overshooting when the actuator hits its limits.  It turns out that the phenomenon is know as “integrator windup“, and the two solutions I came up with are standard solutions.  Turning off the error accumulation when the actuator is at its limit and more movement in that direction is desired is known as “conditional integration” and guessing the correct setting for the cumulative error on setpoint change is a form of “back calculation”.  There are more sophisticated forms of back calculation that I might want to try implementing.  (I found a better explanation of the anti-windup scheme, which I might base my next implementation on—basically it gradually reduces the cumulative error to 0 as long as the desired setting for the actuator is past its limits.)

The temperature controller has been harder for me to tune, for several reasons:

• The response time is very long.  Instead of oscillating around 5Hz, the period seems to be more like 90 seconds.  This means that it takes a long time to see whether an adjustment to the parameters makes a difference.
• The temperature at the thermistor is dependent on the temperature at the resistor.  The thermal mass and thermal resistance act like an RC circuit (with temperature analogous to voltage, and power dissipated analogous to current).  Adjusting the power to the resistor via PWM changes the rate at which the temperature increases.  It also changes the eventual equilibrium temperature, but the PWM control is more directly of the rate of temperature change.
• The heatsink and resistor continue to warm the air and the measuring thermistor even after all power to the resistor is cut off, so there is a big danger of overshoot whenever the setpoint temperature is increased.
• The control is asymmetric—dumping 40W of power into the resistor heats it up fairly fast, but heat is only slowly dissipated when power is turned off.  Running the fan fast helps a little here, slowing down the temperature rise and speeding up the cool down, but once I put the whole thing in a closed box, it will be very difficult to cool things off if the box gets too warm.  This makes overshoot in the positive direction  a serious problem.
• The temperature measurements are only about 0.1°C resolution, and the noise on the ADC is about ±4LSB, so it will be difficult to get tight temperature control, even with a perfectly tuned controller.
• I don’t have a simple model of what the steady-state thermistor temperature will be given the PWM input, so I’ve had difficulty coming up with a guess about the eventual PWM value for resetting the cumulative error on a setpoint change.  I have a model for the resistor temperature in still air, but the fan makes a huge difference, both in the thermal resistance (and so both the equilibrium temperature and time constant of the resistor heating) and in the coupling between the resistor and the thermistor.

I still have a lot of things left over from a couple of days ago, and I’ve added some new things to the list.

• Put the whole thing into a styrofoam box, to see whether extra venting is needed to allow things to cool down, and to see how tightly temperature can be controlled. I’ve put stuff in the box, but I can’t close the box with the stuff sticking out, so it doesn’t really count.
  
• Design and build baffling for the fan to get better airflow in the box. I’ve made a little paper and wire baffle, to get better air flow over the resistor, but I’ve not done the full baffling to get good airflow in the box.
  
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems.  Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course. The more I work on this project, the more I realize that I and the students will have to be happy with them having explored the options, without getting all the problems solved.
  
• Find a smaller bread board or prototype board to put the controller on—my current bread boards are all 6.5″ long, and the box only has room for 6″, especially since I put the resistor in the center of the 6″×12″ aluminum plate, which just fits the box.  I suppose I could drill a couple more holes in the plate and mount the resistor off center, but I rather like the idea of building the controller as an Arduino shield, so that the Arduino + controller is a single unit.
• Another possibility is to drill a hole in the styrofoam box and run cables through the box for the resistive heater, the fan, and the thermistor.  Even if the grounds are connected outside the box, this is only 8 wires. Putting the control electronics outside the box would reduce the clutter in the box and make tweaking easier.
• Add some low-pass filtering to the temperature measurement to reduce noise.  Just adding 4 measurements in quick succession would reduce the noise and give the illusion of extra precision.
• The fan controller occasionally has a little glitch where the tachometer either misses a pulse or provides an extra one (I think mainly an extra one due to ringing on the opposite edge).  I could try reducing this problem in three ways: 1) changing which edge I’m triggering on, 2) using more low-pass filtering before the Schmitt trigger in the edge detector, or 3) using median filtering to throw out any half-length or double-length pulses, unless they occur as a pair.  (Hmm, the half-length pulses would occur as a pair, so this might not help unless I go to median of 5, which would be a lot of trouble.)
• Improve my modeling of the thermal system, so that I can do more reasonable back calculation on setpoint change.
• Consider using a PID controller for the temperature to get faster response without overshoot.  (If I can reduce the noise problem.)
• Improve my anti-windup methods for both thermal and fan controllers, to reduce overshoot.

Thermal models for power resistor with heatsink

Last night I fit a simple thermal model to temperature measurements of some power resistors: , where P is the power in watts, D is thermal resistance in °K/W, M is thermal mass in J/°K, A is the ambient temperature in °C, and T₀ is the initial temperature.

I ran into problems with the 1.8Ω 50W THS501R8J resistor, because it heated up very fast and I could only get a few measurements when delivering power, before I had to turn it off.  I proposed adding a heatsink, a 6″×12″ sheet of aluminum 0.063″ thick, to increase the thermal mass M and decrease the thermal resistance D.  I estimated that the thermal mass should increase by the heat capacity of that much aluminum (74.33 cm³ at 2.422 J/°K/cm³, giving 180 J/°K), but I did not have a good way to estimate the change in thermal resistance.

The 6″×12″ plate is much larger than the power resistor, which is bolted in the center with M3 screws (American 6-32 screws are a little too big for the holes in the resistor). I used a thin layer of white thermal grease to get better thermal conduction between the resistor case and the aluminum plate.

I do not expect the simple thermal model to work well, because it assumes that you have an isothermal object—all the aluminum at the same temperature.  But a large flat plate is going to have significant thermal spreading resistance, so that the resistor in the center is hotter than the edges of the plate.

With a heatsink the time constant DM is about 260s, only a little faster than the 347s without the heatsink, but the thermal resistance is much lower, so the maximum temperature (PD+A) is much lower.

As expected, the fit is not great. When cooling off, the initial temperature of the resistor is higher than of the surrounding plate, so the initial cooling at the resistor is faster than the eventual cooling, when resistor and the plate are closer in temperature, because heat is being transferred to the plate as well as to the air. The increase in thermal mass  (about 100 J/°K) was less than my crude estimate based on the heat capacity of the added aluminum (180 J/°K)—this is probably also due to the thermal spreading resistance and the non-uniform temperature of the heatsink.

resistance	rated power	heatsink?	test power	M [J/°K]	D [°K/W]	DM [s]	T∞ [°C]
10.10Ω	100W	No	8.288W	101.7	6.38	649	75.7
8.21Ω	50W	No	10.169W	32	11.58	371	143.7
1.81Ω	50W	No	43.174W	31.9	10.87	347	495.8
1.81Ω	50W	Yes	43.174W	131.7	1.97	260	110.3

Note: the asymptotic temperature T_∞ in the table above is with the 9V power supply I have, which does not have quite constant voltage over the range of powers tested. With a 12v supply, temperatures would be much higher: .  The asymptotic temperature is also the maximum when the resistor is sitting in still air that is unconfined.  A fan would reduce thermal resistance and make the asymptotic temperature lower, but confining the resistor in a box (like in the incubator design) would make the “ambient” temperature not be constant—the relevant thermal resistance is how slowly the air in the box loses heat, which for the thick-walled styrofoam boxes we’ll use is a very high thermal resistance.  Without a feedback loop and PWM to keep the power down, even the 10Ω resistor would get very hot in a styrofoam box.

I should probably test the 10Ω 100W resistor on the heatsink also, to see if that reduces the time constant DM.  I expect the thermal mass to go up by something between 100 and 180 J/°K, but the thermal resistance to drop to around 1–1.5 °K/W, getting DM in the ballpark of 300s.  I don’t think I’ll do that today, though, as making measurements every 20 seconds for 2000 seconds is tedious and leads to cramping in the hand that aims the IR thermometer and keeps the trigger pulled.

Which raises a pedagogical question: Should I have students do the measurements?  Should I show them how to make a recording thermometer with a thermistor first? They’ll need to figure out how to use a thermistor for measuring air temperature anyway.

The thermistors I have at home (NTCLE100E3103JB0) only go up to 125°C, and I’d want them to have one that goes to at least 175°C for this lab, which means using something like NTCLG100E2103JB (10kΩ, ±5%, ±1.3% on B-value, -40°C to 200°C), which is only 35¢ in 10s, so still cheap. I should get myself some of these higher temperature thermistors and test out the recording . (Or the tighter tolerance NTCLE203E3103SB0, which only goes up to 150°C, or the wider temperature range 135-103LAF-J01, which goes to 300°C.)

How will I attach the thermistor to the resistor for temperature measurement? tape?  (I have to be sure not to short out the thermistor leads on the aluminum case of the resistor.)

Air temperature sensing poses less of a mounting challenge, but the thermal delays will be quite large—I have to look at how difficult it will be to tune a PID or PI controller with large delays—we really don’t want huge overshoot.  If the students have multiple temperature measurements (resistor temperature and air temperature, for example), they may need a more complicated control loop than a simple 1-variable PID controller.  How much can we simplify this?  (Perhaps a PI or PID controller based on the air temperature, with over-temperature shutdown on the resistor temperature?  Then tuning the PID controller with the constraint that the gain be kept low enough to keep the over-temperature shutdown from kicking in?)