The firmware on this machine, quite frankly, sucks. It doesn't adhere to profiles correctly, nor does it have any real form of PID control. In addition to this, the thermocouple interface is a giant pile of rubbish and is wildly out of spec most of the time, making this machine almost completely useless when you want consistent results. This project fixes all this and more with a hardware and firmware modification.
This oven has a few unique features over the popular T-962 oven, which makes it slightly more desirable if you don't mind the higher cost:
an internal convection fan built in.
fume exhaust system which you can vent outside.
insulation and thermal tape is actually decent, so it doesn't give of nasty smells during operation.
overall build quality is much better.
However, unlike the Unified Engineering mods to the T-692, the BRTRO-420 is slightly more difficult to modify, mostly due to the unobtainium build chain for its microcontroller along with a few other design issues such as a poor and noisy thermocouple interface. So the decision was made to spin up a mod board that can be soldered to the bottom of the existing board.
All the firmware sources and board files are here.
All code, documentation and design on these project pages are licensed under the GNU General Public License (GPL) unless otherwise stated.
There's now a screenshot command which generates an XBM bitmap over the serial port. Here's a few screenshots for your viewing pleasure. Note the ticks on the profile display, each tick represents 20 degrees (or 5 degrees per pixel) across the Y axis. As for seconds, each tick represents 20 seconds (or 5 seconds per pixel) across the X axis.
If you check the update to the previous log entry, the board temps were getting up to 290 degrees Celsius. So after thinking about it for a bit, the thermocouples floating inside the oven are basically next to useless for any sort of temperature regulation as they don't correlate to any meaningful and reproducible temps, no matter the board colour.
Now it's time to replace the thermocouples. The main issue is how to route the thermocouples. Firstly the existing thermocouples are glued into the chassis, so removal is difficult. And secondly, where they come out is a bit tricky from a cable management point of view, since the tray slides in and out (i.e. how are you going to deal with the excess lead and how do you stop it from knocking parts off when you slide it back in).
So to deal with this a new route was found. This was actually easy to do without any mods as the forced air extraction system already has a way to go without modifying the case (there's a small hole for entering this section which the power lead for the secondary fan goes through):
Inside the flue section on the left of the image above, there is some vent holes that go into the case, so you can just feed the thermocouple through those vent holes and you're in. Be careful when putting the case on now so the thermocouple wire doesn't get crushed.
Now inside the case, you can feed the thermocouple on the right side of the tray in the grove and you can tie off the excess with some steel wire such that it moves under the tray when you slide in and out in a concertina fold, leaving just the end piece to worry about when positioning it (i.e. just tape it to the board and you're done).
With all that done, you can now get an almost perfect thermal profile and it's guaranteed to correspond to the actual board temps. Note I was using two board colours in this test and the graph is drawn based on the average of the two temps.
The LCD display also gives you a nice little overlay of the current reflow process, which shows how well it fit the curve:
As you can see, while the oven does struggle a little to keep up with the steep ramp rate required in the reflow phase of this profile, it does get relatively close (despite lagging a little). Tweaking the ramp rates of the different stages will yield fitter results.
The graph will overflow to the other side as well (as you can see with the cooling cycle tail).
Edit: something in the back of my mind from the start was the built in thermocouples not getting as hot as the boards themselves, which is a common problem with IR based ovens. This is more extreme that first thought as a black test PCB got up to 290oC during the reflow phase. As I feared, we are going to have to either create different modes for different PCB colours, or move/swap out the thermocouples to have them contact the boards.
This is tricky, since we have a tray that slides in and out and there are two thermocouples for each zone. Maybe a third thermocouple is required to offset the actual temps (using the built in ones to control PID rates for each zone)? Maybe we can have fixed metal plate that we can permanently have thermocouples attached to on the tray. I think moving to thermocouples on the board is the way to go however as it removes a lot of the guess work.
So the firmware is pretty much complete apart from some more tuning to do. I've created a quick video showing the operation below (apologies for the LCD quality, the sun was out and the light polarisation gets a bit screwy, but you get the idea).
You might notice that it struggles slightly to keep up with an aggressive profile, but the oven doesn't change to the next state until both the minimum current profile stage time and temps are met, to ensure an adequate reflow. This is waaay better than the stock firmware, which would just continue after the profile phase was meant to be up (based on its configuration). So depending on the initial start temp and the amount of effort you were willing to put into configuring the profiles, would end up with many failed reflows on the stock firmware.
This is actually quite a misunderstood issue with a lot of reflow oven firmware out there. Most of the time it's attributed to needing to run an initial reflow cycle to bring the oven up to temperature first, but in the earlier, less critical stages where it might need to catch up from a lower room temp, strict adherence to the profile is less important, especially if below the activation temp of the flux (don't take this as something that should be ignored though). But it is VERY important to get it to the right temp before moving onto the next stages of reflow. It really is in the name of the early stages, "pre-heat" (depending on which nomenclature you are using). We want to use this "pre-heat" stage to "literally" "pre-heat" the oven before moving onto next stages (hopefully that was clear :P).
The LCD also draws the current temps over the displayed profile, so you can check its fitness to the curve. Also displayed is the cold junction temp of the thermocouple interface (as Top). This lets you know how hot the controller PCB/top of the chassis gets.
The oven itself has two separate PID loops for both the front and back elements, which coincide with the front and back thermocouples. These do fight slightly if they have different PID parameters, but for the most part they remain pretty steady as the convection fan stirs the air around anyway to keep things even.
The cooling phase still needs to be tweaked to ramp up the initial fan speed also.
Oh, talking about flow. I've also created a 3D printable shim which reduces case fan noise too:
After ironing out a couple of PCB bugs, things are getting there. A trace got missed on the LCD display and the LEDs won't light up with the current rev of the board without a simple mod. But everything works now without any modifications required to the existing board (apart from putting a jumper on).
One of the buttons (back button) also managed to share the same EXTINT with the zero crossing detection circuit on the SAMC21, so the button is handled separately in the main loop instead (which can cause a missed click every now and then, but it's not that bad).
It also turns out that the original circuitry and power supply was very very noisy, which causes random button presses and other minor undesirable issues like LCD glitches when not redrawing often. The new thermocouples are on their own 3.3V linear regulator, so there isn't much of an issue there. The buttons were fixed by having longer debouncing delays. This goes to show that the original hardware was completely inadequate for the task and the controller should really be replaced from the get go.
Most of the menu functions and profile modification/display features have also been created:
The SAMC21 (nor any of the SAMx2x microcontrollers) doesn't allow you to invert the hardware UART polarity, so you would have a tricky time getting a software UART working if you want to use the Arduino bootloaders (you could forego the bootloader, but where's the fun in that?). Now theoretically, you could use a UART->USB controller that had inverted logic, but most don't seem to.
So instead, there was enough free pads around the UART connectors (these were originally put in to be able to change the RX/TX orientation if necessary) to wire in some SOT-23 PNP based inverters while keeping things relatively neat (take note that the transmit LED needs a current limit resistor too otherwise you just get spikes on the UART bits as the LED starts to dim/burn out due to excess current):
As for the bootloader/core, I'm using a modified mattairtech ArduinoCore-samd (which is a modified ArduinoCore-samd) firmware which has options for the SAMC. The pinouts have changed of course, so a recompile of the bootloader is necessary to get things running.
Now to solder the board on. You want to join the existing leads to the new holes. This is made easier with a fine solder tip and feeding in the solder:
To check that pins have wetted, you can shine a light through the gaps in the PCB:
Also, pop a jumper on the W1 pins near the existing MCU (or bridge them with solder); this is the DEBUG I/F pin. This places this MCU into serial bootloader mode (MD = 0, DEBUG I/F = 0) and effectively renders it inoperable.
New 5mm headers have been placed for the thermocouples. You could reuse the existing ones if you prefer.