Archive for April, 2013


Cheap eBay reflow oven


I recently got a T-962 reflow oven from one of the many front-ends for the same fulfillment shop in California that sells various Chinese imports.  The unit cost $240 with free shipping, and arrived in roughly a week.  It’s the smaller of the two available units, the B model having a 1000W element rather than 800W, and a somewhat larger overall work space.  The unit came shipped in the usual Chinese style: wrap the unit in enough bubblewrap to fill the box on its own, stuff into cardboard box, then add about as much tape by weight (waterpoofing?).  The build quality is reasonable enough at first glance.

I started out with a few small boards (my Xmega DIP adapters) and went with “wave 2” designed for 63Sn/37Pb, peak temp of 225C.  Right off we have our first problem: the UI is horrible.  The screen itself is fine, but the font used is nasty.  The buttons are OK physically, but they’re only scanned once per second(!), which means you have to hold them down until it decides to notice.  Unfortunately, it doesn’t do any state latching, so if you hold it down a little too long, it’ll treat it like another button press.  Apparently debounce and interrupts are too complicated.  Even worse, when exiting some menus, it immediately processes that button press again.  A prime example is anything that uses F4 to return to the main menu: main F4 means “switch languages”….

The next problem is that while there’s a “cool-down” fan in the back, some genius decided that it should blow in to the chassis.  This results in all the solder fumes being pushed out the open bottom of the oven, and into your local atmosphere.  My absolute first modification to the oven will be turning that fan around.  I then need to find a flange with screw mounts for a 4″ flex-duct, at which point I can route the exhaust into my theoretical wall vent and continue breathing actual oxygen.

As you might expect, I took the unit apart to figure out what all is inside.  The answer: an insane amount of very tenacious hot-glue.  They hot-glued everything.  I spent a chunk of time removing all the hot-glue, because it was unnecessary (now that it’s shipped to me…) and because I wanted to actually be able to disassemble it.  I didn’t take any pictures the first time I took it apart, I’ll have to do so again and get all the detail I need.  Unfortunately the fan that needs to be reversed is buried inside several more layers of insulation and silver (duct) tape.  I didn’t dig that far into it yet because I actually need to make certain it’s usable for a while still…

The main board is designed to be split, with the various power stages on one side and the logic on the other.  The MCU is an LPC2134 (ish), with a funky programming header (1×6?) nearby, which bodes well for fixing the firmware stupidities.  A full reverse-engineering of the board will be necessary to figure out all the I/Os, but it doesn’t look like it’ll be a huge challenge.  The good news is that everything looks to be easily controllable, so enhancing the functionality with new firmware should be easy enough.

Just now I did a “large” panel of PCBs, taking up most of the available working space.  Here we find another issue with the oven: it’s not very even.  The panel had a 4×4 grid of boards, and the front row didn’t really come close to soldering in the preprogrammed “wave2”.  I had to not only switch to manual and keep the peak temperature in place for quite a while, but I had to open the tray and very carefully rotate the entire panel 180deg in order to put the unsoldered boards in a hotspot.

New firmware could fix this by running the “cooldown” fan at a very low speed during heating cycles.  The bottom of the unit might need to be taped up in order to force incoming air to enter from the front of the chassis and pull across the boards, though I haven’t looked at the bottom much.  The other advantage of doing this is that the “preheat” stage where the flux fumes start to off-gas would be exhausted to the outside.

At some point when free time actually exists, I’m hoping to hack up new firmware (after swapping out the chip if it’s code-locked, so I don’t kill it completely) and make it a bit more viable.


Crazy-accurate PCB stencils via Silhouette Cameo


Wow, I haven’t posted anything here in way too long.  This might help.

Right now I’m working on getting accurate PCB stencils out of my Silhouette Cameo desktop cutter.  People have been doing this for a while now, but they’ve been plagued by various complications with the data workflow and physical cutter settings.  The process involved transforming your artwork through several formats, importing into a proprietary application (you can buy SVG support for $50…), and hoping you have everything set right.

My initial work on the process was to change the data flow, allowing me to work from Gerbers rather than exporting a different format from Eagle.  It was a cumbersome process that involved using gerbv to write SVG files, then loading those into Inkscape in order to save them out as “R14” DXF, then switching over to my Windows VM to import the file into Silhouette Studio, dragging it to the right spot, and then cutting.  This at least allowed me the possibility of cutting an entire panel as generated by gerbmerge, but took waaay too long.

Now, I’m well on my way to having a radically superior process in place.  First off, I found that there are several projects capable of talking to the Graphtec engine that the Cameo is based on.  These gave me the foundation to write my own simple code to control the cutter, although there are still a lot of “magic commands” that need to be figured out the hard way (I’ll have to set up USB sniffing and exercise Studio a fair bit to figure them out, if I care).  That got me a Python script that could cut whatever I wanted programmatically.

The next step was to try to clean up the physical results.  Ever since I started cutting stencils, I’ve been plagued with strange shapes instead of nice rectilinear openings.  Well, this turns out to be a function of the design of the Cameo blade.  Inside the cutter is a vertical shaft with a very small triangular knife blade that spins freely.  The shaft is centered on the nominal X,Y of the cutter head, but the tip of the blade is not.  It drags roughly 0.5mm behind the center of the shaft.

This means that when you make a hard corner with the cutter head, the blade will not make the same corner.  As the center of the head (black) makes the sharp corner, the knife (red) lags behind and eventually ends up where the head wants it.  The result is a shape that roughly approximates the original, but only mostly.  Even worse, because the blade never actually reaches the start point, it leaves a little un-cut corner.

Cameo drag cutter     Not square!

My initial thought was to basically over-shoot the corner, then come back to the target line.  A simple method uses a single angled return path, but really it should be an arc of the same radius as the blade lag.

Initial compensation attempt

That mostly worked, but then I ran into another problem with blade-dragging: the blade drops with whatever rotation it had for its previous cut.

Drop misalign

In this case you can see that the blade was aligned from a previous upward cut when it dropped, then slowly made its way towards the right cut it was supposed to make.  The solution I came up with was to do a “pre-cut” off to the side before any lines of a given angle.  This leaves the blade pre-set at the right angle to make sure the beginning of the cut is straight.

The final trick was to cut each line in half, and actually force the blade to make two cuts starting from the center towards each end.  This avoids any question of exactly where the blade drops at the corners, and leaves and overshoot at every corner.  At least for rectilinear openings (all I care about just for now), this results in a perfect opening:

The Fifth Millimeter

That’s a millimeter ruler up against an 0.2mm square hole.  Not only is it nearly perfect (to the limit of my ability to actually see the thing!), but it lifted clear of the adhesive cutting mat exactly as you see: the fragment was 100% detached from the sheet.

At this point I’ve got a minimal codebase that reads actual stencil data, albeit the long way around: gerber -> gerbv -> Postscript -> pstoedit -> .pic(troff) -> myscript.  I’m hoping to fix that in the long run by reading Gerbers directly.

I have all sorts of transform functions in place to allow me to implement these techniques then send the resulting cut paths to the hardware.  I’m still tweaking a few things (I don’t have the cut-from-center trick written yet, but I do have a “repeat last line” to make 5 cuts around a rectangle) and getting period odd results (my last test left every single fragment still attached well enough to peel off with the main sheet…), but it won’t be long before I can take a Gerber file straight from Eagle CAM and generate a nearly perfect stencil on my $300 cutter!