Tool Path Software

In my current manual milling process I begin with 2D CAD design. The main purpose is to come up with accurate coordinates for moving the axes around. After completing the drawing of the part, I strategically place circles representing the cutting bit I will use around the drawing. I then add dimension lines referencing the cutter circles. All dimensions come from a 0, 0 "home" position. So each cutter circle essentially has X, Y coordinates. After squaring up my stock, I set the spindle to the "home" position and zero the DRO. Then it's just a matter of removing material until I reach the cutter positions on the drawing.

A way more sophisticated way of doing things is with advanced CAD/CAM software where you draw your part in 3D and then generate tools paths (G Code) that tell the mill how to remove the material. But this is not an "Easy Button". You don't just throw a piece of metal in the vice and press "go". Milling most anything is a series of discreet operations such as facing, pocketing, and drilling. Each operation may require remounting of the stock, changing tool bits, etc.

I'm not willing to invest in an advanced software stack that costs as much as the hardware. I think I can write a decent, flexible program for describing how to mill a particular piece (not simply "what it looks like"). While a fancy user interface would be nice, I'd like to have a "scripting language" that allows me to write "parameterized functions" representing the milling operations to be performed. The first step of making a part is usually squaring up rough stock. A "facing operation" might take parameters for the width and depth of the face, the size of the cutting bit, how much material to take off with each pass and how many passes to make. I would just take my cad drawing with dimensions on it and plug them into the facing operation.

A facing operation would be composed of many straight line movements to get the job done. This series of lines could be built up with a series of commands to move the spindle in 3D space. When I was a kid, personal computers had just come out. When the graphics got sophisticated enough, a program called "turtle graphics" came out. Basically you have a "turtle" with a "pen" it can draw with. You tell the turtle to move forward a certain distance, turn right a certain number of degrees, raise and lower the pen, etc. The core of my scripting language would essentially be "3D turtle graphics".  Here's a code sample:

m.down(0.75f); 
m.forward(0.25f); 
m.right(60.0f); 
m.forward(1.75f); 
m.down(1f); 
m.right(90); 
m.forward(2.5f); 
m.plunge(0.5f, 5f); 
float turn = (float) (360 / 16.0); 
for (int steps = 0; steps < 16; steps++) { 
   m.right(turn); 
   m.forward(0.5f); 
} 
m.up(0.25f); 
m.setHeading(30); 
m.forward(2.25f); 
m.right(45); 
m.forward(0.5f);

This describes a rather arbitrary path for testing purposes. (It's a bit hard to tell what the plunge command does. Here it says "descend 0.5 units while moving 5 units". So the circle becomes a helical path.) Here's a screen shot of the 3D preview / simulator:

The Cone in the upper right is a representation of the spindle or cutting bit. It is animated along the path and the path and the whole scene can be rotated and zoomed for examination. (The line colors and points are for analysis of the path generation algorithm.)

The tool path is fully modeled on the host computer and then sent to the Arduino (see "Major Components").

A G Code parser could pull in paths generated by other software components and mix the paths with other operations to create a complete job program that can even prompt the operator to change tool bits.