I have bought this oven -

. The main reason for this was to bake some PCBs. As with every reflow oven, this one needs temperature control as well.
I have baked several pcb without problem with unmodified oven. But that might be luck, as the temperature profile is nowhere near perfect.
I have therefore decided to make some simple temp controller to take care of the whole soldering process. As my oven features fan, I will probably want to control it as well. The contoller should not to need any special programmer (mega can by programmed with BP) and the board should be etch-able at home.
Schematic:

- The whole thing is based around mega8 chip. There should be enough space for some pid, ramp generator, and menu. Oscillator is internal RC 8MHz.
- User output is through 8x2 lcd display. Tiny display that will fit to the control panel nicely. This display is driven in 4-bit mode, to limit number of IOs. Backlight can also be controlled by the mcu.
- User input is encoder with button. Both encoder pins are interrupt. Button is polled to save some nasty logic needed to multiplex.
- Temperature is sensed by thermocouple and converted to digital using max6675, that i had lying around. Datasheet is saying that data is available every ~200ms. Little slow, but enough for this purpose. Big plus is cold junction temperature compensation and polynomial compensation.
- Output is 2 channel PWM, 0-Vin. Both to be used to drive SSR (solid state relay). These relays can be bought off fleabay for about 3-6dollars/pc (free s/h).
- Serial port is used to talk to bootloader, and to transmit temperature for further analysis (pid tuning)
- Powered by 5.70-12V, voltage is regulated by micrel mic5202-5.0 (same as on BP)
There is no programming port for the atmega8. It needs to be programmed with bootloader before the max6675 is soldered. Reset and MISO pads are for this purpose.
The board:

The board is a bit larger than the lcd itself. Most difficult part is to solder the header. That needs to be replaced by smd version in next release. The board is designed to be piggibacked on the lcd. Small hack is Pot to set the lcd contrast. There was no smd pot available near, so I decided to solder miniature trimmer to the pin header directly from bottom side.
Board is single side pcb, with 2 jumper wires.
Finished board:


This board was not etched at home :-). It was made some local company that does UV etching, and they also apply silver coating to protect the copper.
There are few modifications not present in the picture above - gnd on middle pin of the thermocouple connector, voltage divider for serial port. Some parts are missing, and are not needed for lab testing (mic5205 voltage regulator, and big through-hole capacitor).
Thermocouple used is from sure electronics:

The thermocouple does take a while to cool down and I wonder if it is suitable for this purpose.
For user input I use incremental encoder, bought at local store. This seems to be not a good quality build. Tends to jump randomly back and forth.

The software:
Probably the hardest part. This part is still in development. So far the every peripheral can be controlled.
Finished is: encoder, button, display, max6675 temperature reading, PWM output, pid controller.
There are still missing parts like: ramp generation, user interface.
I will provide board/schematic files here on request. The software will be provided as well, once finshed.
Nice!
Did the Dangerous Toaster never get off the ground? ... or is this slightly different? The picture of your oven did not show up, although the schematic and board do appear.
a generic temp controller would be cool, I've been thinking about cooking sous vide in my crock pot.
I've been thinking about cooking sous vide in my crock pot
Indeed.
The picture of the oven is on my other hdd (one that failed :(, of course there is backup (-: ) *picture* is just a placeholder.
The temp controller is actually the most recent project of mine, it will be finished this week, I hope :)
I guess I uploaded some code for the Dangerous Toaster project. It is from a PIC24 book used in my microprocessors course. Maybe they can be helpful while developing the firmware.
Still have no idea what "Dangerous Toaster" is ! :-)
[quote author="robots"]Still have no idea what "Dangerous Toaster" is ! :-)[/quote]
You don't want to know ;)
[quote author="robots"]Still have no idea what "Dangerous Toaster" is ! :-)[/quote]
I would have said "Dangerous Toast-R-Oven" but some U.S. company would probably have their lawyers contact me...
sparkfun has listed their old oven,
I would have said "Dangerous Toast-R-Oven" but some U.S. company would probably have their lawyers contact me...
it is a posibility if they determine they don't like dangerous used with their trademark
becoming a bit ot ....... as it was supposed to be one of my project's log. :-P
Dangerous Toaster was the name of a reflow oven controller design discussion and I have made some boards that I am testing right now.

My intent was to keep it as simple as possible and use the power of a PC to manage profiles, data collection and plotting. The software is a based on the software I did for the USB LCD Backpack. The board drives a SSR or Power Switch Tail.
McZ
Seems like the two projects (Dangerous Toaster v. Reflow oven controller) could be combined in some ways. Rather than have the entire system be managed by the ATmega (UI and operations), or entirely managed by a connected PC, perhaps the duties could be shared. A PC front end would allow a more comfortable user experience, but hopefully the time spent in the UI would be minimal. The PC could then download the desired profile to the ATmega as a data set, stored in a designated area of Flash (or EEPROM), and then the oven could operate on its own. Such a split of duties could lower the costs by alleviating the need for an LCD, but still not tie the oven to a PC 100% of the time. The LCD would still be a nice touch as an optional confidence display, perhaps even to select among multiple profiles stored in Flash (if there is enough room).
FTDI is convenient, but I tend to prefer having local firmware under control. It's also safer in the event that someone trips over the USB cable and unplugs the USB host during a bake. But I'm just tossing in my two cents. International exchange rates may vary.
There are so many version on the web using either Atmel or Microchips. I was thinking about something different. So in the scheme of DP I was trying to KISS and keep the cost down. I have designed many variations of the circuit some very advanced with color graphic LCDs and as simple as the FT232R.
On the other hand if the hardware is simple the software has to be more complex.
The new BP with the PIC24FJ should be able to control this circuit through it's USB OTG.
BTW, the 555 in the circuit is a watchdog so in case you trip over the USB cable or the PC gets BSOD the relay turns off.
McZ
[quote author="MichaelZ"]BTW, the 555 in the circuit is a watchdog so in case you trip over the USB cable or the PC gets BSOD the relay turns off.[/quote]
That's a cool idea, but then the oven stops working. With a PIC or AVR, the oven would continue to function unless it totally lost power, which means there's no hope of working anyway.
But I see your point - there are lots of designs out there.
The software I am working on, (yet to be documented) will have everything stored in eeprom: pid settings, multiple temperature profiles. I want to make it configurable though the UI, but there will be possibility to upload the eeprom (there is bootloader capable of this).
Realtime temperature data is going to be available on the serial port, so user can graph temperatures. (not planing any frontend for this, gnuplot is good enough).
Still wonder how much program space will it take. So far 1k is taken by bootloader, and the sw that is described in the 1st post has ~3k - thats 50% already !
There was quite a bit progress in the software development. I have successfully added menu to the device.
Have few options:
- run profiled "cooking" - 2 profiles.
- run constant temperature "cooking"
- configure each profile
- configure pid parameters
- reset defaults for pid/profile1/2
- restart system (bootloader enter)

What is to be added is the actual editor for the values.
So far 5.5k of flash is used. 7k is limit. 1k is used by bootloader.
Bootloader:
bootloader is modified avr109 bootloader- also known as arduino bootloader, even though it existed long before arduino did :-). Modifications are to save some space. Byte memory access is removed completely, and only neccessary funcions are left, so that it works with avrdude. Bootloader is entered by reseting the device and user has 2 secons time to talk to the bootloader. After timeout user application starts.
BTW ... 1st post updated, pictures, pictures :)
[quote author="robots"]For user input I use incremental encoder, bought at local store. This seems to be not a good quality build. Tends to jump randomly back and forth.
The software:
Probably the hardest part. This part is still in development. So far the every peripheral can be controlled.
Finished is: encoder, button, display, max6675 temperature reading, PWM output, pid controller.[/quote]
The poor quality performance of the encoder could be due to the software or the hardware or both. The photo shows exposed wires, and if you touch those when rotating the encoder, it might affect the output. Also, I believe that the scan rate of the firmware can affect whether the performance is smooth or jumpy. Finally, you may need some kind of debounce on the encoder returns - logic bounce could be a possible explanation for the random jumps.
Do any of the Dangerous Prototypes projects have firmware with support for rotary encoders?
I have used several routines for reading rotary encoders. The one that has work well for me is at Rotary Encoder Demonstration (http://http://www.waitingforfriday.com/index.php/Rotary_Encoder_Demonstration). I have used it with the SparkFun Rotary Encoder (http://http://www.sparkfun.com/products/9117) without any issues.
[quote author="rsdio"]
The poor quality performance of the encoder could be due to the software or the hardware or both. The photo shows exposed wires, and if you touch those when rotating the encoder, it might affect the output. Also, I believe that the scan rate of the firmware can affect whether the performance is smooth or jumpy. Finally, you may need some kind of debounce on the encoder returns - logic bounce could be a possible explanation for the random jumps.
Do any of the Dangerous Prototypes projects have firmware with support for rotary encoders?[/quote]
Scan rate is not a problem. Encoder is hooked to interrupts, so every transition is caught Problem is that the encoder is mechanical, and has similar problem as bouncing buttons. And also it is not brand new, and has been played with. So the mechanics might be a bit loose.
I will probably add some external capacitors for the debouncing.
Wonderfully done project so far! I've been looking for a simple solution to my lack of a reflow controller and this looks to be the first real project to solve it. I take it this will become a kit after final testing is done? ;) I sure hope so.
[quote author="robots"]I will probably add some external capacitors for the debouncing.[/quote]
Sounds promising. Let us know how that turns out.
I found it ! (the time to have some more fun with this project)
So I added 100n capacitor to each encoder output, and now the glitches are gone. Makes me happier to be with one less problem to solve :-)
So the TODO list is:
- add parameter setting menu
- test pwm outputs
- test on real toaster.
- test, tune, test, repeat as necessary :)
[quote author="robots"]I found it ! (the time to have some more fun with this project)
So I added 100n capacitor to each encoder output, and now the glitches are gone. Makes me happier to be with one less problem to solve :-)
So the TODO list is:
- add parameter setting menu
- test pwm outputs
- test on real toaster.
- test, tune, test, repeat as necessary :)[/quote]
:D w00t! Glad to hear of the encoder issues are gone.
Note to self: I do hate cpus with 2 separate address spaces !
I have finished the parameter setting menu. Parts of the menu have been moved to program space to save ram.
It does make pretty nice errors once you start messing with the stack :)
I have finished the firmware. Now it is time to put the electronics inside the oven.
It seems that Chinese manufacturers like screws with triangle head. :-(
There is a github repository for this project, you can have a look at the source code.
https://github.com/robots/reflow-oven (https://github.com/robots/reflow-oven)
Update: 1st post is updated with picture.
:D A friend of mine sent me a set of security bits that is handy to have. If it is just a flat triangle you can use a blade tip that is the same size as one of the flat sides. I have removed them before this way.
i try to build a reflowovencontroller with your software and i try to understand your PID implementation. I am experimenting with the parameters to get a temperturecurve as for reflowprocess nessesary.
Is it possible that there is an mistake in parameter editroutine?
in pid.c is
int16_t pid_limit_default[4][2] PROGMEM = {
{-256, 256},
{-256, 256},
{-512, 512},
{0, 4095},<--- low/hight Limit
in menu.c you edit as follows
.text1 = "Set high",<<<<--------I think this must be "Set low"
.text2 = " O limit",
.type = MENU_VAL_I16,
.p = &pid_limit[LIMIT_O][0],<<<----- high should be [1]
Is it possible that the other PID limitparameters have the same problem in the Editparameter menu?
Do you have from your own experiance parameters that i can try to use? with the default parameters it is not really working with my oven.
Christian
Well the software was never really put to test, I have locked out my mega8 on the controller (due to relatively high voltage 8v) and i have had no time to replace it yet :-)
Default parameters were NOT tested in reflow oven, they were just tested with blinking led as "heater".
And yes there might be some errors in the menu. I haven't tested the controller much. I have had no time last few months, and my reflow oven is just collecting dust :(
If you have any patch for the source I would be glad to accept it ;)
Old project, but:
The MAX6675 has no polynomial compensation, I don't know where you got that...
IMHO Also a very expensive chip for a hobby board.