In Which Jarrett Builds

Jumping off from my last post about getting images into Altium Designer, it was surprisingly difficult to do in CircuitMaker.

After three days of attempting a few different approaches, I have one that I’m quite happy with. Conveniently, this is pretty good at getting images into EAGLE as well. At least as good as the built-in ULP.

If you’re just here for the solution, scroll way down and read the paragraph about the brd-builder.py script.

This is the story of how I arrived at a robust method of importing bitmaps into arbitrary layers in EAGLE cad or Altium CircuitMaker.

The first approach I started with, after drawing some pretty pretty pictures, was to attempt to load them into Altium Designer in the same fashion as described earlier.

These images were way larger and more complicated than the previous experiment, however, and the Delphiscript chewed on it for three or four hours before silently failing. Even if it had worked properly, I’m not particularly happy about being dependent on the expensive professional tool to work with the hobbyist one. So I delved deeper.

Here are the options and approaches I took:

• Importing DXF files directly in Circuitmaker is possible, but largely unsatisfying. The CM importer splits up the original paths into discrete arc and line segments. This is great if you want to draw outlines, but that’s it. Lack of fill options or the ability to merge these objects make it inadequate for my purposes.

• Using CircuitMaker “region” objects. Going into the property menus of one of these objects reveals a list of points and coordinates, and import/export options. I wrote a converter to massage SVG files into the proper CSV format. This is svg-parse.py. It’ll take an SVG file, and convert each individual object into a CircuitMaker-compatible CSV file. From there, you can create a region in CircuitMaker, open its properties, and import one of the CSV files.

This is pretty good, and results in native objects that are speedy to move around. There are some caveats, however:

• You must do this for each object, making it labour-intensive for complex canvases
• Curves are not supported, so it is first necessary to follow the “Add Nodes” and “Flatten Beziers” steps in Inkscape, described in the import-dxf EAGLE plugin.

• Attempting to hijack the clipboard was the next experiment, read-clipboard.py. Region objects can be copy-and-pasted between documents, so I wanted to take a look at what that data contained, and maybe silently insert my own. This never really worked properly, and I abandoned it quite quickly. It was a hacky approach, anyway.

• A quick search on reverse-engineering Altium’s file format brought up this primer (by way of Hack-A-Day). Although very abbreviated (the goal of that guide is to teach a methodology, not to completely reverse the file format), the page was more than enough information for me to write a Python script that opens and dumps the contents of the CircuitMaker-formatted OLE document. So in ole-extract.py, I got as far as grabbing a library document and extracting and splitting header/data information into a folder. Realised at this point that the libraries I was using would have a difficult time repacking the streams into one OLE document. Not to say it isn’t possible – it totally is – it’s just rabbit-hole I don’t particularly want to go down at this time. This is still interesting in that it should be a working Altium and CircuitMaker file reverse engineering effort in Python, which hasn’t been done before.

• Importing EAGLE files works really well. They’re XML-based, and very well documented. First, I imported an EAGLE file that contained an image, which looked and worked great in CircuitMaker. I poked around with how that image was created in EAGLE, and it looks like it was just made with the built-in “Import Bitmap” ULP. How it works is that it scans along each horizontal line, creating a one-pixel-high rectangle in the filled area. Repeat for the entire image.

Okay cool. That sounds really simple. Problems with that:

• It doesn’t alleviate my allergy to using 3rd-party software as an intermediate step
• If my image is over the 3 inch (or whatever) size limits of EAGLE’s free version, I’m hooped
• The ULP script seems to choke on images randomly

So what I did instead, is take a dummy EAGLE file, and stripped it to the bare-necessities required to load. This particular brand of XML is the fourth file format I’ve had to parse in this whole process, but it wasn’t too hard. With this dummy file, my final and greatest script, brd-builder.py, grabs a bitmap file, converts and then injects it directly into the EAGLE file, giving you a proper EAGLE file, with no size limitations and no EAGLE install required. CircuitMaker can then easily import this via the File->Import menu.

Input images need to be a 1-bit BMP file.  In Photoshop this is done by converting to grayscale in Image->Mode->Greyscale and then converting to bitmap in Image->Mode->Bitmap. In GIMP, this is done through the menu in Image->Mode->Indexed. Then save as BMP.

Before running this script, open it up and then modify the desired variables – inFile, outFile, layer, and scale. They should be fairly self-explanatory. Scale in my application was found by guessing until it fit my board, due to the resolution I drew my image at.

This was a fun detour. Fun is good, because spending time to make tools for your tools can be very frustrating. The last tool in particular works great for me, but If I were to develop a robust system designed for anyone to use, there are a few more avenues I would attempt to pursue first:

• In the Hack-A-Day link posted above, one of the comments mention being able to just open OLE. They turned out to be using 7zip, which supports that format natively. Coincidentally, I found a portable 7zip executable in the CircuitMaker folder. It’s possible that they’re using this for encoding their documents. It would be fun to write an executable shim with the same filename that invisibly passes arguments to the original 7zip program, but logs it to file as well. Will also look into better methods for doing this – Static analysis using X64_DBG or IDA is an obvious candidate here.

• Failing that, writing and testing code to modify the OLE document stream and then repack it into a format that CircuitMaker can read

• The native importers in the CircuitMaker all have IWZ extensions, and from the binary data seem to be x86/64 executables. Google says these might be installer files. Along the same lines as the executable shim/wrapper above, figuring out how these work and writing my own would be fun.

I’ve been a really big fan of PCBModE for a long time. Designing beautiful PCBs is a seriously difficult skill, and a serious abuse of the PCB board houses. Saar Drimer of Boldport has done a great job, and anyone reading this should definitely check out his stuff.

Where it falls down, though, is doing complicated and electrically correct circuits – No DRC/ERC rules, and not even a schematic view. I use Altium for my main PCB package, but it’s pretty tricky in it to get images into the PCB. It is possible, if a little convoluted, so here is my method.

Part of the problem is that I’m using Altium Designer 10 – Newer versions are better with this, it seems.

This process uses the CreateRegionsFromBitmap script. On my machine, it’s located in:

C:\Users\Public\Documents\Altium\AD 10\Examples\Scripts\Delphiscript Scripts\PCB\CreateRegionsFromBitmap

It’s also broken and required a couple fixes.

When I opened up PCBLogoCreator.PRJSCR in Altium and compiled/ran it, I got an error, missing semicolon at this line:

GrayWidth := Round((1 - sqrt(GrayProportion)) * PixelToCoordScale / 2);

Instead of trying to fix it (I don’t got time for that), it was replaced with:

GrayWidth :=0;

Second error was a missing function. This was fixed by copying LayerComboBox.pas from the PCB Logo Creator script into the working CreateRegionsFromBitmap script directory and project tree.

Then hit Run, and a dialog box pops up!

My workflow here was to identify what different shades I could get on the PCB, and the best ones for my image.

Here is a list of portions that contain wildly different shades:

• Bare FR4
• Copper
• Soldermask
• Soldermask with copper underneath
• Silkscreen

Predictably, that means that images with 5 or fewer colours (including backgrounds and outlines!) work best. For a non-commercial practice piece, Dr Seuss was the clear choice.

First step is to pull the desired image into Inkscape and separate all the component colours.

The way Inkscape handles colours masking each other – like the yellow layer being the “background” and relying on it being blocked by the colours on higher layers – doesn’t really mesh with the way they show up on PCBs. After some fudging around (as quickly as possible), this is what I came up with.

And here’s how the PCB turned out in OSHPark Purple.

The thing is super small, so you can see how the soldermask pools up against the raised copper and causes weird bubbles.

I didn’t spend a huge amount of time trying to fit the best colour scheme to the image. But what I’ve done since then is scanned a few PCBs that I have kicking around, and created this handy palette for a various soldermasks!

The best method for using these is probably to ignore the PCB aspect entirely at first, and draw a pretty picture in your illustration application of choice, using just those colours. Translating that to PCB is the secondary concern, and much easier. Something to note is that the “copper” colour of the DirtyPCBs palettes is HASL tin grey on top, and the OSHPark scheme is ENIG gold on top. Both of those are shiny.

Another technique worth trying is crosshatching. That might work out really well, in the same way that it works for laser cutting.

I’ve written recently about machining my own custom pen because, much like lamps, they are a “form over function” project where the end result can be gorgeous as well as useful. Aesthetically pleasing to everyone, not just techie people. And they don’t take up a lot of space!

Initially, my design for the first pen was sketched out in notebooks, and then modelled in CAD, then back to the notebooks when I was in the shop. This helped me get a general feel for what I wanted, but many style, material, and mechanical considerations had to be redesigned on the fly as I found techniques that didn’t work, and others that did.

A lot of the dimensions of final product came down to how they felt in my hands, as I was building. That’s fine for a one-off, but I’d kinda like to parameterize basic measurements so that I have some guidelines on what works for future pens.

So here’s a pretty generic pen, modeled in Solidworks.

Here are a few pens I had within arm’s reach.

Starting at the top, I named these 1-4, and made some basic measurements based on the generic model:

Now I’ve got a good baseline for what makes a comfortable writing utensil, a recommendation for critical dimensions to stay within, and some language (or at least letters) to be able to intelligently discuss the anatomy of a pen.

This is a pretty rare combo: using a premium PCB package with the budget board house.

Kinda funny.

Generally these small run PCB houses provide DRU and CAM files for EAGLE design rule checking and Gerber outputs, respectively. Because I’m using Altium, I had to make it up as I went along.

It gets much easier when you understand what Gerber files are. While we’re all used to standard, unified output formats that contain all of the data we need, Gerbers are very much still a holdover from manufacturing in the 80s.

When you export these, a whole bunch of files get generated. This is intimidating, but don’t panic! They all have different extensions like GBO, GTL, etc. These are all the same type of file.

As I’ve said, while you’re used to unique file extensions being different formats, these are a holdover from 80s manufacturing and the PCB industry still hasn’t caught up. That means that by changing file extensions, you can play around with different layers doing different things.

So here’s how you generate the appropriate Gerbers. I used a mostly the default rules for this, I’m not pushing the limits. Maybe next time I’ll generate the proper rule sets.

Read and understand these directions before you start. They require some forethought.

Start out with your finished PCB.

Do the thing.

The resolution options matter here. There’s no way Dirty PCBs can handle the higher res, so turn it down a notch.

In the next tab, this is where you’ll have to do some thinking. Every project is slightly different. So for this one, I want the top overlay (silkscreen), top solder (gaps in solder mask for your pads), and top layer (copper). Same thing for bottom.

You also need a board outline. Older versions of Altium don’t have a dedicated “outline” layer, although I believe newer ones do.

So what I did was change the board outlines to Mechanical 1, and now I’m exporting that.

A couple more notes:

If I wanted to create a solder paste stencil, I would also export the Paste layers.

If you want through-hole slots, you will need an additional layer. This includes slots that allow you to panelize. Export them on another mechanical layer, and I’ll talk about it a little later. I’ve done this before, DirtyPCBs does a great job of this.

All of the other tabs in this dialog are kept at default values. Don’t mirror the bottom layers as shown. I did that and it was Wrong.

I lied a little bit above. Of the exported files, there is one that is not like the others. The drill file (.TXT in this case) requires it’s own export.

Do the resolution thing again, and everything else is default.

Okay! Now we’ve got all the files we need, let’s make sure they’re in the order they need. Here’s the key on the DirtyPCBs website.

As you can see, it’s super similar to what we have. The top 6 are exactly what we exported, and the drill TXT, too. The outline is the only thing that’s not quite right.

We exported it this time as mechanical layer 1. Easy fix, just rename the GM1 file to GKO. If you’re doing internal slots or self panelizing, you’ll also have exported another mechanical layer. Say, GM2 or GM15 or anything you like. Rename this to GML and include it with the others.

And there you go! Zip up all of these files, and they should turn out alright. GD1 is the Gerber drill file that this board house doesn’t use, just ignore it.

An important step: Check your files.

CircuitPeople is an excellent and simple online Gerber viewer. Look at all your layers and make sure nothing is terrible.

And you’re done! Send it off and enjoy your boards.

If something screws up in the order, I’d like to hear about it, but I take no credit. These steps have always worked for me, but this particular company probably won’t tell you if anything is wrong with the files. They’ll just manufacture it and send it on.

Side note: A summary of something I’ve been using for many hardware hacks in the past while.

A lot of commercial machines use gears for transferring forces. Well, duh. It’s often necessary to change gearing around, though, and it’s nigh-impossible to find commercial solutions with appropriate ratios, tooth profiles, and mounting options. So usually I laser cut my own.

The easiest way to generate a gear that meshes with an unknown is to use Inkscape’s Gear extension. It needs circular pitch, which you find by:

1. Measuring the gear’s outer diameter, OD
2. Counting the teeth, N
3. Getting diametral pitch: (N+ 2) / OD
4. Calculating circular pitch: Pi / Diametral pitch

For the pressure angle, it’s a little more complicated. You need the base pitch:

1. Use your digital calipers to measure right down in the gaps of two teeth
2. Measure three teeth
3. Subtract the two-teeth measure from the three-teeth one to get a single tooth
4. Do the same for 5 and 4 teeth
5. Take an average result of those to get an approximate base pitch measurement
6. Base Pitch * Diametral Pitch = Pi * Cos(Pressure Angle)

Of course, that looks difficult and error-prone but generally you’ll only run into pressure angles of 14.5 or 20 degrees, so only do rough measurements pick the closest one.

For mounting holes, you’ll need to know how far apart to space them. Pitch diameter is what you need: Teeth / Diametral pitch

This is a quick summary of everything you need to know. There are a lot of dimensions associated with spur gears, and it’s good to know what’s what, but these are the only ones you actually need to make your own. All of these formulas are unitless, so pick and choose, as long as you match the same unit in Inkscape. I uses inches for these, but I tend to switch back and forth to metric with impunity for everything else.