Nomad: Great results milling PCBs from Eagle

Milling PCBs was one of my main reasons for getting a Nomad. I finally found some time to learn how to use Eagle and the related tools and mill my first boards. I am very happy with the results and once again very impressed by the Nomad, especially its precision.

This post provides some results and lessons learned from my first two test projects.


As preparation I milled down the wasteboard so it was perfectly flat. It was pretty close out of the box, but not perfect. The milling pass fixed that up.

First Project: Single sided TQFP-44 breakout board

The first project was a single-sided simple breakout board/breadboard adapter for TQFP-44 package ICs, which have a pitch of 0.8mm (30mil).

I set up the very simple circuit in Eagle v7.2 with the SparkFun design rules. For the first attempt I let Eagle’s autorouter route the traces and then produced the gcode files with pcb-gcode and ran them on the machine through Carbide Motion. The very first board came out great right away and looked like this:

The milling is perfect but if you look closely you can see some design issues:

  • There isn’t enough clearance between some traces and pads and they touch
  • The whole thing is too big and would cover up too much of the valuable breadboard area
  • The autorouted trace pattern isn’t very pretty

Here are some close-ups of faulty areas along with the design errors that caused them:

Eagle’s design rule checker is very handy for finding these issues before milling. It reliably flagged all of these clearance issues.

All of that needed to be cleaned up and I also had to save some space, so for the next pass I moved the two rows of header strip pads together as close as possible while still leaving enough space for the IC in between. After I did that, the autorouter wasn’t able to fully route the circuit anymore, so I routed everything by hand, which also let me get a fully symmetrical trace pattern to satisfy my OCD tendencies. I routed it with 10 mil traces with 15 mil clearance between them and then ran the job on the Nomad again.

Again the milling result was great and this time the traces/pads looked electrically functional:

pcb-gcode has an option to output the vector text on the milling layer as well so I ran that program next on the same board:

This text is tiny! I didn’t realize that it would be so tiny when I picked the size in Eagle, and I was surprised that the machine was able to mill this legibly at all. Very impressive.

The third program generated by pcb-gcode was to drill the holes, which I ran with a 0.9mm drill bit:

The fourth and final program file was the milling layer for the board outline. I wanted to mill rounded corners:

Carbide Motion was not having it:

So I switched to regular 90 degree corners and regenerated the program. I ran it with a 1.5mm 4-flute bit:

That didn’t come out very clean so I’ll need to play some more with speed/feed and the type of tool. Also, the depth for both the hole drilling and the milling passes were set too shallow in pcb-gcode so the holes and the milling cut didn’t go all the way through.

After a bit of manual sanding and cleanup for all of these issues, it looked pretty decent:

I soldered on an IC and added the headers to make it breadboard-friendly:

After seeing that a 0.8mm pitch worked really well I wanted to know if I could go any smaller. I did a quick test with an LQFP-64 package IC, which has a pitch of 0.5mm (20mil), and the result looks good too:

These are designed as 10 mil traces with 5 mil spacing:

At this spacing the isolation starts to eat into the traces a bit so they are probably not 10 mil wide. I didn’t finish this one because I don’t need it and I don’t have PCB blanks of the right size, but I did check the connectivity and isolation of all traces shown in the photo, and they are all fully functional. I feel this is about as small as I could go.

Second Project: Double-sided Bus Pirate board

The second test was a double-sided board whose design files I downloaded. It’s the SparkFun variant of the Bus Pirate, an “open source hacker multi-tool that talks to electronic stuff”.

I originally downloaded its design files in order to make one very minor change and send the result off to DirtyPCBs. The change was to replace the Mini-USB with a Micro-USB connector. I also shortened the board by a few millimeters so it could fit into the cheapest DirtyPCB size/pricing tier (5cm x 5cm).

Since I had these design files already lying around, I used them for the double-sided test. The board is quite small and the traces and vias are delicate, not really suitable for hand-soldering, but I tried to mill it anyway. Here’s the top layer in progress:

And the result, which blew my mind:

This is rather small at 5cm x 3cm. The drill holes are a bit too big for the size of the vias, they should be 0.5mm but the smallest drill bit I had at hand was 0.7mm so I used that.

Next came the challenge of flipping the board over and aligning it so that the vias on the front and back layers would meet. I added two extra holes on the left side and had the machine drill them through the board and a bit into the wasteboard (this next photo shows the board moved out of the way a bit):

I then flipped the board over, aligned it with the holes, and taped it down again:

As you’ll see next, this way of aligning it with two holes and drill bits isn’t good enough, I’ll have to use at least three holes next time.

Because the two holes were drilled on the zero axis, I didn’t have to change the machine’s zero position for milling the bottom layer program. pcb-gcode outputs the bottom layer with negative x coordinates, so everything should line up nicely.

Because I wasn’t quite sure what exactly pcb-gcode was going to do with regards to that x coordinate flipping before I saw it in action the first time, I looked around for a way to verify the gcode files visually first. pcb-gcode has a preview option, but it requires Java and I didn’t want to bother with setting that up on my Mac so I looked elsewhere. I found the awesome open souce app OpenSCAM, and it was perfect for the job (if you end up finding it useful as well, consider making a donation to the project). I can load the top and bottom layer gcode files and see exactly how the tool is going to move for each in relation to the zero point:

So with the board fixed in the properly aligned position and some confidence that the gcode generated by pcb-gcode was correct, I ran the bottom layer program, and it came out like this:

You can see that the alignment of the via pads and the via holes drilled on the top layer is not great but acceptable on the right side of the board, closer to the alignment holes, but the further left you look, the more they are out of alignment. As noted above, I’ll have to use three or more holes next time.

Nonetheless, I proceeded to run the milling program to cut the board to its final size, sand and clean up the board, and solder some of the vias. All connections I tested ended up fully functional!

Halfway through the board I noticed that something was wrong, there were some unwanted connections:

It turned out that these locations had a clearance of just 8 mil, and the tool diameter in pcb-gcode was set to 8 mil, and as a result it didn’t generate a toolpath for those cuts at all. This was actually visible in the OpenSCAM visualization:

When I configured Eagle’s design rules for a minimum clearance of 9 mil and ran the checker, it flagged exactly these locations, so there’s at least a reliable way to find these. Make sure to check for a clearance value larger than the tool diameter:


Here are the pcb-gcode settings I used. I started out with the ones from the PCB milling thread on this forum and then fine tuned a bit.


These particular cutters were recommended by @robgrz from Carbide3D and they do indeed produce awesome results. I never had to deburr anything, the cuts came out clean right away.


If you want to try this on your Nomad or a different machine:


Amazing project, really nice results! thanks for sharing. :clap: :clap: :clap:

Each day, as you said I’m more happy with the Nomad, even when it is frustrating when not getting good results with something.

1 Like

Thanks for posting that. We haven’t done any PCB milling since our Kickstarter prep and we never did anything that nice. T-Tech tools are great, I’m glad to see them in use here.


Glad you like it Rob. I got these cutters based on your recommendation, thanks for that!

Do you think anything can be done in Carbide Motion about the gcode error for the rounded corners noted above?

Do you have the option to use IJ instead of R for arcs? That should work.

If not, I’ll get it added to Carbide Motion for you


Fantastic work and writeup!


wow. me ideas for doing this myself

I looked into this again and the pcb-gcode software does not seem to have an option to emit IJK instead of R.

I made myself a Python script that rewrites the pcb-gcode output accordingly, bit it’s an extra step, so I think adding native support for R in Carbide Motion would still be a good enhancement.

Great write-up, thanks for it, and for being so thorough. PCBs are on my to-try list with the Nomad once I manage to learn how to get my current wooden artwork attempts functional.

Awesome writeup and results! I am intending to do some PCB work too and have purchased the materials, but have not had the time to learn all the software. This writeup will definitely help!

I presume scoring would be simple too.

Thanks for the write-up. This is useful information.

Grbl doesn’t support the R option for arcs. The thought at the time was that it was new-ish and there wasn’t any CAM programs that generated them that I knew of. I’ll add R arc support to the Grbl to-do list. It might be a while, but it’ll get on there.

1 Like

That’s great to hear, thanks!

Dang. I totally bungled up the arcs. Grbl DOES support R radius-mode arcs. It always has. I mixed it up with the new P option, which creates full circles. That said, the R radius-mode arcs are very susceptible to numerical error, just from the way the definition was written. Not sure why Carbide Motion would block them, but, if they do intentionally, it’s probably because of the problems associated with them.

1 Like

@chamnit we haven’t implemented the r-arc verification yet, but it’s coming soon™ Rob says. The main cases for “r” are from eagle & HSMworks, but in HSMworks you can still set it to use i/j notation instead, so I am wondering if that’s possible for Eagle also…

Great post.
Can you please post the g-code so i can test it?

Sure, I just added a link to a zip file with the gcode and eagle files for the breakout board to the end of the article.

I just wondered how the R arc support was coming, as I just ran into this, for a converter board much simpler than the above.

I have a friend that designed a board with “fritzing” and I thought perhaps it might be possible to take one if its output types (PDF, PostScript, SVG, PNG, JPG) and import into MeshCAM as if an engraving project. Seem reasonable? Would using one of the T-Tech V mills be a good choice, and setting the engraving depth and tool diameter (as if an end mill) such that the minimum between-trace-gap is doable?


Hi, I was wondering if you could explain how you were generating the gcode to cut out the pcb? I was only able to generate drill and pcb etch files that contained data.