I have created what I think is an acceptable method to create g-code from the devCad Pro CAM program that now includes BitSetter functionality. devCad is a 2D cad program which is designed to be a general purpose CAD program, but is really tailored for the creation of parts for Radio Control airplanes. The CAM wizard allows you to select two different endmils when creating the cut files. One for cutting the parts out and one for engraving part names. Since I now have a BitSetter, I wanted to be able to use it when switching endmills using the g-code created from devCad.
Here’s what I have done so far:
Requested and received the g-code configuration guide from devCad.
Created a new g-code configuration file in devCad for my Shapeoko with “Toolchange” (BitSetter) support based on the devCad generic g-code configuration file I had been using.
Tested the new output “in the air” to assure nothing catastrophic is going on and that the proper BitSetter actions are occurring.
So far so good, everything seems to work correctly to me. But there are a few differences I see in the generated g-code between Carbide Create and devCad that I would like some input on.
a) Carbide Create does not use G2 or G3 commands in its generated g-code, but I have the devCad output configured to use those commands. This does work using Carbide Motion and I have been using them for a while. I thought I should double check if they are OK to use.
b) devCad forces a return to the defined zero position at the start and end of each tool’s path. It has not caused any problems, but it is a difference I have noticed.
I’ve attached a DXF file that I started from. (A simple wing rib), the C2D file with the toolpaths added, and the generated g-code from Carbide Create. I’ve also attached a zip file containing the g-code generated from devCad, the g-code configuration file for devCad and the instructions for the configuration file from devCad.
Maybe I should just ask Carbide3D support these questions… but I thought I would ask here first to see if there is anything I am simply overlooking.
Arcs: there should be no problem with Carbide Motion, as far as I know it does not interfere with G2/G3 commands sent to GRBL (that does the heavy lifting), and for example the Fusion360 post-processor for the Shapeoko uses them and works fine with CM.
There’s always the matter of G2/G3 errors thrown by GRBL when…exotic conditions happen that create rounding problems, but that’s a different story.
The return to the defined zero position should be fine too, but looking at the last lines in the example G-code file you posted:
I’m just wondering if 4mm is a clearance value you set in devCad ? (and therefore that you set it to 4mm because you knew there would be no clearance issue for the cutter moving back to 0,0 ?). If so, I don’t see how this could hurt.
If think CC generates a return to “center/back of the machine” as a convenience to clear the way for the user to access the piece, nothing more.
I’m just wondering if 4mm is a clearance value you set in devCad ? (and therefore that you set it to 4mm because you knew there would be no clearance issue for the cutter moving back to 0,0 ?). If so, I don’t see how this could hurt.
Thanks for the quick reply Julien, and yes there is a 4mm clearance value in the devCad settings. (Configurable)
So good… Time for some real cutting to see what happens in reality…