PCB-Gcode

[This text in German]

With the schematic and layout editor EAGLE (Easy to Use Graphical Layout Editor), two-sided boards up to the size of half an euroboard - corresponding to 8 x 10 cm - can be created in the freeware version.

The finished board can be ordered from a professional PCB service, but you can also produce the board yourself.

The earlier approach of etching the board in a chemical process never really convinced me, the disposal of the resulting residues in the form of a toxic broth via the pollutant mobile acts as a fun brake.

Since I own a CNC-milling machine and the appropriate software in the form of OpenCNCPilot, I have abandoned the photochemical approach and mill my boards.

The ULP (User Language Program) PCB-Gcode, created by John T. Johnson in 2003, provides initial support in converting the board created in EAGLE into a form of data that can be interpreted by my milling machine. PCB-Gcode converts the polygons of EAGLE into enclosing paths, which are then run by the milling machine - this is called isolation milling. Here is the link to the current version of the ULP. The ULP also works with more recent versions of EAGLE, I use EAGLE V7.7.

As tool for the creation of the milling paths for the PCB production I usually use so-called V-mills or engraving gravers, I use those with 0.2 mm tip width and a cutting edge angle of 45 or 30 degrees. The simplest and very well suited gravers have a D-shaped cross section and thus one cutting edge. In the ULP you can choose whether engraving should be done with the feed direction ("Always climb") or against the feed direction. In my experience the edges that are cut against the feed are the cleanest, edges that are cut with the feed do not look very nice, usually look a bit frayed.

Unfortunately, the ULP in its original form can create all traces either with or without the option "Always climb", so you have to decide, and it is best to choose "Normal", i.e. not "Always climb", then at least the contours of the traces are clean.

Since I was dissatisfied with this behaviour of the ULP, I analysed the code and with really manageable effort I created the possibility to mill the first contour around the resulting signal trace in the preferred direction, i.e. against the feed, but all further milling paths in the opposite direction, so that now the contours of the remaining copper areas are also cut against the feed. Thus the resulting edges of the copper areas look as good as the signal traces.

The ULP change must be implemented in the "PCB-Gcode.ulp" file starting at line 1288, directly after

// set direction of cut around contour
if (((g_side == TOP) && !CLIMB_MILLING) ||
   ((g_side == BOTTOM)  &&  CLIMB_MILLING)) m_fwd = true; else m_fwd = false;

Here I have inserted the following code:

////////// Harald added 13 Feb 2020
// Provided our tool is rotating clockwise when viewed from the top.
// If we are in the first turn around a trace, we mill it normal (not climbing) since we mill the _inner_ side of the trench,
//  so we move the tool on the right side of the trace counter clock wise around the track.
// If we are in the second or beyond turn, switch to the opposite mode (climbing) since now we mill the _outer_ side of the trench,
//  which results again in "normal" (not climbing) milling for the given side of the trench.
// If the user chose "climbing" in the settings, both cases result in "climbing" milling

if (m_pass_num == 0) m_fwd ; else m_fwd = !m_fwd;
//////////

First a lot of comments, real code is only the last line. Here the first pass (m_pass_num == 0) will keep the direction as set in the PCB-Gcode setup, in all other cases, i.e., if and when additional passes are made to increase the trench between signal trace and remaining copper area, the milling direction will be reversed.

---

A further improvement over the original version was suggested by Alexander Arkusha in the end of 2017.

This improvement addresses the problem that in the original version the marks for the holes, called Spot Drills, were drilled with the same depth as the correct holes when the drill file generation is activated, too. Correctly, the spot drills should only mark the surface to prevent the drills from running off when they are placed.

The correction to the code proposed by Alexander is a bit more extensive, the following changes have to be made (I am inserting here the original text by Alexander, which is also quoted exactly the same by John Johnson):

    step 1. ADD FOLLOWING TEXT AT THE END OF "source\pcb-file-utils.h"

    void output_drill_spot_hole(real drill_x, real drill_y, real depth)
    {
        if (SIMPLE_DRILL_CODE) {
            rxy(drill_x, drill_y);
            fzr(depth, FEED_RATE_DRILL_Z);
            rz(DEFAULT_Z_UP);
        }
        else {
            out(frrrr(DRILL_SPOT_HOLE, drill_x, drill_y, depth, FEED_RATE_DRILL_Z));
            update_cur_xy(drill_x, drill_y);
            }
    }
 

   step 2. ADD FOLLOWING TEXT FROM LINE #102 IN "settings\gcode-defaults.h"

    string DRILL_SPOT_HOLE  = RAPID + MOVE_XY + EOL
                            + FEED_MOVE_Z_WITH_RATE + EOL
                            + RAPID + "Z" + real_to_string(DEFAULT_Z_UP) + EOL;
 

    step 3. REPLACE FOLLOWING TEXT BETWEEN LINES ##467-473 IN "PCB-Gcode.ulp"

    if (m_first_spot_drill) {
        output_drill_first_hole(drill_x, drill_y, SPOT_DRILL_DEPTH);
        m_first_spot_drill = NO;
    }
    else {
        output_drill_hole(drill_x, drill_y, SPOT_DRILL_DEPTH);
        }

    ...WITH FOLLOWING TEXT

        output_drill_spot_hole(drill_x, drill_y, SPOT_DRILL_DEPTH);

    step 4. (optional): REMOVE LINE #455 IN "PCB-Gcode.ulp"
        SINCE VARIABLE  m_first_spot_drill BECAME USELESS.

---

There are further improvements. For example, there is a patch by Timo Birnschein which splits the milling of the finished PCB into several passes so that the milling cutter does not have to mill the complete thickness of the PCB in one pass. The patch is described on Hackaday.io, the complete code can be found here.

Unfortunately the possibility to generate so called bindings is still missing. They would hold the finished PCB in the remaining PCB material to prevent the milling cutter from tilting. If the raw board is fixed with double-sided adhesive tape, however, it is not necessary to generate those bindings.

---

Here the link to the official homepage of PCB-Gcode.

---

Tip
Unfortunately, PCB-Gcode only generates the outline of a board in the milling layer with a router path exactly on the board outline. If you were to do this with the CNC router, the board would be too small by half the router diameter on each side.

With simple geometries of the PCB, e.g. rectangular, this correction can be taken into account manually and it is then even possible to provide so-called connections. For more complicated outlines, however, this process is time-consuming. If the board also has incisions and/or must adhere precisely to dimensions, you quickly reach the limits of what is still feasible with reasonable effort.

Fortunately, there is the GCode-Ripper tool, which can convert the GCode generated by PCB-Gcode back into DXF format, so that Estlcam, for example, can be used to generate the router path with router radius correction and connections. This is what happened, for example, with the replacement power supply unit for our Paradigma heating installation.

Hint
In the current version V3.7.0, John has introduced some of the improvements mentioned into his ULP. Unfortunately, he made a small faux pas, which is why the contours of a circuit board with rounded corners are not generated correctly.

The design in EAGLE (here for the e-scooter brake light):

The result on the milling machine:

Instead of rounded corners, small ears are created.

John has fixed this, unfortunately in the somewhat older version 3.6.6 of the ULP. The current 3.7.0 has not yet been revised in this respect (as of 07/2024).

---

Speaking of versions of pcb-gcode...

The version 3.7 I am using has apparently never been released as an official version. At least as of today (07/2024) there is only V3.6.6 under Master on Github.

V3.7 can be found in the endmill-holes branch. But beware, the rounded corners do not work here, see above.

The advantage of V3.7 over V3.6.6 is the ability to drill holes in the board with a smaller diameter cutter using a helical drill. The hole diameter is slowly lowered into the board material in circular paths, eliminating the need to use the appropriate milling cutter for each different hole diameter.

For this to work, the drill rack file, i.e. the default.drl file in the settings folder within the pcb-gcode directory, must contain information on which cutter is to be used for which minimum and maximum diameters.

More detailed information on how to set up the table can be found in the manual pcbgcode.pdf, which can be found in the docs folder.

Update

I sat down and transferred the corrections from V3.6.6 to my active V3.7.0. WinMerge is usually a great help, but this time I used the comparison option on Github.

In short, my “private” version of pcb_gcode.ulp now generates rounded corners correctly and additionally handles helical drills. Finally, the all-round carefree package from pcb_gcode that I have always wanted for my purposes :)

Since I don't know the voodoo around forks on Github (well enough), I offer the V3.7.0 patched by me for download here for those interested.

I must note, however, that John's Github version V3.6.6 is 21 changes ahead over the V3.7.0 I patched, so it is not impossible, but rather very likely, that V3.6.6 contains corrections for bugs that I simply haven't noticed yet. The changelog on Github is a bit confusing on this matter, probably because John only works on pcb_gcode very sporadically and may have lost the thread from time to time ;)
Or I simply don't see through John's comments.

Nota bene:
Version V3.7.0 reports itself in the configuration dialog as version 3.7.2-alpha.

---

Translated with www.DeepL.com/Translator (free version - online)