Review of some Open Source Software for CNC Machine Control

1. OpenSource CNC- From CAD to FAB
By
Charles Warner

2. OpenSource CNC- From CAD to FAB
I first encountered “Rapid Prototyping” or “3D Printing” back in the late 1980's, when I contracted
with a Canadian company that offered the service based on a process that used a laser to cure specific
regions of a soup of liquid plastic. Very impressive, and so was the price- several thousand dollars to
produce a prototype that, in production, should have cost less than a dollar. Most of the costs were the
result of converting the 2D mechanical drawings (about the only option back in those days, unless you
happened to work for a major aerospace or automotive company) to machine code for controlling the
laser.
Things have come a long way in the past 20 years or so. Commercial Rapid Prototyping systems have
come down in price to a few ten's to hundreds of thousand dollars, with hobby-level systems appearing
in the price range of a couple thousand dollars (or less, if you are willing to dig through your scrap pile
and build from scratch). CAD has progressed significantly, with 3D modeling becoming very common
(and affordable). More traditional machining equipment (lathes and mills, for example) rely more and
more on automatic numerical control- CNC, in industry parlance. I myself do not consider this a
totally good thing- for me, when I get frustrated or stressed, there is nothing more relaxing than
stepping out to the shop and turning some little trinket out on my lathe (akin to the way some people
use meditation or recreational drugs). Thus, I am not all that concerned with production costs of my
little trinkets. Although I spend a good deal of time analyzing speeds and feeds to determine optimum,
I generally operate at 10% of the optimum, just to prolong the experience...However, one of my dream
projects is to build my own Rapid Prototyping machine, and for this, numerical control is crucial.
The process of going from the CAD design to finished product consists of:
Giving credit where credit is due: the above is a variation on a diagram available from the pyCAM
wiki. I have adapted it the way I have my system set up, and changed the focus from “PyCAM” to “G-
code”, because it is the generation of the machine code language from the original graphical design that
is critical (this is what drove the cost of the rapid prototyping process back in the 1980's).
G-code is a colloquial name for the RS-274 machine tool programming language. It is not the only
language used for machine control, nor is it standard across the industry. The RS-274 standard was

3. developed by the National Institute of Standards and Technology (NIST) in the 1980's. The simplest
g-code program is nothing more than an ASCII text file containing a list of movement and coordinate
commands. The RS-274 standard does include higher-order features such as arithmetic functions,
variables, conditions, loops, and sub-routines. There are other approaches, such as ClassicLadder, that
may be of interest to others. Our personal interest is primarily in the “*.ngc” dialog of this language,
because that is what EMC2 uses, and RepRap (one of our candidate rapid prototyping systems) already
uses it (as described here).
On either side of the G-Code center in the above chart, we see multiple paths for getting from our
design to final product. On the right is another program that originated at NIST, “EMC2”, which is an
Open Source “software system for computer control of machines such as milling machines, lathes,
plasma cutters, cutting machines, robots,... etc.” and is distributed by LinuxCNC.org on a live CD
compiled with Ubuntu (they also offer a “demo” version that can be run on an existing Linux
installation, without full functionality- this demo version is what we are working with for this study).
According to the EMC2 web site, “The simulator mode is useful for playing with gcode onscreen, but
not for measuring jitter or driving actual machinery.” We haven't yet built our machine, so we don't
need full capabilities yet. The EMC2 program will ultimately read our g-code and send instructions to
our CNC machine. EMC2 happens to use its own variant (officially titled rs274ngc) based upon the
NIST standard.
To the left of the G-Code island, we see a number of paths to get from design to g-code. We identify
two possible interpreters, which are are the two we have explored, but not necessarily the most
appropriate for any given application. Note that the two primary paths are based on either 2D *.dxf
original CAD files, or 3D *.stl files. Our initial experiments suggest that the 2D path would be most
appropriate for engraving and such, although it should be possible to create a 3D object with multiple
views. Since our first experiment involved a 3D milling exercise, however, we opted to generate our
*.stl file in Salome (a personal preference, since we are more familiar with Salome than some of our
other packages). Interestingly, there exists a python script add-on for Blender that generates g-code
directly, which greatly simplifies the procedure, but we find Blender, because it is such a powerful and
universal 3D modeler, is a bit cumbersome for simple tasks. So here is the object we want to mill:

4. Which was generated in Salome, exported to a *.stl file, then imaged in Blender (just because we can!).
Next, we import the *.stl into pyCAM:
After playing around a bit with various selections for tooling, processes, and such (all actually very
well-documented by the pyCAM developers), we finally come up with a successful g-code defining our
cut (we could have added additional tool paths to include rough cuts and finish cuts were we really
going to make this part). We check the tool path by clicking on the “simulate” button. Here's a close-
up showing that the tool paths actually follow the contours we are looking for:

5. Next, to test the EMC2 simulator, we save the g-code we just generated, and load it into the EMC2
simulator. Whoops! EMC2 complains that our model exceeds the limits of the machine in the x
direction. It just so happens that these limits are set in a *.ini file, plain ASCII text which we can edit
quite easily. This illustrates the versatility of the software. Although the package comes with various
*.ini files for a variety of machines, it is relatively easy to modify for any particular piece of
equipment. Here is our “mill” cutting one of the grooves:
And here is the “finished” profile:
Of course, this exercise does not represent the best way to produce this particular object (for instance,

6. we would drill the hole, rather than mill it, and we would use roughing and finishing cuts, not just the
semi-finish cut we used here). But, this illustrates the basic procedure.
The next step is to explore the python script in Blender. We imported the *.stl file into Blender (which
may not have been the proper way to do it- we lost our dimensional reference!):
But we do see the tool path being generated.
There are still lots of experiments to do, and features to explore, but, hopefully, we have demonstrated
some of the capabilities for CAD programming that are available within the OpenSource community.
For those who would like to explore this subject further, here are some links to get you started:
http://www.linuxcnc.org/
http://sourceforge.net/projects/cncsimulator/ (Windows-based simulator)
http://www.cnczone.com/
http://www.cncinformation.com/
http://christian-kohloeffel.homepage.t-online.de/dxf2gocde.html
http://pycam.wiki.sourceforge.net/
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?GcodeGenerator