Using Stl2gcode to Automatically Generate G-Code From STL Files

Potential of Vertical Milling Machines with Straight End Mills

It is often possible to arrive at sophisticated designs using only a vertical milling machine with straight end mills. Several light duty bench top vertical milling machines have reached the market in the past few years but some CAM software fails to deliver their full potential. Many mouse clicks are often required to get from STL files or other CAD output to g-code. This process is error prone, tedious and often results in the following two unfortunate outcomes: designs with few complexities in the z-dimension and a reluctance to change designs once g-code is created and validated. This instructable describes an approach used to arrive at g-code from STL files automatically, which often addresses these issues and enables users to achieve the full potential of their vertical milling machines.

Raspberry Pi Mount Example

A Raspberry Pi (RPI) mount is used to describe this approach. It is created from 1" rigid foam and secures a raspberry pi, battery and power supply in a $10 case. The mount was chosen because it has non-trivial features in z, undercut features that require cutting from the top and bottom and features that cannot be reached at all. All of these features make it a good candidate for showing the capabilities of this approach. The mount design was created in Design Spark Mechanical by intersecting a model of the foam with models of the other components including the case.

Step 1: Planning Approach

Gripping and Freeing

The first step to generating tool paths is to understand how you will grip the stock and free the part. The RPI mount includes flipping the stock in order to cut from the top and bottom. The stock is gripped using lateral wedges and the part is kept secured in the stock with tabs that are manually cut away after machining is finished. Tab geometry is given in the form of an additional STL file referred to as scaffolding. As the STL file defines regions that make up the part and should therefore not be removed by the cutting tool, the scaffolding object defines additional regions that should not be removed.

Precision, Performance and Tool Selection

Precision requirements and trade-offs with performance should also be understood and decided upon. Tool path creation-time and run-time typically increase with precision so the minimum acceptable precision is often used. This decision is applied directly by stl2gcode algorithms and also indirectly as a function of tool selection. Smaller diameter tools can reach finer detailed geometry but require more passes to hog out open regions. Stl2gcode never removes stock that makes up the part; when a tool diameter is too large to allow the cutting tool to reach a feature, that feature will not be realized. This is most commonly observed at inside corners, which result in fillets. In this way, stl2gcode does the best it can with the selected tool. The RPI mount was created using a max error of a few thousandths of an inch. Furthermore, a 3/8" end mill was selected to cut the mount bottom and a 1/16" end mill was selected to cut the mount top, which has finer features.

Step 2: Creating Scaffolding Objects

What are Scaffolding Objects?

Scaffolding objects define regions that should not be removed by the end mill in addition to those regions defined by the part itself. Just as scaffolding at a construction site facilitates working through large scale fabrication realities, scaffolding objects in stl2gcode facilitate working through the realities associated with machining operations. Scaffolding objects are typically designed alongside the parts to be machined and exported as binary stl files using the same process used to export the parts themselves.

Scaffolding Objects and the RPI Mount

The mount is secured in the stock with tabs until the machining is finished. In addition to cutting the battery feature, the bottom tool path cuts the perimeter of the mount except for the tabs. If the tabs were not present, the part would free before the stock could be flipped and gripped to cut the top features. The scaffolding object used to create the bottom tool path is the dark blue object in the above image [left]. As shown, there are six tabs connected by a perimeter feature. The space between the perimeter feature and the mount is sufficient for the 3/8" end mill to pass. The bright green object in the above image [right] is the scaffolding object used to create the top tool path. As shown, there is not sufficient space between the scaffolding and the part at any point for even a 1/16" end mill to pass. This keeps the top tool path from including perimeter components since these would be redundant with those in the bottom tool path.

Step 3: Capturing Approach in Stl2gcode Configuration File

stl2gcode_user_id           Ed Slatt [[e-mail]]
stl2gcode_registration_code 1234-1234-1234

stl_filename                ../../raspberry pi mount 1.stl
stl_90_deg_rotations_z      1 // better angle for camera on left

speed_cut_ipm             100
speed_jog_ipm             150

max_error_in                0.002

<session>
  tool_diameter_in          0.063
  max_cut_depth_in          0.125
  min_height_in             0.200
  scaffolding_stl_filename  ../../rpi mount 1 scaffolding top.stl
  current_working_directory audit_1/top
  gcode_filename            rpi_mount_top.gc
</session>

<session>
  tool_diameter_in          0.375
  max_cut_depth_in          0.250
  min_height_in            -0.020
  scaffolding_stl_filename  ../../rpi mount 1 scaffolding bottom.stl
  stl_90_deg_rotations_x    2
  current_working_directory audit 1/bottom
  gcode_filename            rpi_mount_bottom.gc
</session>

Organization

The plans arrived at in "Step 1: Planning Approach" are applied via stl2gcode configuration files such as the one shown above. These files are broken into sections, which are controlled by the directives in the section and are responsible for a g-code file. Directives that are given outside of the sections apply to all of the sections. Directives are key-value pairs where the keys are separated from the values with either a space or colon. File system paths can be specified with either forward or backward slashes and may include double quotes.

RPI Mount stl2gcode Configuration File

The mount is created with two g-code files: rpi_mount_top.gc and rpi_mount_bottom.gc. The stl_90_deg_rotations_x 2 directive in the bottom section directs stl2gcode to rotate the part about the x axis 180 degrees before generating the tool path. The stl_90_deg_rotations_z 1 directive is applied to both sections. Similarly, both sections use raspberry pi mount 1.stl, a cut speed of 100 inches per minute, jog speed of 150 inches per minute, a max error of 2 thousandths of an inch and both use Ed Slatt's license.

As shown, the bottom g-code uses a 3/8" end mill. The max_cut_depth_in 0.250 directive ensures that the end mill will never be pushed laterally into stock that is more than ¼" deep. Similarly, the 1/16" end mill will never cut stock that is more than 1/8" thick due to the max_cut_depth_in directive in the top section.

Finally, the min_height_in directive tells the algorithm when to stop. This directive is set to -0.02" for the bottom tool path because the bottom tool path is used to cut the perimeter of the part. The extra 20 thousands of an inch ensures that the cut reaches the entire way through the stock. The default min height value of 0" is used for the top section, which specifies the bottom of the stock and top of the mill deck.

Step 4: Running Stl2gcode

Zero User Interaction Enables Painless Design Evolution

Stl2gcode does not require any interaction with the user while it runs. All user input has already been captured; stl2gcode generates tool paths automatically as a function of only the configuration file and the referenced stl files. The implications of this approach are significant. Once the configuration file is complete, changes to the part can be incorporated into the g-code without any user interaction.

Performance and Output

The stl2gcode application is associated with stl2gcode files. It is run by double clicking on these files in windows explorer. It runs in a command prompt as shown in the above image and indicates which cut planes have been processed. The time stl2gcode takes ranges from a few seconds to several hours depending on the part and precision requirement. The tool path generation time for the RPI mount is 25 minutes on an Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz with 8GB RAM.

Step 5: Validating G-Code

Validation Output

stl2gcode produces a directory named validation that contains an html file and image files. An image file is produced for each cut plane and shows a slice of the part in green and the corresponding tool path in black. The html file references these images so they can be viewed in sequence in a browser. This view typically gives the user a sense of whether their intent was properly captured in the stl2gcode configuration file and realized by the stl2gcode application.

Validating G-Code is the User's Responsibility

It is ultimately the user's responsibility to ensure the safety of any tool paths they run. While the stl2gcode validation facilities provide a starting point for validation, they are insufficient to declare the tool paths safe and other means must be applied as well.

Step 6: For More Information

Contact [e-mail]

I've been developing and using variants of this algorithm for several years and only recently decided to see if there is external interest. Please email me if you would like to purchase or beta-test stl2gcode or if you have other questions/suggestions. I hope there is interest so that I can justify further development and additional features!