Computing stuff tied to the physical world

,

Reflow profiles, again

In Software on Nov 2, 2010 at 00:01

Now that the thermocouple readout is working properly, things are moving again with the reflow controller.

What we need to do is set up a reflow temperature “profile” which drives the whole process. First the top level code which controls the whole shebang:

Screen Shot 2010 11 01 at 12.10.38

I’ve left out the reporting part, but basically we need to respond to button presses and go through the whole profile once activated. The reflow profile logic is handled by “setPhaseAndTemp()” function:

Screen Shot 2010 11 01 at 12.12.33

As you can see, it is a simple state machine which moves from one phase to the next according to current temperature and timing conditions. The parameters I’m currently using are as follows:

Screen Shot 2010 11 01 at 12.19.36

Each phase has slightly different conditions, and criteria with which it decides to move on to the next phase.

I’ve added a “warmup” phase at the start for two reasons: 1) to always start off on the main part of the reflow profile from a fairly well-defined temperature, and 2) to implement a drying period which removes any humidity present in the chips, since some chips seem to be sensitive to that. That does somewhat lengthen the whole cycle, because there is a lot of overshoot at low temperatures.

Tomorrow, I’ll describe the complete setup and show you how it performs.

  1. Looking forward to seeing your results! By the way, for moisture-sensitive devices which are not sealed with a dessicant, I’ve seen advice like “12 hour bake at 125° C” for drying before soldering.

    JBeale 2 November 2010 at 5am

  2. I think you can easily reduce overshoot by making better use of the PID output. The line: setHeater(power >= 25) is not really helping here. A better way would be to do some PWM-like output like this:

    byte heatcnt=0;
setHeater(byte power) {
    switch (heatcnt) {
         case 0:    if (power>12) heat=(on);
                    else heat?/(off);
                    break;
         case 1:    if (power>37) heat=(on);
                    else heat=(off);
                    break;

         case 2:    if (power>62) heat=(on);
                else heat=(off);
                break;
     case 3:
     default:   if (power>87) heat=(on);
                else heat=(off);
                break;
}
heatcnt+=1;
heatcnt %=4;

    }

    (Or somethink alike). As a result the output of the PID does not need to fluctuate so much and a more stable behavior will result.

    Jaap 2 November 2010 at 9am

    • Thanks. Aha, 4 time slots, with the heater on in a certain proportion of them – nice!

      Your values are for PID results 0..100, right? (in my case, pidCalc() returns 0..255, although those bounds are fairly arbitrary)

      I’ve seen various comments on the web about ways to improve on the full on/off nature of heater control. Hadn’t fully realized that the info for better control is probably present in the pidCalc() result.

      Ok, I’ll experiment with this – thanks.

      jcw 2 November 2010 at 11am

  3. That really looks ugly…

    Jaap 2 November 2010 at 10am

  4. I use this kind of solution for my ceramic oven controller (using an arduino). I also use a thermocouple as I need to be able to go up to 1200deg. BTW I also experienced a lot of instability using the TC (via some op-amps to the analog input).

    My solution also has a PID output of 0-255 and for some reason I end up using 255 timeslots of 1 second…

    It would have been nice to know of the Jee Nodes back when I made this controller, as a wireless solution to control the oven would have been a COOL feature.

    Jaap 2 November 2010 at 12pm

Comments are closed.