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 “Gcode”, 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 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:
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:
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,
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://sourceforge.net/projects/cncsimulator/ (Windows-based simulator)