Posts Tagged ‘artwork’

h1

Crazy-accurate PCB stencils via Silhouette Cameo

2013/04/05

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!

h1

Panelizing PCB & Assembly: prepping the boards

2011/05/26

In my quest to get a group of PCBs fab’d and assembled as inexpensively as possible, the first step of course is getting the artwork for the individual PCBs ready.  Once the schematic is finalized and the basic layout is done, additional steps need to be taken in order to make then panel-friendly, and actually get the artwork together into one chunk.

Read the rest of this entry ?

h1

The joys of PCB & Assembly panelization

2011/05/24

I’m working on the latest round of prototyping for the product I’m working on.  This time there are a number of factors that are forcing me to change from my previous development methodology.  First and foremost, there’s a lot more pressure to get it done fast rather than cheap, so a major factor is the reduction of unknowns like low assembly yield that were making the process rather slow.  Second, I’ve shuffled things around in the design in ways that both call for tighter design rules than the DorkbotPDX group order provides, and make assembly even trickier to do by hand.

The project itself consists of a whole series of different PCBs.  The main group of 3 boards stack on top of each other, while the controller has a site to stack on the top board from the first stack, then itself live on a larger board that I haven’t finalized yet.  Because of the small quantities of boards and the diversity of the design, panelizing them turns out to save quite a bit of money.  I’m currently running 2 of the main stack plus the first board of the controller.  If I ordered PCBs separately, it’d run about $1500.  Panelized, they came in under $600.  Assembly for each of the jobs separately would run around $3300 based on mostly-accurate numbers, but the panel drops that to around $2200.  Overall I’m saving around $2000 by panelizing.

The downside is that it’s a rather complicated process.  I’ve worked for the last week trying to get everything in order so EpecTec and Screaming Circuits don’t end up with major problems because of what I send them…  However, once it’s figured out the first time, I can do subsequent panelized runs with a lot less effort.  And thanks to the wonders of Open Source, I’m hoping others out there will be able to do the same because of the scripts I’m writing.

I’m going to see if I can make enough time in the next few days to note down most of the issues I’ve run into, and hopefully save others some trouble in doing so.  First up will be setting up the PCBs and panelizing them.

h1

Mental excercise: tiny acceleration logger

2010/06/08

When watching shows like Mythbusters, Prototype This, and Smash Lab, you regularly see them using accelerometers in order to test the shock characteristics of a given event.  The problem is that these loggers are invariably big (roughly 6″ cube by volume) and fraught with problems such as “triggered, hurry up before we run out of log space!”.  Given the current crop of really tiny accelerometer chips (such as the Freescale MMA4755 mentioned on dorkbotpdx, for $2 quantity 1), microcontrollers, flash memory and batteries, it seems almost criminal that they aren’t using something radically smaller and smarter.

So just for fun, I decided to toss some parts together and see if they would actually fit on an incredibly tiny package.  The design is not complete, as it is missing any charging capability and more importantly a Bluetooth uplink module, but it’s a good start:

I call it “rev -1″ because of the missing features, but it’s a good start.  However, it’s a whopping 1.125″ x 0.5”, sized to match a tiny LiPoly cell from Sparkfun.  It’s got an ATmega48 core, MMA4755 accelerometer capable of up to +-8G, and an 8Mbit dataflash capable of roughly 15 minutes of continuous recording at the maximum 250Hz sampling rate.  A tact switch is used to turn it on etc, and an LED just under that for status.

The next steps would be to add the Bluetooth module (e.g. this one also from Sparkfun), some kind of charging circuit, and possibly a USB-A connector to make it into a “USB key” for both data extraction and recharging.  I’d drop the huge battery connector in favor of soldering it on, and put the Bluetooth (and maybe some other parts) on the opposite side of the board, but I still think it’d fit.  I’d want to find a solid power-management chip designed to handle USB input and LiPoly charging that’s also insanely tiny, but these days the manufacturers are so keyed in on making multifunction chips in stupidly-small packages that it’s probably going to be harder to find one big enough to do on the group-order design rules.

Total retail price on this module would likely be in the $75-100 apiece, but the combination of size and potential feature set should be hard to beat.

h1

“Rev 1” Xmega adapter art

2010/05/15

I’d mentioned a post or so back that I found assembly costs to suffer from the use of QFN chips, and that I was going to redesign the Xmega adapters to use PQFP instead.  Here they are:

I call these the “rev1” boards because the first round of QFN’s were the real functional test.  These boards have identical schematics, just different parts implementing it.  The pins are now surface-mount on the bottom of the board, which doesn’t even come close to offsetting the costs of the QFN when it comes to assembly (quoted at Screaming Circuits).  I’ve also switched the A3 boards back to 0603 caps, since while I can do 0402’s by hand (the first rev0 A3 board is assembled and working as well!), I don’t think they’re going to scale well for production.  They spend half their time stuck to the tools instead of the board…

I’m going to turn a set of 3 of each of these with the next group order to make sure I can do the bottom-side headers, then these will be the “final product” boards until something else needs to change…

h1

DMX-512 module in development

2010/05/04

In response to a question on answers.hackaday (this one) about an open-source DMX-512 platform, I figured I’d post something about what I’ve got under development as part of a larger project.  The long-term goal is to develop a wall-mounted control panel (e.g. in the standard light-switch box) for lighting scenes.  A number of these would be installed at key places in our church sanctuary, allowing the DMX-controlled lights to be operated without having to trudge upstairs and find the light board.

The module in question would be the brains of such a beast, having a microcontroller and the necessary DMX interfacing.  An ATXmega would form the core, given that it’s the most versatile MCU I’ve used so far.  DMX interfacing uses a pair of MAX13430’s, which are dual-voltage transceivers allowing me to run the DMX ports at the proper 5V yet interface cleanly to the ATXmega running at 3.3V.  A soft-USB port is present for configuration, though that depends on either porting or rewriting the AVR-USB stack to run at 32MHz, or just running the whole module at say 20MHz (the max current speed for AVR-USB).

The module takes the physical form of a 40-pin 600mil DIP, for which sockets are easily available anywhere and everywhere.  All the pins not used by the DMX interfaces are brought out on pins for use by whatever you want to drop this thing into.  DMX and power connections are made via screw terminals, which could be routed to standard 5-pin DMX connectors on whatever chassis you have.

This module is still under development, as in I was modifying and cleaning up the PCB just a few minutes ago.  The DIP power pins are yet to be routed, and there’s more cleanup to be done.  However, I’m waiting to turn the actual boards until I get my baseline Xmega adapters populated and can start developing some of the software so I know I’m not smoking something.  I expect to turn these boards in 2-3mo, and shortly make them available for purchase.

h1

Xmega adapter boards for breadboarding

2010/04/16

I’ve got a number of projects coming up that would be radically simplified by a) using ATXmega parts, and b) breadboarding a prototype.  The problem is that Xmega’s don’t come in anything but surface-mount packages.  The obvious solution is to construct an adapter board.  A straight pin conversion would be a waste of effort, so adding programming headers, clocks, and decoupling capacitors is a necessity.

I posted to the DorkbotPDX list to see if anybody is interested in ordering some of these alongside my own order in the next group PCB buy (April 26th), and got one response almost immediately.  As a result I’m going to tweak the boards up and make sure they’re ready to go, and post them up here for comments.

The first board here is the ATxmega*A4 unit, which is a 40-pin 600-mil DIP.  PDI header on the right, crystal on the left, decoupling and AVCC filter caps scattered around.  Port pins are labeled as are + and -.  PDI pins are accessible on the main header as well as the programming header.  Discretes are all 0603 for ease of assembly, though the chip itself is a QFN (unfortunately).

The second board is a straight extrapolation of the first, designed for the larger A3 chips.  It’s a 60-pin 600-mil DIP with the same basic feature set.

I’ll be tweaking these over the next few days, and hopefully producing a batch of them in the next couple weeks.