|
I need a reflow oven for lead-free soldering Surface Mounted Device (SMD or SMT) technology. Some of my projects have more than 100 SMD components and soldering these by hand is time consuming and exacting. Real SMD reflow ovens are expensive (and large) so I figure I’ll be making my own. There are a few construction articles on the web that give ideas for converting a bench-top oven for reflow either using a commercial microcontroller or PLC controller but these approaches are relatively expensive. I’ll be doing this design from scratch and trying to use stock components. I already have a particularly cheap (and somewhat nasty) Cascade bench-top oven that was purchased specifically for de-populating boards. The oven has two electrical elements (one upper and one lower) with a combined rating of 1,500 W controlled by an electromechanical thermostat and a mechanical timer.
Figure 1. Cheap Toaster Oven
Depopulating boards doesn’t require precise temperature control or profiling. The technique I use is simply put the board upside-down in the oven over a tray, turn the oven on, wait until the solder melts (usually accompanied by a couple of SMD components falling off), give it about another 30 seconds, then remove the hot board from the oven with tongs and bash it on the oven tray. Almost all of the SMD parts will come off and with just a small amount of clean-up they can be re-used. Infrared SMD reflow soldering requires time/temperature profile control to within about +/- 5°C up to a maximum of about 260°C. The required temperature profile is primarily specified by the solder paste manufacturer, but individual components may have recommended reflow profiles, and there are also JDEC and other Standards that specify these..
Figure 2. SMD Lead Free Reflow Profile
The first mission was to pull the oven to pieces, see how much space I have for mounting stuff, investigate moving both elements to the top of the oven cavity and making better radiation shields and mirrors. After removing just 9 screws and sliding off the case I can see that there is heaps of room.
Figure 3. Toaster Oven Guts
I need a microprocessor based temperature controller. I have decided to build this up on in four sections for electrical isolation and ease of development.
1. Optically isolated zero voltage power switch. 2. Processor board with thermocouple amplifier and cold junction reference. 3. Power supply board. 4. Control board with LCD display.
The processor will allow me to calculate cold junction compensation provided that it has a measure of the ambient temperature at the thermocouple terminating junction. This has the advantage that I can use any thermocouple type and re-calibrate in software as opposed to having to change the hardware. I can also linearize the thermocouples non-linear response either through a look-up table or by applying a standard polynomial. The processor will allow me to utilize proportional control and lead-lag compensation to ensure optimum temperature ramping and avoid temperature over-shoot within the limitations and characteristics of the oven. In addition to controlling the temperature to achieve the desired profile it would be nice to log the time temperature curve as a record of a particular soldering operation. The required heating operation does not require me to heat the entire PCB substrate, only the surface layer, hence the need to move the oven’s heating elements to the top of the oven. The use of two elements should also reduce radiation shielding caused by high profile SMD components. The thermocouple configuration and placement is going to be critical. It should be in the plane of the circuit board away from the sides of the oven cavity. It will require some sort of thermal mass that will approximate the heat transfer (radiation, conduction and convection) characteristics of the printed circuit boards being reflow soldered. I figure that if I weld the thermocouple junction to a piece of 1 ounce PCB it should provide a reasonable measure of PCB surface temperature. However this will require some experimentation. As an aside, the concept of what constitutes surface temperature is not straight forward. The actual temperature of the board surface will not be isothermal because even with an isentropic radiation element the board will not be homogeneous (these are great wheel-barrow words). The area of copper conductors and pads will vary, there will be shielding by components, components leads will conduct heat away from the pads at differing rates, and the radiation reflection coefficient of the board will be all over the place due to different materials and surface properties. Okay, I have a design concept that should not be too much of a challenge to fabricate. As a first step I need a thermocouple measurement device to measure the oven’s performance. I could simply purchase one, but I have the bits lying around to make one and this will be the guts of the proposed controller. I have some K type thermocouple wire which will handle 1,300°C and if this toaster oven ever gets near this temperature then all of the plastic trim will have ignited. My preferred processor has a 10 bit ADC resolution. This is more than adequate for the temperature range of interest; say 300°C as a maximum. There are a few tricks I can apply if I need a higher resolution such as over-sampling and decimation. A quick note on accuracy and resolution. While the resolution of this controller should be better than +/-1°C the absolute accuracy of a K Type thermocouple is around +/-3°C in the range 0 to 300°C. While this can be improved by calibration against physical (triple point) references this is time-consuming and in any case the thermocouple output will change over time, and from one heating cycle to the next. Instrumentation errors are cumulative and have not been included. For this application we need better than +/-5°C at the top end and this should be achievable. I expect that the greatest contribution to the absolute error will be associated with the thermocouple mounting. The basic design is complete. It has the following modules:
1. Processor Board
a. RS232 serial port (one day I will make this USB but not today). b. LCD display drive. c. Over voltage protected dual thermocouple inputs. d. Cold junction temperature measurement. e. Two IO ports for driving/reading whatever. f. One 12 V 5 A output port for fan drive. g. SPI (and RS232) programming capability. h. Regulated power supply. i. Rotary encoder, three switches and two LED interface. j. Piezo sounder.
2. Isolated Mains Switch.
a. Fully isolated optically coupled drive. b. Zero voltage switching. c. 12 A, 600 V rating.
The next stage in this project is to sort out the operating modes and display before I complete the board layouts. The LCD display modules that I have on hand are 2 lines x 16 characters. Meaningful graphics are therefore out of the question on the oven display. I propose two basic operating modes: Oven and Reflow. I want to be able to adjust the oven temperature and start or stop a heating cycle at any time. I want to view the time, actual temperature, set temperature, mode and current heating cycle .
| O | V
| E
| N
|
|
|
|
|
|
| T
| S
|
| X
| X
| X
| Line 1
| O
| F
| F
|
|
| 0
| 0
| 0
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2a
| O
| N
|
|
|
| Y
| Y
| Y
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2b
| C
| O
| O
| L
|
| Y
| Y
| Y
|
|
|
|
|
|
|
|
| Line 2c
|
|
In Reflow we need to see the time, heating stage and actual temperature. | R | E
| F
| L
| O
| W
|
|
|
|
| t
|
|
| X
| X
| X
| Line 1
| O
| F
| F
|
|
|
|
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2a
| P
| R
| E
| H
| E
| A
| T
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2b
| S
| O
| A
| K
|
|
|
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2c
| R
| A
| M
| P
|
|
|
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2d
| R
| E
| F
| L
| O
| W
|
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2e
| C
| O
| O
| L
|
|
|
|
|
|
| T
| O
|
| Z
| Z
| Z
| Line 2f
|
|
Best we have an Error display too (although not that I am anticipating too many errors). We can detect all sorts of error conditions including over temperature, thermocouple failure, no heating and inadequate cooling. | E | R
| R
| O
| R
|
|
|
|
|
| T
| O
|
| X
| X
| X
| Line 1
| T
| C
| 1
|
|
|
|
|
|
|
|
|
|
|
|
|
| Line 2a
| T
| C
| 2
|
|
|
|
|
|
|
|
|
|
|
|
|
| Line 2b
| A
| M
| B
| I
| E
| N
| T
|
|
|
|
|
|
|
|
|
| Line 2c
| E
| L
| E
| M
| E
| N
| T
|
|
|
|
|
|
|
|
|
| Line 2d
| O
| V
| E
| R
| T
| E
| M
| P
|
|
|
|
|
|
|
|
| Line 2e
| F
| A
| N
|
|
|
|
|
|
|
|
|
|
|
|
|
| Line 2f
|
|
While all this is going on we want to be sending the time-stamped temperature over the RS232 port. This is pretty straight forward but dynamically dealing with the data at the other end is going to be slightly more of a challenge. I figure on trying to use Microsoft Excel and using a Visual Basic or XML macro to dynamically graph the output temperature. If this turns out to be a problem then I’ll probably be writing a monitor program in C. I have settled on a single rotary control with a push button and two additional push buttons for setting modes, temperature and start/stop. Some commercial ovens automatically open the door during cool-down. I figure that incorporating a fan will be easier to implement with my toaster oven. There should be enough leakage from the cavity to allow for effective convective cooling. I have also found a commercial IR reflow design with a lower element which claims to reduce localised hot spots on the board. I understand what they are trying to achieve by through-board conduction but reflow heating cycles are relatively short (say 600 s from the start of a cycle to the end of cooling) so I’m not sure how effective this will be. Best I get on and make the controller to measure the oven characteristics. A slight problem has arisen. There is insufficient space on the oven’s front panel for mounting the LCD display with an appropriate orientation. It will fit on the top but it will be a struggle to orientate it ideally unless it extends slightly over the oven cavity. There are smaller character LCD display modules that will fit but they are either expensive or have large Minimum Order Quantities. Either I’ll be mounting the controller and switch in a stand-alone box or using ceramic wool to insulate the display module from the oven cavity. My next mission is to lay out the PCBs for the design. There are a couple of over-riding criteria. The mains switch (an optically isolated solid state relay) needs to maintain spacing for electrical isolation, and the cold junction reference, thermocouple terminal blocks and amplifier on the controller board need to be laid out for best isothermal performance. Keeping these parts away from power devices, a good thermal mass (a lump of copper on the back of the board perhaps) and convection shielding will help here. Another minor issue has arisen. Somewhere I have several tubes of optical isolators in 4 pin DIP packages but I can’t find them. I suspect that this will be the one component purchase for this project. Thankfully they are cheap – just a few cents each - and I will be able to use SMT devices. The processor board layout design is completed. It is 2” x 3”, double sided board with SMD on one side and just a few through-hole components and connectors. I could have made it even smaller but I have been generous with track widths and clearances to aid with my prototype construction process. A late thought in this development was the use of single IC cold junction reference amplifiers such as the MAX6675 (specifically designed to work with K type thermocouples). A quick check of the data sheet indicates the accuracy for this device is almost +/- 20°C at 700°C. It is unclear if this incorporates the inherent inaccuracies in a thermocouple or is due just to the non-linear response curve. I figure that I can do much better than this with my current design. Today is board making day and maybe writing some code! At the end of the day the board has been etched but not drilled, cut to size or plated. The delay was due to in part to the failure of one of the UV lamps in my board exposure box (I have some replacements on order). I’ve made a start on the code with developing the look-up tables. With appropriate gain on the thermocouple amplifiers these will be incredibly fast and accurate to within +/- 4°C from 0 to 511°C with all errors accounted for. The greatest contribution to the absolute error will be the thermocouple itself. Tomorrow I hope to complete the controller board, populate and test it. Tomorrow has come and gone and the board is drilled, plated, tinned; all of the through-hole vias have been made and tested but I ran out of time to fit the parts. No worries. The processor board has been assembled and tested. There was only one problem of any significance. I inadvertently put the input op amp on the board with the wrong orientation. As a consequence the board drew a relatively high current of about 1.2 A and both the regulator and the op amp got rather warm rather quickly. Sorting out the cause of excessive current can be difficult with many devices on the supply rails. In the first instance check for rail shorts and the polarity of all polarity sensitive components including ICs. Double check the voltage ratings of tantalum capacitors too. Now days it is extremely unlikely that an integrated circuit was dead on arrival so you shouldn’t be making this assumption. The finger test on the components will confirm what is dissipating excessive power. Most three terminal regulators have over temperature and current shut-down but they will get hot dealing with a down-stream fault, and limit the output voltage in the process.
Figure 4 (a) and (b). Controller Board
With the offending op amp found I then had to carefully replace it. As the component was almost certainly stuffed the easiest technique is to carefully cut the IC pins close to the case using very fine and sharp sharp side cutters and then clean up the tracks with solder braid. Trying to lift the IC risks damaging the tracks unless you have a real SMD rework station. With the op amp replaced the board current settled down to about 20 mA (in the right ball-park) with nothing getting warm. The RS232 IC was generating appropriate +/- 8.5 V rails and can therefore be assumed to be operating correctly. The temperature compensation IC was producing about 3.6 V which was adjusted to 2.87 V with the calibration potentiometer. The op amp had outputs of 100 mV and 160 mV with a 50 Ohm shorting resistor across the input channels. Surely this should be zero – so my design must be faulty! Actually this ‘error’ was anticipated. It is due to the input offset voltage and bias currents of the op amp. The amplifier DC gain is almost exactly 119 (established by passive feedback components) so the corresponding input offset voltages (ignoring bias currents) are 0.83 and 1.34 mV at 14°C ambient. These are completely within specification of the selected op amp (2.5 mV maximum at 25°C and 2.7 mV maximum across the specified industrial temperature range). They are also both positive which is expected from the distribution of offset voltage for the selected device. With a K Type thermocouple connected both outputs rose about 70 mV when held between my fingers (around 15°C above ambient). There are several ways of dealing with input offset voltage and bias currents including using a high specification low input offset op amp, or an offset null, or a chopper stabilized amp. However these approaches add components and cost. I had always intended to calibrate the input offset voltage out in the software. The input offset voltage (and bias currents) are also temperature dependent. With the specified op amp the input offset voltage varies by typically 2 uV/°C. The circuit board temperature will need to vary by about 20°C for a 1°C change in the temperature reading. When I put my finger on the op amp IC package there is no perceptible change in the op amp output. If necessary I can account for this in the software too. In terms of bias currents the design has identical impedances (within 1%) on the op amp inverting and non-inverting inputs so provided that the bias currents change proportionally with temperature they should result in minimal changes to the output voltage. If these prove to be a problem I can address them in the software too. Time to write some code to test the SPI interface, the processor and a few of the peripherals. The program interface is working (although I did have an issue with a couple of assembler directives), the LCD display is running, and all of the output ports are doing their stuff. The next test is of the RS232 port using a simple terminal echo routine. Receive a character and echo it back to the terminal program. This will wait for a couple of days as I am out of town tomorrow. Rather than mess with the RS232 just now I got straight on with the temperature sensors. The ambient temperature sensor should have a linear response to within +/-1°C between -40°C and 100°C so there is no need for a lookup table. Some scaling binary maths were required in the code to suit the analogue to digital 5 V reference but it is working just fine. Note. The ambient temperature sensor draws approximately 1 mA and as a consequence self-heats with a time constant of about 90 seconds in free air. This results in an initial change in ambient temperature measurement of no more than +1°C from turn on at a measured air temperature of 18°C. Calibration of the sensor output also compensates for self-heating over the rated temperature range of the sensor. I am using three thermometers (two digital and one mercury in glass) for initial calibration. The thermometers vary by no more than 1°C at a room temperature of approximately 18°C. I haven’t got time to input the thermocouple look-up table this evening but displaying the amplified thermocouple voltages gave a first up reading of 20°C and 32°C. This is exactly as expected from the previous offset voltage measurements +/- nothing! If we subtract these offsets which are largely temperature invariant and add the ambient then the output will be within +/- 1°C of the thermocouples’ absolute accuracy. I have also implemented a real time clock in software that keeps track of the time and provides one second ticks for initiating measurement cycles. The hardware that I have made is not capable of measuring all three temperatures (the two thermocouples and ambient) at the same instant in time. The actual time delay between each of these measurements is approximately 200 us (0.0002 s) repeated exactly every second. I could easily reduce the time delay between readings to 100 us and the total cycle time to about 10 ms but there is no need for this. The minimum half wave AC power cycle to the elements is 100Hz (10 ms), the thermal lags in the controlled system are expected to be at least several seconds, and the thermal response of the thermocouples will also be relatively slow – perhaps several seconds. I am about to implement the thermocouple look-up tables which should not be particularly difficult. There are a number of approaches to implementing these depending on storage availability and processing time. I have opted for fastest processing as the code and the look-up table occupy just one third of the available flash memory, with most of the controller routines implemented. The only real challenge was preparing the data in an appropriate format to cut and paste into the code. I used Microsoft Excel and prepared the inverse mV to °C data from two standard ninth order polynomials for K Type thermocouples (published by NIST). The calculated values are accurate to within +/- 0.06 °C and rounded to the nearest °C (there is little point in displaying a significantly greater precision than the instrument is capable of achieving). The thermocouple inputs are working beautifully. They are stable at ambient temperature, rise rapidly to about 670°C when heated with a butane lighter flame and (with heating removed) return to ambient. The next task is to get the RS2323 port sending time-stamped data and temperatures to a computer for analysis and work on the Microsoft Excel real-time graphical display. The first step should be straight forward. The second is expected to be a challenge. With the RS232 port working I was able to evaluate the temperature measurement functions of my controller using a simple free terminal emulator and Microsoft Excel. The first test was a butane lighter applied to thermocouple. The heating response was rapid with an intuitively nice looking negative exponential temperature decay.
The second test was using both thermocouples connected at opposite ends of a steel terminal block connector, again heated with a butane lighter. The curve shape is good but there is a worrying temperature differential between the responses that is clearly temperature dependant. This suggests either a temperature gradient over the terminal block or an appreciable gain differential between the thermocouple amplifiers. I measured the passive gain resistors in-circuit and the gain differential is just 0.1%! So the problem must be with either the thermocouples or a thermal gradient (possibly caused by the difficulty of keeping the butane flame steady and in the same place).
Figure 6. Butane Flame on Terminal Block - TC1 & 2
The final test was with both thermocouples connected to one end of the terminal block and my soldering iron connected to the other. I swapped the thermocouples between the input channels – if this was a thermocouple problem the other channel would now lead. The thermocouples tracked beautifully within +/- 2°C to almost 300°C and these errors can be almost entirely attributed to ADC noise and software rounding (both of which could be improved through software but this isn’t necessary). The temperature measurement functions of the controller are completely within design specification.
Figure 7. Soldering Iron on Terminal Block
My next task was to write the Excel real-time temperature monitoring function. This took a wee bit longer than expected (actually the best part of three days) even though I chose to start with some VBA code from the Internet which does not require any Excel Add-ins ( http://dev.emcelettronica.com/serial-port-communication-excel-vba). The challenge was getting the data transmission and reception synchronized. The code is not quite complete as I have yet to find an elegant way to end the logging session (Ctrl Break and Esc work but they are hardly intuitive), and there still exists the potential for sync. failure. I can fix these issues but their solution is not pressing. The good news is that the data is graphed dynamically and stored in the spreadsheet as a record of the heating cycle for subsequent analysis.
Figure 8. Monitor Program
Time for some experiments with the toaster oven and a real PCB to gain an understanding of the oven’s thermal characteristics. I had originally contemplated welding the thermocouples to a prototype panel but this proved to be impossible because of the HALS lead free solder on the pads. Often times when preparing instrumentation for fire resistance tests we riveted the thermocouples to the specimen. This provides a secure thermocouple mount while ensuring good thermal contact between the thermocouple and the board.
Figure 9. Riveted Thermocouples
The test panel comprised 1.2 mm thick double sided FRP with 35 um (1 oz) copper, HALS lead free solder, a green solder mask, and no silk screening. Both the ground plane (lower side) and SMD upper side were better than 90% copper clad. My initial tests were to examine the board temperature response to a stepped input. These should give me the thermal lag of the oven and maximum attainable rate of temperature rise. I removed the radiation shield from the oven’s upper element and reassembled the oven case. Two step-response heat and cool tests were completed using the same panel (in part to examine repeatability). The test procedure was straight forward. The toaster oven was manually set to the ‘toast’ setting (which bypasses the thermostat) and the mechanical timer was set to 15 minutes. I started the Excel monitor program, turned on the controller board, and after 60 seconds applied power to the oven. Once the temperature reached about 300°C I turn off the oven, then opened the door a bit, and continuing monitoring until the thermocouple readings were within a few degrees of ambient. While all this was going on I was also taking observations of the board and photographs of everything.
Taking photographs of everything includes the specimen (PCB board) and the instrumentation. Just occasionally logging files will get corrupted and a photo or two gives you a back-up, albeit not perfect, of an experiment that you can never repeat exactly. I know of more than one instance where a photograph of the instrumentation allowed for subsequent analysis after instrumentation failure. And photographs of the specimen may record details that you simply didn’t observe during the conduct of the experiment.
Figure 10. Panel Test 1 Measurements
My preliminary findings are as follows. 300°C is too hot, even for a brief period. The solder masks on both sides of the test panel had started to bubble and char, and central component pads had begun to lift and the FRP substrate had been burnt. These effects were more pronounced after the second test due to the earlier degradation and change in colouration. Overheating also caused white smoke and a horrible smell that I will be living with for the next few days.
Figure 11. Cooked to Death Panel
(after second test)
The maximum rate of temperature rise in the first test was was approximately 1.3°C/s at 225°C after 200 s, reducing to 1°C/s at 275°C (thermal losses increase at higher temperatures so the maximum rate of temperature rise decreases as the system becomes hotter). The maximum cooling rate with the door closed was 0.8°C/s at approximately 285°C which occurred approximately 63 s after the oven was switched off. The cooling rate increased to 1.3 °C/s at a temperature of approximately 216°C about 11 s after the oven door was opened. The system has a thermal lag (time difference between element on to 63% of steady state rise) of about 34 s for heating from ambient. With a closed door the time between element off at 298°C and the maximum temperature of 308°C was 13 s with a 10°C over-shoot The maximum temperature difference between the two thermocouples during the heating cycle was 10°C which occurred at the maximum temperature. The maximum temperature difference during cooling was 21°C which occurred after the oven door was opened. The maximum temperature difference that occurred during the heating cycle between the two tests was 7°C approximately 100 seconds after the element was turned on. I have a second set of tests to complete with a new panel positioned off centre in the oven to look at the spatial thermal distribution, but this will wait for now.
Conclusions The unmodified oven is not capable of achieving the desired temperature profiles for reflow soldering. I definitely need to move the lower element to the top of the oven and fit some decent radiant heat reflectors above the elements to improve the maximum heating rate and heat distribution. This needs to occur before I do any more tests. Ideally the oven should be capable of achieving a temperature rate of rise of 3°C/s at around 250°C. I need some form of forced air cooling. Ideally the cooling rate should be controllable up to 6°C/s at an initial temperature of around 250°C. The temperature differences between thermocouples and between tests were promising. It should be possible to have the heating and cooling cycles reproducible to within about 10°C at any point in the heating cycle. Future tests should limit the maximum temperature to about 260°C.
Aside from modifying the oven I have two minor improvements to make to the monitor software and four controller board software structures to complete: - the control module that reads and interprets the controls (three push buttons and a rotary encoder). Easy.
- the command shell that changes modes. Easy (flow chart written already).
- the PID controller that uses the desired temperature profile and feedback from the thermocouple temperature measurements to control the heating elements. Difficult (while I have a reasonable grasp of system control theory I expect that implementation will not straight forward).
- the error detection software and a watch dog circuit. Moderate – but I have some ideas.
The significant challenge will be to implement the controller function. We need a fast thermal response with minimal overshoot, controlled rate of rise, reasonable control in the steady state, relatively fast cooling and system robustness against thermal load and oven changes. Best I get on with the oven modifications so I can retest the oven and make some progress. 5 September 2013 and I finally got around to moving the toaster oven elements to the top of the oven cavity.
Figure 12. Elements at the Top of the Oven Cavity
With the elements at the top a further test was completed. The oven was turned on after 1 minute, turned off after 3 minutes and the door opened after 4:30. The logged results of the test are shown in Figure 13.
Figure 13. Elements at the Top
The graph shows a rate of rise of 2.35°C/s between 100°C and 200°C. As with the previous experiments there is a temperature difference between the two thermocouples, but it is more pronounced, being 14°C at the maximum recorded temperature of 273°C after 200 s. By limiting the maximum board temperature to 273°C the board is completely serviceable (nothing has been burnt) and my office has remained free from the smell of burnt FR4! You might also notice a 1°C rise in the ambient temperature after about 180 s. This is due to the self-heating of the ambient temperature sensor and could be avoided in future by switching the controller on and allowing it to stabilize for a minute or two before starting the experimental measurements.
Figure 14. Baked (but Not Burnt)
The maximum cooling rate with the door closed was 0.83°C/s increasing to 1.33°C/s after the door was opened. The cooling rate is very similar to previous (as expected). Thermocouple TC2 cooled faster than Thermocouple TC1 after the door was opened because it was closer to the door. There are a few extra holes in the oven cavity as a result of the element repositioning. These had no significant effect on the oven’s performance. This clears the way for additional holes for fan forced air cooling. My next mission is to reduce the temperature differential across the board by increasing the spacing between the two elements. The target temperature differential is less than 5°C. The received radiation flux at a point on the board is a function of distance and the view angle to both elements (and a whole lot of other parameters which are of lesser importance in this application). Arguably I should have done the maths before moving the elements - but better late than never. While a conical element configuration will achieve close to icentropic radiation (this is why cone calarometers use conical heating elements) there is not a great deal I can do with my existing elements other than vary their spacing and their height above the board. Using Excel I have calculated the radiant heat flux from the 40 mm separated elements to the board, approximately 95 mm below. I have simplified the maths by treating the heating elements as infinite line emitters. The problem then simplifies to two dimensions. Radiative heating is relatively quick and FRP is not a great heat conductor so I have ignored conduction losses. The board is horizontal so I have ignored convective losses. The heated board surface re-radiates to the interior of the oven but the relative temperature differential between the board and the oven cavity should be much smaller than between the elements and the board so I figure can ignore this too.
Figure 15. Optimizing Element Spacing
The calculated radiant heat profile for the existing 40 mm element spacing and the optimized 115 mm spacing are shown in Figure 15. Note that there are no y axis units - this is relative received radiation flux. The maximum usable oven width is indicated by the vertical red (existing element spacing) and blue (proposed element spacing) dashed lines. The optimized element spacing provides a useful reflow board space approximately 120 mm wide x 180 mm long. Of course there is no free lunch with thermodynamics so the penalty will be a reduction in the maximum rate of temperature rise. The slight dip in the received radiation flux in the centre of the oven will be evened out to some extent for boards with relatively high copper coverage due to thermal conduction across the plane of the board. There will be more to follow just as soon as I have found time to reposition the elements and run another test... 11 September 2013 and I have re-positioned the heating elements at 115 mm between centres, patched up the holes in the oven cavity and completed a further test using the previous board. The results are shown in Figure 16. Just for fun I placed some lengths of 0.5 mm diameter flux-cored lead-free solder on the sample board. The oven was turned on after 1 minute, turned off after 3 minutes and the door was opened after 4 minutes.
Figure 16. Even Heating Across the Board
Key results were:
the board did not burn, the solder only partially melted, heating was even across the board profile, and the edge of the board closest to the oven door cools more rapidly than the centre (as occurred in earlier experiments).
The maximum rate of temperature rise was around 2.2°C/s (somewhat better than anticipated) and perfect for achieving the required reflow temperature profile. During the heating period (from 60 s to 180 s) the measured temperature of thermocouples TC1 (centre of the board) and TC2 varied by no more than 5°C (at about 95°C) and were typically within 2°C. As the maximum temperature differential occurred at approximately 95°C it may well have been caused by differing board moisture content. The soak time temperature profile will resolve any issues here. The 0.5 mm diameter solder didn’t fully melt (see Figure 17) because there was no soak time, no flux on the board lands, and the maximum measured temperature of 240°C was held for just 10 seconds. For proper reflow I need to go above 245°C for at least 20 seconds.
Figure 17. Soldering (almost).
The next step is to build my isolated mains switch so I can place the toaster oven under processor control. 26 November 2013 and the power switch is finally built, tested and installed in the oven. See Figures 18 to 20. During testing there were two issues that required some thought. The first was that the opto-isolator was not dropping the Zero Voltage Switch comparator input low enough (below 1.4 Volts). This was fixed easily by changing out a single resistor. The second issue was that with a light test load (around 12 W) the switch didn’t seem to be working. The problem was that the test load was too light for the gate pulse duration (about 200 us) so the Triac did not achieve latching current (~35 mA) for the switching quadrant. This won’t be a problem for loads greater than 100 W (the oven elements are rated at 1,500 W).
Figure 18. Isolated Power Switch (Top)
Figure 19. Isolated Power Switch (Bottom)
Construction and assembly were straight forward. The power switch is thermally shielded from the oven cavity wall by an aluminium bracket. The PCB is mounted on insulating sleeves (ideally these would have been ceramic but I have settled for nylon because this is all I have on hand and they can’t perform significantly worse than the plastic components in the original oven controller. The mounting location is aligned with existing louvres for free vertical convective cooling. The only component on the switch expected to get hot (a 2 W 18K resistor) is mounted high. All wiring is crimped or clamped as opposed to soldered, and is either high temperature rated or covered in fibreglass insulation. And I have also moved the power cord mount from the bottom (how stupid is this) to the back of the oven. I have wired the electronic switch in parallel with the existing thermostat and timer, and both are in series with a thermal fuse. This configuration means that I can still use the oven from the existing front panel controls to make toast or whatever.
Figure 20. Isolated Power Switch Assembled Mounted in Oven
When taking measurements on mains powered circuits it is advisable to use an isolating transformer rated for the anticipated test load and appropriately fused. Most test instruments and bench power supplies will have the reference potential connected to mains ground (earth). An isolating transformer will prevent an accidental short circuit through the instrumentation ground. Note that an RCD or earth leakage breaker may protect your equipment from damage if they are fast enough, but they won’t allow you to measure potentials relative to phase. Isolating transformers rated at over 1,000 W are heavy and rather expensive. Short of rebuilding a transformer (which isn’t particularly difficult but is very time consuming) you can improvise for light loads by connecting two similar step-down transformers back to back. Figure 21 shows my improvised isolating transformer. It works very nicely under light loads and as a bonus it provides double insulation.
Figure 21. Improvised Isolating Transformer for Testing
There are four final construction issues to complete the oven.
1. Mount the 5 Volt DC isolated controller socket. 2. Refit the neon power indicator (one of the leads on the original was too short and during handling the other one broke off right at the current limiting resistor). I may have to get my welder out for this job, or replace the neon. 3. Fit the cooling fan. The back of the oven cavity looks promising. 4. Sort out the permanent mounting of the thermocouples.
I still need to complete a few more tests under power control to confirm that my model of the oven is sufficiently accurate. Once I am satisfied with the system transfer function I will be doing some maths to convert this to a prediction model for the controller. This isn’t a classic PID design but it promises better response and control than the original thermostat. 25 March 2014 (a long time between drinks) and I have found time to sort out the first two construction issues (above). The oven is now fully functional under digital control and still works using the original controls. Items 3 and 4 (the fan and the permanent thermocouple mounts) will wait for a bit. I have started on the first software implementation of the system prediction model and expect some useful results in the next few weeks.
2 June 2014. Time for an update on this project. The golden rule for controllers (of any sort) is that they should be as simple as possible subject to the desired accuracy, response and stability. I have a few temperature time curves for the oven from my earlier experiments (see Figure 10). It is immediately apparent that there is a significant time lag between turning on the element and reaching a steady temperature increase. To achieve the desired temperature profile we need to be able to predict the future temperature output on the basis of previous heating history. I have two relatively easy options for achieving the desired temperature profile. - The first is open loop control where, through trial and error or a model, I determine the appropriate element power over time. This cannot compensate for system changes such as ambient temperature.
- The second approach is similar to the first but with element power initiated by oven temperature. This scheme should compensate for changes in ambient temperature and some aspects of the thermal system (such as the heat capacity of the circuit board being soldered).
I have also got a heap of more complicated systems that I could implement using predictive control based on numerical convolution . This would give us the actual the predicted temperature and the desired temperature at any time. However I am using a relatively low speed 8 bit microprocessor that I fully anticipate will be challenged by numerical precision, and this is in conflict with the Golden Rule (simple). Let’s try and implement Method 2. As a first step I need to develop a model of the oven’s performance. Models are a simplified representation of the system under consideration. Interestingly we can model the oven as a thermal system or, somewhat more abstractly, an electrical or mechanical system. In essence we have a heating element with a delay, a heating time lag and instantaneous Newtonian cooling. When we apply power to the element it takes some time before the final heating rate is achieved and any time that the oven temperature is above ambient it is cooling. There are a number of simplifications evident in the model. All of the thermal heating lags (element PCB, thermocouple, oven) are lumped into a single parameter and we are making no distinction between radiant, convective or conductive heating. The simplified system is represented in Figure 22.
Figure 22. Simplified Thermal System
My preference is to model the system as an electrical network as shown in Figure 23. Here, V1 represents the input power, the input resistor R1 limits the rate of heating, the inductor L1 represents the thermal lag of the system, the capacitor C1 represents the heat capacity of the PCB (and oven), and the output resistor R2 represents the cooling function.
Figure 23. Electrical Analogy of Figure 22
The electrical network transfer function, H(s), in the (complex) s domain can be completed by inspection (any undergraduate electrical engineer should be able to do this without hesitation):
[1] The s domain transfer function can be converted back into the time domain using the appropriate inverse Laplace transform, but this is a classic second order over-damped system and we can use tabular methods to get the general solution of the form:
[2] I am reasonably confident that there is also a delay in the thermal system (referred to as a transport delay in control theory texts). We can incorporate at time delay in equation [2] as follows:
[3] Now what about all of these coefficients (the k’s and alpha’s)? In a practical sense they have real meaning with regard to the oven’s performance as follows: - k1 - k2 is the initial oven temperature, which is the ambient temperature, Ta.
- k1 is the final oven temperature (after waiting to infinity) for a unit step (continuous power) input from some initial time, .
- a1 and a2 are the time constants for the system.
- k2 is a little more problematic. In practical terms it ensures that cannot go below the ambient temperature, and cannot exceed the final oven temperature. We will solve for this shortly.
But this is only half of what we need. In order to predict the oven’s response from an arbitrary input history we need the unit impulse response, u(t), which is the time derivative of h(t). We can calculate this in the s domain by multiplying equation [1] by s, however equation [2] can be readily differentiated directly in the time domain to give:
[4] Now from time t < td, u(t - td) is necessarily 0 because the output of any practical circuit (even a straight wire) needs time for the driving signal to propagate. At t - td <= 0 all of the exponentials in equation [3] equal 1 so that:
[5] From my earlier experiments I can now estimate the coefficients (the k’s and alpha’s). - Ta = 15°C
- k1 is about 680°C based on extrapolation of the experimental heating curve.
- k2 = -665°C
- td is the time delay which is about 9 seconds from the experimental heating curve.
- a1 is the heating time constant. This is best estimated early in the experimental heating because the rate of cooling is low at relatively low temperatures and can therefore be ignored. I have estimated a1 from the experimental results as the time for the heating curve to reach 63% of its maximum value. This gives a1 = 1/15 s which (because of the cooling function) will be a high estimate.
- a2 is the cooling time constant. This is best estimated at the time we would expect the oven to reach about 80% of its final temperature which I figure is about 1/350 s.
We can compare the unit step model with our experimental heating curve by plotting equation [3] directly as shown in Figure 24.
Figure 24. Modeled Unit Step Response
Okay, the result isn’t perfect but the model is a simplification of reality and some of the parameters have been estimated by extrapolation. However it will probably do for the purposes of our analysis. If necessary we can tweak the parameters to get an improved fit later on. We can also see how well the model predicts the experimental cooling by using discrete convolution of equation [4] as shown in Figure 25.
Figure 25. Modelled Heating and Cooling by Discrete Convolution
The convolution solution shown in Figure 25 looks quite reasonable (although it does not track the cooling after about 300 s when the oven door was opened in the experiment). We can use this result to quickly determine an input heating sequence that will give us an optimum reflow curve in the middle of the reflow envelope . In essence this is trial and error but by numerical solution. Coming up with a heating sequence took just a few minutes. Coding took a few days implemented as a state machine. In essence the code uses the current oven temperature to determine whether or not to apply power to the oven, and if so, how much. The LCD displays progress through the heating cycle (heat, soak, ramp, critical, reflow and cool) and a number of timers are used to indicate the duration of each state to ensure they are within the heating envelope. The controller sends temperature measurements and time to a serial port from where it can be graphed in real time. With the code written and tested it was time to apply it to the oven for real. The initial results are shown in Figure 26. The general shape of the thermocouple curves (TC1 and TC2) compare favourably with the model to about 350 seconds when the oven door was opened and the cooling rate increased. However the oven heating appears to be more rapid that in my earlier experiments. After some thought I have concluded that this is due to the relatively low losses of the electronic controller compared with the oven’s original thermostat (the latter having mechanical contacts, a series heating element and conducting bimetallic strips). As a consequence I need to readjust the model parameters and adjust the state machine code. I can use the experimental data from this latest test (Figure 26) for this purpose.
Figure 26. First Attempt at a Reflow Profile
As an aside the current oven performance is extremely close to acceptable margins. The only specification failure is the reflow temperature and duration. Ideally we want to exceed 245°C for 30 s. The experiment only reached a maximum temperature of 244°C for 9 s. Note also that the oven controller hardware and software allow for fan control for forced air cooling. This will provide faster cooling than opening the oven door, but less than 6°C/s. Although I have the fan (a 12 V plastic cowling computer-cooling fan) I have not yet made an insulating gasket for mounting it to the oven. The cowling is required to ensure that the fan does not melt if the oven gets too hot. After adjusting the model parameters and making up some new thermocouples with proper welded terminations I have re-run the lead free solder cycle from a number of different start-up conditions. I am getting excellent repeatability for any given initial oven wall temperature. The interior of the oven heats above ambient during the very first cycle. As a consequence the board cooling rate decreases substantially resulting in acceptable, but somewhat shortened, total cycle time for further heating cycles. Note that in the experiment that lead to the curves of Figure 27, the green (TC2) trace is the oven cavity free-air temperature. The low thermal mass of the thermocouple responds more rapidly to heating and cooling cycles than the printed circuit board as expected. As usual I have opened the oven door at 217°C so the cooling curve profile deviates from the model from this time.
Figure 27. Refined Model Parameters
For the record, the controller is now achieving the follow time temperature profile against limits. | Parameter |
| Minimum
| Experimental
| Maximum
| Time to Critical
| Ta to 217°C
| 115 s
| 182 s
| 480 s
| Soak
| 150 to 200°C
| 60 s
| 98 s
| 180 s
| Ramp Heating Rate
|
| -
| 1.8°C/s
| 3 °C/s
| Critical
| > 217°C
| 60 s
| 80 s
| 150 s
| Reflow
| > 245°C
| 20 s
| 30 s
| 40 s
| Max. Temperature
|
| 245°C
| 253°C
| 260°C
| Max. Cooling Rate
| Door Open
| -
| 2 °C/s
| 6 °C/s
|
|
Table 1. Oven Performance The current thermocouple printed circuit board has been subjected to about 20 reflow profiles and is absolutely none the worse for wear. There is no sign of solder mask char or lamination bubbles. With the reflow profile established I have attempted lead free soldering using flux-cored 0.5 mm diameter wire solder (and with no components). The results were only partially successful (see Figure 28). The reason for this is that the reflow oven actually heats the board which then melts the solder. While solder paste is in good thermal contact with the board, conventional wire solder makes for lousy thermal contact, hence the solder temperature is closer to the green TC2 free wire curve in Figure 27 - and too low for reflow. That said, where the wire was in contact with the board the solder melted, flowed and was subjected to surface tension that drew it onto pads. These are excellent signs.
Figure 28. Attempted Lead Free Soldering
There are several aspects of the current controller that could be improved. - Soak time should be increased by 22 s to 120 s.
- Critical time should be increased by 25 s to 105 s.
I need to incorporate the oven wall temperature in my heating model (in essence as a replacement for ambient temperature, Ta) or implement slope (derivative) control over the Soak section of the cycle in order to get the soak time closer to optimum. There are numerous ways I can extend the critical time without affecting reflow time. The easiest to implement this is probably a short duration heating cycle during cooling after the temperature has dropped below the reflow limit of 245°C. I’ll be carrying out these modifications in slow time because the existing controller should be completely adequate for reliable lead-free reflow soldering. I figure I should also incorporate a leaded solder reflow profile (similar to Pb free, but with lower temperatures) and a proportional oven controller.
While I have some more stuff to do (mount the fan, fit the thermocouples in a more permanent fashion, put the controller in a box with a power supply, and tweak the Soak and Critical times) this project is essentially done. The final test requires a solder mask, some solder paste and SMD components. The mask and the paste are on order, and I will be reporting on the first ‘for real’ experiments in due course.
In recent weeks I have ‘discovered’ the Maxim Semiconductor 31855. This IC is about $10 (one off) but should be an improvement on my current thermocouple interface as it provides the zero reference junction and a heap of other functionality, with reduced hardware and code overhead (no lookup tables or conversion routines). If I were starting from scratch I would be using these IC’s.
12 December 2014 and I have decided to remake my reflow controller. The main reason for this decision is that the current circuit board was not particularly well thought out for case mounting (my dumb). But this rebuild also allows me to incorporate the Maxim Semiconductor 31855 in the design and replace the RS232 serial interface with a USB 2.0 connection. This last refinement is a necessary progression because serial ports are no longer widely provided on computers. The computational overhead required to bit-bang a USB port is too onerous for my current processor so I have settled on a truly tiny USB to serial bridge device from Silicon Labs (the CP2104) which contains its own clock and comes with a complete set of Windows drivers. The hardware design is complete and the components have all arrived.
With the USB interface and the precision of the new thermocouple ICs I have decided to extend the functionality to allow oven control from the computer through an ASCII command set. In this mode a controller can be implemented in your favourite programming language. My next mission is to make the new board. It is slightly larger than than the previous version because the layout has been optimized for the LCD display, mode switches, IO terminal blocks, and a nice case. The good news is that most of my earlier code will be directly usable. Apart from a few hardware changes affecting ports, the major task is developing the command interpreter.
A problem has arisen with my new design. While I can make the boards the physical size of the USB Micro B connector and the QFN 24 USB bridge make reliable soldering is a real issue without a solder mask and stencil. I have messed around for almost a week trying to make a stencil using laser printed toner transfer but the results are marginal so I have redesigned the board for commercial manufacture and designed a number of stainless steel rework stencils for the major components.
The new board and solder stencils are on order. I have also 3D printed a new case for the controller. This project is on hold until the new board arrives.
20 February 2015 and the new board and solder paste stencils have arrived today. The new board fits the case perfectly. Hopefully I can get on with populating the board in the next few days. I have designed this particular board for leaded solder because I want to keep the temperature down for hand hot air soldering of the USB bridge IC and the USB socket.
The solder masks for this project are a set of general rework masks (some are shown in Figure 29). They are stainless steel and were manufactured by commercial laser cutting as a single sheet for economy. With a bit of care they should last forever. When the sheet arrived I carefully cut it into individual rework masks using nothing more advanced than a pair of scissors, gently flattened any minor bends caused by cutting, ground the edges true using an oil stone, and bent up a 45 degree corner using a pair of pliers to for easy handing and positioning using a pair of tweezers.
I have left a fair bit of space around the apertures but this can be trimmed back for tight rework. For asymmetric pad layouts I have made two masks in different orientations for optimum placement. For very tight work it may be necessary to use the mask to apply paste directly to the replacement IC. Masking other stuff with Koptan tape is a good way of protecting against inadvertent solder paste placement and protects from reflow heating.
With larger components such as 0603 resistors and capacitors I can manually apply solder paste directly onto the pads with a syringe, but for really fine pad spacing, and particularly for QFN packages with central connections, a solder paste mask is almost essential. Note that you can solder these by hand without a solder paste mask using a soldering iron but at considerable risk of failure or damaging the integrated circuit.
Figure 29. Part of my Set of Rework Masks
My next mission was to experiment with applying solder paste using the masks. I have a 500 g tub of date-expired paste which is ideal for testing my technique. I started attempting prints onto a sheet of plain white paper using a piece of Perspex as a squeegee, and holding the mask in place with tweezers. The results were somewhat hit and miss. Sometimes I got a perfect print but about half of the prints had incomplete pad coverage or print smear.
One problem was ensuring that the mask was clean. Wiping it with tissue is not a good idea as this leaves very fine fibres in, and bridging the apertures that detrimentally affect the transfer process. I now use a lint free linen cloth. The second aspect to cleaning is to use a very fine soft bristled brush with alcohol to ensure that the mask apertures are completely free of paste. This problem appears to be made worse by printing onto paper which seems to absorb the liquid flux in the paste, leaving relatively dry solder paste stuck in the apertures.
After doing some research I decided to try several different squeegees. I tried a microscope slide which was worse than the Perspex. After doing some on-line research I tried a safe edge razor blade which, unlike the perspex and slide, provided some flexibility. The first attempt with the razor caused some very minor scratches on the surface of the mask. I reworked the edge of the razor with a fine oil stone to ensure it was flat and true. The second attempt was much more satisfactory.
Hand holding the mask was proving to be difficult (and causing smear) so I taped one edge of the mask opposite to the bent up corner with a small piece of adhesive tape. This worked very well and allowed me to lift and drop the mask using the tab without smearing the printed solder paste.
With the paper printing working it was time to attempt to print onto a board. My initial results are shown in Figures 30 to 33. These solder paste prints are completely satisfactory. Although the 32 lead TQFP print is slightly misaligned the solder paste does not bridge between pins and will centralize on the pads when it melts due to surface tension.
Figure 30. 32 Lead TQFP Solder Paste Print
Figure 31. 32 Lead TQFP Print
(0.8 mm between pad centre-lines)
Figure 30. 24 Lead QFN Solder Paste Print
Figure 31. 24 Lead QFN Print
(0.5 mm between pad centre lines)
With the solder paste application sorted I will be completing some hot air soldering experiments with leaded solder paste before moving on to populating my new controller board.
Well I almost managed to start my experiments today - but I plain ran out of time. In essence I am trying to reproduce a lead tin solder heating profile using a hand-held hot air gun. Profiles vary between components and manufacturers so I have decided to use the JEDEC profile shown in Figure 32.
Figure 32. JEDEC Profile
(Lower curve is for lead tin solder.)
There are quite a few variables that I can adjust including air temperature, flow rate, distance, nozzle size, nozzle movement, and time. There are a number of other variables that I am stuck with including the board thickness, the component, and the pad layout.
I figure on setting the air temperature to about 260°C (20°C above the maximum), selecting a nozzle size to provide full component coverage, and selecting an air flow rate that won’t blow components off the board at a distance of about 25 mm (1”).
The basic procedure will be to start at a nozzle height of about 75 mm (3”) and hold, directing hot air around the component and observe the temperature rise, then gradually decrease/increase the nozzle separation to achieve the preheat profile to 150°C over two minutes. Then decrease the nozzle separation distance over about 80 seconds to obtain a temperature of at least 225°C, hold for about 10 seconds, and then gradually remove the nozzle over 60 seconds.
I’ll be using my old temperature controller to interactively measure and adjust the board temperature in conjunction with an IC on printed solder paste. I got to complete my experiments today. After a bit of trial and error I have developed the following procedure which gives a reasonable estimate of the desired reflow profile for leaded solder paste.
I’m using a Tenmar Reflow Station with an 8 mm diameter air nozzle and a 70% air flow rate at a temperature of 350°C. I hold the nozzle about 75 mm above the mounted part for about two minutes moving in slow circles directed at the part. I then progressively reduce the height (at a rate of about 25 mm/minute (1”/minute) until the paste melts. Then I hold at this height continuing with slow circles directed at the part for a further 10 seconds. Finally I increase the height back to 75 mm (3”) continuing with slow circles directed at the part, and hold for a further minute.
Here are the results of using this procedure on my new reflow board.
Figure 33. 24 Lead QFN with Ground Tabs Under the Chip
(Photo at 45° to show connections.)
Figure 34. Micro USB Connector with Frame Connections Under the Part
(Photo at 45° to show connections.)
My new masks and the hot air reflow procedure worked well. The only minor drawbacks of this technique are that you end up soldering the semiconductors before the passive components, and you may have to mask previously soldered components with Koptan tape (or similar). All of the integrated circuits and the SMD crystal are now mounted on my new reflow board. I have a few passive components to hand solder using conventional cored solder and an iron before I can get on with programming and testing.
The new hardware is essentially assembled. I have a few final connectors for the control switches and the power LED to fit, some mounting screws to attach the board to the case base, and some hot melt gluing to attach the LED and switches to the case top. My very next task is completing bench testing and initial programming. Here are some photos of where I am at today.
Figure 35. Assembled Board Fitted to Case Base
Figure 36. Case Top on with Cable Access Panel Removed
The initial hardware tests have been completed. Rail voltages, current draw and the power LED check out just fine. Time to move on to some software to test all aspects of the hardware.
The first step is to map the processor I/O to ensure that it is initialized to the appropriate state. This has resulted in finding one definite error and one probable error with the board layout. There are three communications buses on the board. Two (the LCD and the USB interface) are dedicated but the third Serial Peripheral Interface (SPI) bus serves the temperature transducer IC’s (TTIC) and the system ISP (In-Circuit Programming).
I have made an error with the connection of the data lines on the SPI bus to the temperature transducer IC’s by inadvertently swapping the MISO and MOSI lines. This is somewhat annoying but not fatal. Thankfully it is easily repaired by cutting a single track and inserting a wire bridge. The printed circuit board design has been adjusted.
The probable error is more interesting. The SPI bus has multiple masters that can initiate and control the bus. Under normal operations the processor is the master and initiates communications with the TTIC’s. However during programming the processor is a slave, and simultaneous slave responses from the TTIC’s on the very first attempt at programming, when the processor I/O is not defined and the TTIC’s are likely to be enabled, will almost certainly screw up the programming responses. I need another jumper on the board to either disconnect the SPI clock or the MISO connections from the TTIC’s during the programming cycle. The board modification has been completed and thankfully my MISO/MOSI patch will serve this purpose.
So I’ll be having the soldering iron on again in the next few days, while the software can continue to be developed.
28 February 2015, and my hardware-test software is written and compiling without error. There is a lot of stuff to test here including the audio alarm, the mode switches, the LCD display, the fan control and drive, the oven control, the thermocouple IC’s, the USB interface, and the real time clock. I hope to be programming the processor in the next few days using a new commercial USB interface (as opposed to my serial STK500 development platform. If I get this process wrong then there is a significant risk of turning my beautiful hardware into a paper weight - I have done this before today with other projects. I anticipate no problems with the hardware but some significant stuffing around with the USB interface software. The Win7 x64 drivers have been compiled and registered but this process is bordering on black magic.
Two late developments. I’ll be reverting to my SDK500 ISP programmer because my new USB ISP boards are strictly 5 Volt systems. The processor rail in my controller is just 3.3 V and I can control the programming voltage with the SDK500. I have also found another board error - having inadvertently mirrored the ISP programming socket in the board design. The board design has been fixed, but I will need to wire an adapter for programming the current board.
1 March and the board has been successfully programmed and the LCD, beeper, push buttons, fan and element control are working.
There are problems with the SPI communications with the thermocouple ICs and the USB bridge. The SPI chip enable lines are working but there is no activity on the serial clock line (and as a consequence, no activity on the MISO line), yet the processor master is progressing through the byte transfer loop. I know that the SPI bus is working because it is used for In Circuit Programming (ISP). So I am doing something wrong with the processor ISP master configuration.
The USB issue is a little more perplexing. In the first instance the drivers would not load under Windows 7 because they were not Microsoft certified. Then I couldn’t find a USB cable with a Micro B USB connector.
Figure 37. Board Utilities Under Test and All Working
2 March and after a few hours of effort all of the board utilities are now working. The SPI problem was due to the processor serial clock output being defined as an input. With this resolved the thermocouple IC’s are working just fine including reporting ambient temperature and open/short faults on the thermocouples. The USB issue was resolved by purchasing the appropriate cable, finding some certified drivers, and resolving several configuration issues with the processor USART and my terminal program. The USB bridge is in a simple loop back test mode for now. I send some stuff from my PC using a Terminal Emulator, the on-board processor receives it, triggers a received character interrupt, and sends the same character back to the PC.
I am particularly pleased with the USB interface which is low cost, has a very small footprint, just three passive external components, provides an on-board 3.45 V regulator that powers pretty much everything except the LCD, and will readily replace the serial ports that I have used on numerous previous projects.
The next step is to take my old controller code and port it to the new hardware and put everything into the 3D printed case. I expect that this will take a few hours, but I have made enough progress for today.
Notes on Temperature Accuracy
The best book I have ever read on this topic is ‘Traceable temperatures, an introductory guide to temperature measurement and calibration’ by Nicholas and White, Science Information Division, DSIR, Wellington, New Zealand, 1982.
While the MAX31855K cold junction compensated thermocouple to digital converters are functioning perfectly, it is interesting to reflect on their contribution to the accuracy of temperature measurements of this system.
The limits of error for a K Type thermocouple to BS 1041:4 - 1966 are +/- 3°C in the temperature range of 0°C to 400°C. Our instrumentation errors will add to these error bounds. We can’t do better than this without calibrating or thermocouples (whose response will also change with each heating cycle and with time) or selecting another temperature transducer.
The MAX devices assume a linear relationship of 41.267 uV/°C for a K type thermocouple throughout the specified temperature range of 0°C to 1,000°C and a cold junction sensitivity of 40.73 uV/°C throughout the specified temperature range of 0°C to 70°C.
The specified accuracy of the MAX31855K is +/- 2°C from -200°C to 700°C but, in a very small note, the data sheet also states:
‘Not including cold-junction temperature error or thermocouple nonlinearity.’
K type thermocouple (and thermocouples in general) do not have a linear response. The K type thermocouple output has a local minimum at about 200°C where the Seebeck coefficient drops to about 39 uV/°C. This is very near to our critical maximum temperature for reflow soldering. If you think the positive temperature differences due to K Type thermocouple nonlinearity are bad then you might be interested in researching the negative temperature differences.
Figure 38. Anticipated Error due to Thermocouple Non-Linearity
The cold junction temperature accuracy of the Max 31855K is stated to be +/- 2°C over the temperature range of -20°C to 85°C by design.
The resolution of the MAX31855K is stated to be 0.25°C. This is adequate for this design but has bearing on the absolute accuracy of our temperature measurements. It is an order of magnitude (factor of 10) less than the basic accuracy of a K Type thermocouple in our temperature range of interest.
Analogue to Digital Converters (ADC’s) aren’t perfect. The MAX31855K data sheet provides two graphs relating to the ADC accuracy and both temperature and Vcc. Unfortunately this information is far from complete.
What does this all mean?
In the first instance my previous analogue design had a significantly greater absolute accuracy and less variability than the MAX 31855K.
The temperature reported by the MAX 31855K will be less than the actual temperature by about 4°C at 260°C. This error is consistent and predictable.
The error bounds over our temperature range of interest are -7°C to +11°C While these are, in a sense, absolute we can expect that under actual operating conditions (limited ambient temperature, low ADC input voltage, good thermal design, regulated Vcc, low power dissipation, noise suppression, etc) we can expect much better performance.
If I want reliable reflow soldering (and I do) then I need to incorporate a look-up table in my code to adjust for thermocouple nonlinearity, and maybe do some calibration too.
I have written the look-up table extending from -200°C to 1,200°C to give the temperature controller a little more utility. The thermal fuse in my toaster oven will fail well below 1,000°C and the plastic components in the oven will probably catch fire for a sustained temperature much above 350°C. This is a double byte look-up table and consumes rather a lot of memory. However it is significantly faster and more accurate than attempting to solve a ninth order polynomial approximation using multi-byte arithmetic. Interestingly there are some temperature values that simply don’t appear in the table because of the lookup precision of 1°C (there is absolutely no point in reporting temperatures to 0.25°C with the current design approach). This may have consequences for temperature control and I will need to take to care to ensure that temperature comparisons for the controller are completed using >=, or < operators.
Getting the thermocouple nonlinear compensation right has taken some thought. The key to this is that a thermocouple’s output voltage is a function of the temperature difference between the hot and cold junctions. So the nonlinear compensation scheme must first subtract the cold junction temperature, then apply the lookup table, and re-add the cold junction temperature. We don’t want to be applying the nonlinear thermocouple correction to the cold junction measurement because this will result in compounding the error.
Figure 39. Monitor Code Running
(LED and switches removed for disassembly)
The monitor code is completed and debugged. There have been a few challenges along the way. For example I have a 16 bit two’s complement temperature value. How do I efficiently convert this to an ASCIIZ value with leading zero suppression and sign? Applying raw logic results in complicated and excessive code. So I paused for a while and considered how my mind solved this problem and came up with an elegant and efficient solution.
With everything working and the thermocouple compensation scheme running it’s time to re-implement the oven profile driver for lead free soldering. Looking at my old code there are some things I can do better.
I have improved the State Machine using indirectly indexed calls. This has saved a heap of code and made for easier program modification and faster operation.
I have changed the element power routines. Previously, the minimum element on time was 1 second. This is fine for course control given the thermal lag of the system but it is hopeless for fine control. I have reduced the minimum element on time to to 0.02 seconds (0.01 seconds is the absolute minimum due to the 50 Hertz mains frequency) and incorporated a Pulse Width Modulation scheme that provides 50 power levels between 0 and 100% with a one second duty cycle.
I am working on improvements to the reflow temperature profile. Most of my boards are about 1 mm thick coloured green or native FRP (white with yellow/green tint) but some (such as the Amigo boards) are somewhat thinner and mat black. Darker thinner boards heat faster than lighter thicker boards so I need to refine the control state machine to account for this automatically. The alternative is to calibrate the controller for each board type. I’m working on it.
With the new USB serial port up and running I have changed the Microsoft Excel event handler to the demo version of ActiveX StrokeReader. Although it has an annoying pop-up window (the demo license doesn’t permit me to disable this) it works fine, allows easy extension of the data parser through Visual Basic, and results in a much more compact Excel file than my previous open source solution (and as a consequence faster file loading and saving).
I am still busy working on my control strategy. While I have a system that works for a particular printed circuit board (colour, material and thickness) my controller needs to have a greater degree of automation in producing temperature profiles, otherwise every new board will require calibration. Here are some things that we know or can at least reasonably assume: - The fastest way to go from the temperature at some instant in time to a higher temperature is fully power.
- The fastest way to go from the temperature at some instant in time to a lower temperature is no power. We can do better than this with fan cooling, but let’s ignore that for now.
- The delay time between applying power and seeing a temperature rise on the board is primarily a constant of the oven.
- The maximum rate of heating of the board is a function of the board and in particular its colour, material and thickness.
- The cooling time is primarily a function of the oven but influenced to a lesser extent by the board.
- Ambient temperature should be relatively constant, and typically in the range of 10 to 30°C. Variations in ambient temperature should have little effect on heating and cooling rates at several hundred degrees Celsius.
My oven heating cycle has a time constant of about 15 seconds. So while we can change the element temperature in epochs as small as 0.02 s we won’t see a measurable outcome until many seconds later. If we attempt to make adjustments before understanding the effect of previous adjustments then our attempts at control are likely to result in oscillatory or unstable behaviour. An interesting example of this comes from my formative days when I used to travel on navy patrol boats on training trips as a cheap means of getting to Great Barrier Island. There was a significant delay between turning the wheel and the boat coming around. Crew under training would turn the wheel, think nothing was happening and so turn the wheel some more. About this time the boat would swerve, usually travelling at relatively high speed, and the wheel would be spun in the opposite direction in an attempt to correct – resulting is a swerve in the opposite direction. As a result of these training manoeuvres the trip was somewhat longer than the commercial option and everyone arrived somewhat ‘green at the gills’. Our controller strategy breaks down into a number of discrete events. - Turn the element full on to get to the pre-heat temperature (150°C).
- About one time constant before the heating temperature we need to turn the element off, and then turn it on again at an appropriate power level to achieve a rapid but smooth (critically damped) transition to the soak phase slope (0.4°C/s).
- During the soak phase ramp we need to turn the power up slightly over time because the cooling rate will increase as the temperature increases.
- About one delay time before 200°C we need to increase the element power to achieve a rapid transition to the desired ramp-up rate through the critical temperature and on to reflow.
- About one delay time before the maximum desired temperature (255°C) we need to reduce the element power to ensure that we sustain the reflow temperature for the desired time (30 s) and at least one delay time before this is achieved we need to turn the element off.
- Below 217°C we can open the oven door or start the fan to increase the rate of cooling provided it remains greater than -6°C/s.
During the very first phase of any heating cycle we can measure the maximum rate of heating for full power at about 100°C. This measurement can form the basis for determining element power settings at other phases of heating cycle. We can also dynamically adjust the power level during the soak phase which occurs over about 120 s to provide a better fit to the desired slope. While I’m working on the control coding I have decided that I need a number of calibration runs on different types of board in order to determine the control parameters. These will be simple heat at full power to 300°C and then cool to 50°C. This needs to be run through the controller for recording time and temperature without the inherent losses that I have previously identified with the manual thermostat.
Almost all of my coding starts with a flow chart which is refined until the code for any block can be written in just a few lines. Here are the flow charts for my current controller. The State Machine state subroutines are written as a fully self-contained prototype for ease of future development. The calibration run software is just over 1300 bytes and with the lookup tables I have used only half of the available flash memory.
The software has been fully debugged (both for the microcontroller and the Excel Spreadsheet. There were a few issues that needed to be sorted out including:
the use of logical and opposed to bitwise compliment,
bit and byte operatives,
temperature comparisons where I had forgotten to take account of the fact that the controller works with signed as opposed to positive integer 2 byte words, and
a key-press detection issue where I had failed to adequately mask some register bits.
I figure I have made some of these mistakes before, and will probably do so again.
Figure 40. High Level Flowchart for Controller
During the software development there were two eureka moments. The first was with the conversion of a signed two byte word to ASCIIZ with leading zero suppression and sign. The more recent one concerns the push button test routine. My initial code simply inspected each key state, compared it to the previous state, determined whether to flag a key event, and then saved the current state. While this worked it was a rather cumbersome approach with lots of comparisons and bit tests. Simple logical function reduction has enabled me to code for all three keys in just 10 lines of code! I’m now ready to run my calibration tests.
Calibration Tests
The calibration tests have been run. As expected black boards heat and cool faster than green boards and thin (0.7 mm) boards heat and cool faster than thicker (1.2 mm) boards. The effects of colour on heating rate are more significant than board thickness. The heating delay time (thermal lag) is pretty much constant.
There were a couple of issues during the calibration runs with thermocouple short to ground faults. These were overcome by using Koptan tape to insulate the test boards from the grounded oven. The calibration run deliberately over-heated the boards because I was interested in recording the natural cooling rate at 250°C. This resulted in slight burning and de-lamination of the black board FRP and board warping at the mounting clips.
Figure 41. Calibration Curves for Board Thickness and Colour
Figure 42. Cooling Curves for Board Thickness and Colour
There is enough information here for me to program the controller to automatically adjust for board colour and thickness. If I measure the rate of temperature rise between say 50 and 100°C then we can use this to estimate the board cooling characteristics and therefore determine the element power levels required to maintain the desired reflow profile.
A slight problem that I need to address is the rate that I am measuring temperature information (currently every second). The maximum heating rate of the oven is about 3°C/s and the resolution of the temperature measurements is 1°C so I need to increase the frequency of temperature measurements to at least four times per second. The current software executes a state loop in about 30 us so I have plenty of processing bandwidth. However this creates a problem with my existing power percentage routine which needs to operate over one or more seconds for 1% resolution (although the oven element is controlled by zero crossing switch this information is not available to the processor). I have decided to change the basic processing loop frequency to 0.01 seconds and establish two additional software counters (in addition to the real time clock used to trigger USB communications) to obtain temperature measurements every 0.1 seconds and for power processing. This approach is slightly more complicated than my previous hardware-triggered timing and power processing routines and will take a few days to write.
The controller state-machine software is now ready to run and should automatically adjust the heating for any board to achieve an optimised profile. I will be running a number of tests over the next few days to tune the design.
15 April 2015. My reflow oven is finally automatically producing reasonable profiles (with plenty of error margin between acceptable limits) for lead free solder processes with 0.7 mm to 1.2 mm thick boards with either green or black solder masks.
Figure 43 shows a typical set of profile curves. Interestingly I have abandoned using the 50 to 100°C rate of rise to set parameters because this cannot distinguish between thin green and thick black boards. This can only be done at temperatures above about 170°C for the slow initial heating rates required by the JDEC reflow profile. I might revisit this later.
Figure 43 Reflow Curves for Board Thickness and Colour
(Oven Door opened at 217°C during cooling.)
But how well does the reflow oven solder? I have completed several trials with four 1.2 mm thick boards with green solder mask located in different parts of the oven. The lead free solder paste was observed to melt at about 220°C which is somewhat lower than the anticipated 245°C transition temperature. Figure 44 shows a typical resulting solder joint which is remarkably bright and shiny for lead free solder.
The rate of temperature rise to melting is too low to explain the temperature discrepancy. Further, the thermocouple response is relatively fast and there are no other signs of elevated temperature such as solder splatter, board warp, mask bubbles or char.
My first thought was that the reduced melting temperature was caused by alloying with the leaded HASL finish on the test boards. To test this theory I put some paste strips on the solder mask away from any pads and re-ran the experiment. The lead free solder was still melting in the range of 217 to 221°C. What is going on?
Figure 44 Soldered SO8 Package The cause of this problem is the design temperature profiles that I have used (shown in Figures 2 and 32 above). The lead free solder paste I am using is Multicore 318 made by Henkel. The product data sheet shows that the alloy is liquid above about 220°C which is pretty much in line with my experimental observations. Figure 45 provides a copy of the relevant information from the data sheet. Unfortunately the text is not very clear in this image but it will will do for establishing a revised profile.
Figure 45 RoHS Solder Paste Data Sheet Profile
So I need to adjust my controller profiles to suit the solder paste manufacturer’s profile. While it is unfortunate that this needs to be revisited, the advantages are reduced component and board maximum temperatures and a reduced heating cycle.
Another interesting issue has arisen during the soldering tests. With several boards in the oven the heating rate reduced significantly over that observed with just one board. A further set of experiments has confirmed that this issue is caused by the oven drip tray which was located about 20 mm below the board plane. The tray is very shiny aluminium and reflects radiant heat from the element to the underside of a single board. When a number of boards are placed in the oven they partially shield each other from underside radiant heating. With the tray removed the heating rate is reduced even further but there is little difference between having one or many boards in the oven.
So I have some more work to do, but I am soldering with the oven and all of these tests have been a good workout for both the controller and the oven.
While I have been concentrating on the reflow application I have forgotten about my need for a general purpose oven controller (based on oven cavity air temperature as opposed to the heat on the exposed surface of a printed circuit board) and using the controller as a general purpose temperature logger. I have started re-coding to include the full range of anticipated uses starting with a revision of the menu system and the associated displays for proposed states. While this sounds like a lot of work it is tedious rather than complicated. At the end of this process I will have a general purpose controller that will do RoHS or PbSn boards, act as a general purpose oven controller, or as a simple computer logging temperature monitor.
A lot of the computation that is going on is associated with the processing and display of time and temperature information. Processing efficiency is therefore relatively important in these routines. I have improved the computational efficiency of the binary to ASCII conversion and LCD driver routines over the past few days.
The original binary to ASCII conversion routine used the brute force method of repetitive division by decreasing powers of ten (10,000, 1,000, 100, and 10) using repetitive subtraction. This works and is relatively fast but processing time is variable subject to the binary number being converted. There are more efficient algorithms. I have re-written the conversion routine using a nibble (4 bit) based shift, compare and add algorithm. The new code is of similar size to the brute force method but it performs significantly faster on average. While hardware computational power continues to increase over time, significant improvements in processing speed and code size can often be realized by optimising algorithms.
I have revisited the LCD driver routines looking specifically at the processing time for data transfer commands and the hardware timing cycles for write operations. This has resulted in a significant saving in processing time (subroutines that previously took about 5 ms are now executing in less than 50 us).
The current virtual USB port implementation is operating at a lousy 19,200 bps (bits per second). So transferring five 2-byte numbers complete with control characters and stop bits takes at least:
((5 * 2 characters) + 7 control characters) * (8 data bits + 1 stop bit)/ 19,200 bps = 8 ms! My simulator suggests that with other stuff going on such as interrupt processing, temperature reading, error detection and character processing the actual time is closer to 12 ms. While not essential, I may yet increase the baud rate to reduce the USB data transmission time.
The code framework is now documented (with no change from 29 A4 pages), debugged and compiling without error. The code is a compact 2,266 bytes with a further 3,018 bytes of data (primarily used for thermocouple non-linearity adjustment). And I still have 35% of processor program memory to play with! The solder profile routines, universal temperature logger and oven functions are all but complete (just a few days of effort to finish) but the command processor remains as a shell for now simply echoing received characters. If I start to run low on processor resources (unlikely) then the command processor it will be deleted.
The code that I have written is pretty much oven-independent. There are just a few dozen parameters that determine the temperature control functions and profiles. While these are currently stored in non-volatile program memory I could readily move them to EEPROM and make them user-adjustable to suit any other toaster oven. This idea is on hold for now until the current project is completed.
The new controller is now debugged and up and running. The USB logging and error sensing are faultless. I have just a few minor non-critical tweaks to improve some aspects of the user interface, incorporate the parameter tables for the reflow profiles, and add the oven control algorithm. Here are a few screen shots showing several of the 29 basic user interface displays.
Figure 46. Selection of User Interface Displays
Notes on Time of Temperature Measurement
With data logging the actual time of record measurement is often critical.
The current unit takes temperature readings every 0.25 seconds but the measurements do not occur exactly on the 0.25 second transition and the measurements occur serially (one after the other). The MAX31855 data sheet does not provide enough information to determine exactly when a temperature conversion occurs, but the conversion cycle is less than 0.1 seconds (and typically 0.07s). Further, the two MAX31855’s are not synchronised. The time between an 0.25 second event occurring and reading of the first temperature is 8.25 us exactly. The time from initiating reading of the first thermocouple IC to reading of the second is 56.38 us exactly. The software delays are insignificant compared to the MAX conversion cycle.
This means that relative to any 0.25 s event the first thermocouple measurement could have been completed 0.1 seconds earlier and both temperature measurements will have occurred within 0.1 s before any 0.25 s event. The time between measurements and the event are not constant (they will vary over time).
What does this all mean? For my toaster oven the maximum rate of temperature rise is about 3°C/s and I am taking temperature measurements to a resolution (this is not the same as precision) of 1°C every 0.25 seconds. Sequential temperature measurements cannot vary by any more than the resolution so the MAX31855 is adequate for this design. However for rapid temperature changes or increased temperature resolution maybe an analogue temperature stage with reference junction compensation and synchronous sample and hold is the way to go?
4 May 15. The user interface tweaks have been completed, my initial soldering profiles are loaded and I have programmed a proportional oven controller with a 12°C proportional band. I fully expect that the solder profiles will need tweaking for optimum performance against the solder paste manufacturer’s recommendations. I have some more heating experiments to do.
I have also been experimenting with the implementation of the oven controller. This simulates well for high set temperatures but has significant overshoot and takes some to stabilise at low set temperatures (say less than 100°C) due to the reduced rate of oven cooling. The simple proportional controller will be fine for now.
I have completed my initial tuning and the results are usable but not ideal. Figure 47 shows the Henkel RoHS Profiles with the Blue curve showing the experimental results for a 1.2 mm thick black solder mask PCB. While the curve is close enough to the middle of the acceptable profile range (Green curves) the soak time is determined by temperature, and the slope is relatively small and somewhat variable between different boards. I have decided to change the software to force the soak time as opposed to trying to accurately control the slope.
The cooling rate isn’t great yet by I have still to put a cooling fan on the oven. The curves indicate the absence of a fan should have no significant influence on the quality of the reflow. While slow cooling adds to the profile time it has the advantage of reducing thermal stress across components.
Figure 47. Experimental Time Temperature RoHS Profile
(Blue Line in the Middle of the Green acceptable range)
While I’m experimenting I have also looked at the performance of my simple oven proportional controller and the original oven thermostat. I chose a relatively low test temperature of 100°C because the oven cooling rate is particularly slow at low temperatures. The results are shown in Figures 48 and 49.
Given that the software for the controller is just 19 lines of code the results are quite pleasing. Sure there is some initial overshoot, but the software implementation rapidly settles to 105°C +/- 1°C. Proportional controllers depend on an error difference between the set and actual temperature so I need to incorporate integral control to remove the offset. I can reduce the output ripple but improving both the controllers output power resolution which is currently a convenient 8% but could readily be reduced to 2%. I can also reduce the initial overshoot by increasing the width of the proportional band and/or adding differential control.
The original oven thermostat’s long term average temperature stability is about 80°C +25°C/-8°C with an overshoot of more than twice the set temperature at 100°C. I figure it would be almost impossible to achieve a reasonable reflow profile using manual control of the thermostat, even with an accurate temperature display.
Figure 48. Original Toaster Oven Thermostat Set at 100°C
(Blue curve is 1.2 mm Black PCB controlling thermocouple.
Green curve is 1.2 mm thick Green PCB)
Figure 49. Simple Proportional Oven Controller Set at 100°C
(Blue curve is 1.2 mm Black PCB controlling thermocouple.
Green curve is 1.2 mm thick Green PCB)
The tweaking is all but finished and the reflow profiles are pretty much where I want them as shown in Figures 50 and 51. The toaster oven and controller now automatically provide optimum profiles for the full range of board thickness, solder mask colour and lead free or leaded solder pastes that I usually use.
The very next time I have cause to play with the code I will reduce the peak temperatures by about 3°C, and increase the PbSn soak ramp slope fractionally. This should be a simple five minute exercise (where have I heard that before?).
Figure 50. Full Set of PbSn Profile Experiments
(zeroed at the start of soak at 120°C )
Figure 51. Full Set of RoHS Profile Experiments
(zeroed at the start of soak at 150°C )
And finally Figure 52 shows a PbSn test profile (one of numerous solder tests completed at the same time as the profile curves in Figures 50 and 51 were being run). The solder is smooth and bright with nice fillets under the SOIC leads. There is no evidence of solder balling and no residue flux that I can detect.
Figure 52. PbSn Profile Test
So I still need to add the fan and put the controller back into its case. The fan drive and triggering are already implemented so it should be as simple as finding some insulating board, drilling a few dozen vent holes, and bolting the fan to the back of the oven. Otherwise this project is essentially done. Turtle Tank Temperature For some time I have been wondering about the long term temperature stability of Yurtle’s tank. The tank holds about 750 litres of water that should be maintained at about 27°C. It is fitted with two 200 W thermostat-controlled elements. Sure, I can take spot temperatures with a standard mercury-in-glass thermometer but with my logger up and running I thought it would be interesting to measure the temperature over 24 hours at two different locations in the tank.
Figure 53. 24 Hour Temperature Logging with the Turtle Tank
As Figure 53 shows, there is nothing extraordinary happening at all. The temperature is nice and stable despite changes of a few degrees C in the ambient temperature (which is actually 2°C lower than the reported reference junction temperatures due to the previously discussed self-heating). As a result of this experiment I did discover a minor error with the log clock routine which was being reset every 552 s as opposed to every 600 s when set to 10 minute log events. A quick look at the code shows that I mistyped a hexadecimal constant. The last thing that I want to do before I put the electronics back in the case is an improvement in my oven controller - essentially adding integral control to the existing proportional control to remove the offset shown in Figure 49, and maybe reduce the extent of the initial transient over-shoot. I am using my earlier Excel oven model (refer to the text around Equation 4 a long way above) for sorting out the optimum proportional range and the proportional and integral gain factors. Well the first implementation of my PI oven controller was a disaster (see Figure 54 and compare with Figure 49 above). The oven initially heated in the proportional range as expected but over-shot the set temperature and then ramped very quickly to full power. I turned it off before it got too hot and reflected on the likely causes.
Figure 54. Oven PI Controller Disaster
(Controlling Thermocouple is Red TC2 trace. Set temperature is 100°C.)
The first issue was that I was using a thermocouple riveted to a black 1.2 mm thick PCB as the oven temperature controller, and had placed it upside down (with the thermocouple on the opposite side to the heating elements). This caused both a significant initial over-shoot followed by a significant response delay. The second issue was that integral controller was designed on the basis of temperature updates every second, yet the code actually updates temperatures every 0.25 seconds to ensure that temperature changes between successive measurements are not greater than 1°C. The integral control rapidly saturates. The third issue was to do with the integral processing which involves sums and differences of one and two byte signed and unsigned variables. This gives rise to the possibility of subtraction of a negative number from a negative number suddenly becoming positive (-127 -10 = 119!, or in one byte hexadecimal 0x81 - 0x0A = 0x77). How embarrassing!
These issues are readily resolved. I will use a free thermocouple junction in the oven cavity for measuring the cavity temperature (TC1 in Figure 54). I will reduce the integral gain by a factor of 4 to account for the 0.25 second temperature readings, and I will look carefully at establishing variable limits when processing the integral control to avoid clock arithmetic.
Figure 55. Oven PI Controller
(Better - but not yet ideal. Set temperatures are self-evident.)
Well I’ve carried out the code modifications to the PI controller and we are making good progress as shown in Figure 55. You will note that there is still some temperature overshoot (about 5%) after 270 seconds but the the oven is within +/- 1°C of the set temperature after about 400 seconds. The overshoot is caused by what is termed ‘integral wind-up’ and is consistent with the increasing absolute overshoot with increasing set temperature. I can improve this by delaying the onset of integral control or reducing the integral gain. The current performance is still a significant improvement over the oven’s thermostat and the proportional-only controller. The oven’s cavities actual temperature is somewhat dependant on the positioning of the sensing thermocouple which is currently located in the plan centre of the cavity about 100 mm below the centre plane of the elements. While I have not completed a comprehensive set of roving thermocouple tests, with the 200°C set temperature in Figure 55, I found variations of +/- 10°C across the oven tray plane. I may be able to improve this once a fan is fitted by stirring up the convection currents with a quick fan burst every 10 seconds or so. At this stage I have just one code adjustment to make to reduce the integral wind-up, a few more tests including transient response, and then if all is going well, the controller can be permanently mounted in its case. Note that although the reflow profiles are specific to my toaster oven the software has been written to be truly universal within the effective range of K Type thermocouples. It will handle logging and control processing over the range -200°C to 1,200°C and is therefore readily adapted to a furnace or a fridge control with minimal software modifications.
Triac Failure The IP controller is now working with virtually no overshoot and good transient response however, as a consequence of prolonged testing with transients I have damaged the triac switch that I mounted in the oven. The issue is clearly associated with over-temperature. After an hour of oven heating the oven case becomes appreciably warm. Although the triac doesn’t dissipate very much heat (say 1.5 W worst case) the junction to ambient thermal resistance (no heat sink) is around 60°C/W. So the triac junction is about 90°C above ambient, which gets above 50°C after a prolonged period of oven use at elevated temperatures. During a transient (oven door open) the triac gets switched hard on resulting in maximum power dissipation. The triac junction gets too hot and then turns on all by itself through leakage to the gate. The solution is easy - replace the triac because it has probably been damaged, and heat sink the new triac to the base of the oven (the coldest part). Just to add to my frustration the Com Port drivers for my computer’s IDE dual serial port card have magically disappeared? I use a serial port for driving my STK500 programming environment so they are kind of important. As an interim measure I modified a USB ISP programmer and spent some time getting that up and running. Then I found a main board Com Port which has been sitting unused. I enabled the port through the BIOS, wired up a header to connect it to the outside world and the SDK500 is back in business. I have removed the old IDE port card and will put in in another machine before continuing my driver search (the main chip is a Moschip MCS9835CV with a couple of RS232 drivers). The triac has been replaced (Figure 56) and I have finished my oven PI controller tests complete with 20 second oven door open transients after 600 seconds (Figure 57). The overall performance is somewhat better than my previous effort shown at Figure 55. The initial heating time to set temperature is about 20% faster, overshoot is within 5% of set temperature, and final temperature settles relatively quickly to set temperature.
Figure 56. New Triac Switch Mount
(Triac insulated tab is bolted to aluminium plate on base of oven.)
Figure 57. New Oven Profiles
(with 20 second oven door open transient from 600 seconds)
Figure 58. Assembled
While I could tweak some aspects of this controller forever it is assembled in its case and ready for reflow, logging or oven control.
| 
雷达卡
发表于 2017-2-19 17:11:11
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
分享
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2017-2-21 09:05:02
