Carbide Create V Carve Optimization Requests

I have been using Carbide Creates V Carve in aluminum and brass lately. I am running it with a no name 90 degree carbide chamfer engraver. It has been working quite well at 22000 RPM, 10 IPM, .003 DOC. I have been noticing some less than optimal path generation behaviors that are adding a lot of time to machining, that I think can be addressed quite easily.

Attached is the lion head I have been using for testing:
lion test face.c2d (449.3 KB)

With the default parameters and a Z safe height of 0.5", Carbide Motion says it will take 3 hrs and 25 minutes. Yikes.

Based on the behavior of the machine, it seems that Carbide Create generates a path, runs the machine down this path, raises up to z safe height, returns back to the beginning of the path, plunges back into the material, and runs along the path in the same direction again.

Based on this, I have a few recommendations:

Rapid Z Raise
Below is a snippet of g code taken from the file generated with default parameters:

Z12.700 //THIS SHOULD BE G0Z12.700

As you can see, three lines from the end, the Z raise is done at G1 speed. I dont believe there is any reason this cant be done at G0 speed. Especially when engraving in metal where feed speeds are significantly slower, this one line adds a lot of time.

I used a text editor to swap Z12.700 for G0Z12.700. This took my engrave time from 3 hr 25 minutes, to 2 hr 11 min, a 36% improvement according to Carbide Motion

Lower Z Safe Height

As mentioned before, the code generated runs the machine down a path, returns all the way back to the work Z safe height, returns back to the beginning of the path, and runs the same path again. This would only be necessary if there are clamps or fixtures the machine needs to traverse to get from the end of the carve path, back to the beginning of the carve path. I am fairly sure 99.999% of the time, this would not be the case, unless a v carve path is somehow wrapping its way around an obstacle.

Giving users the option of a lowered z safe height for a v carve operation would save a lot of time. By lowering my z safe to 0.125", I can reduce my carving time to 1 hour and 4 minutes. If I also do a rapid z raise as mentioned previously, I now have a carving time of 45 minutes.

It would also help reduce the amount of stress felt when the machine pecks a 1 mm, .003 deep notch in the metal, slowly raises up 0.5 inches, twitches back to the beginning of the 1 mm path, slowly goes back down 0.5 inches, and pecks again at the material.

Zig Zag Option

I tried ESTLCAMs carving toolpaths. It uses a different approach. ESTLCAM runs the machine down the path, plunges DOC into the material, and then runs the path in reverse. This helps significantly reduce machining time. However, I find it doesn’t work that well for metal. The cutter is essentially runs the same path in climb, then conventional, and results in a W shaped grove as the flex in the machine cause the cutter to move from one extreme to the other. It does work quite well in wood and plastic, and should be an option for those materials.

Loop Recognition
Here is another test file I was using. In this, the machine is programmed to v carve a loop:
loop test.c2d (9.5 KB)

The key to this file is that each path ends where the next one begins. Carbide create generates the following code. You will see that at the end of each path, the machine raises back to the z safe height (at G1 speed, I might add), does absolutely nothing, and then goes back into the material for the next pass. I have to imagine this is something that can be adjusted fairly easily.

X56.966Y39.397Z-0.138 //Carving routine
Z0.500 //Raises back to z safe at end of path, at G1 speed
G0 //Does absolutely nothing
G1Z-0.146F203.2 //Feeds back in the same spot it left
X56.983Y37.488Z-0.155F254.0 //Continues back along the path
X56.921Y36.548Z-0.165 //Machinist hugs himself, rocking back and forth slowly.

There is not much time savings in the case of this file, since it is such a short file, but I can imagine in a more complex file, this could eat up a lot of time.

Finishing Pass

Finishing passes help a lot in engraving. It helps clear out any stubborn chips stuck at the bottom of the groove. Adding the option of a finishing pass at reduced depth, or even a spring pass run in the opposite direction, would help a lot in creating cleaner, crisper lines in metal. I will try to take some photos with a macro lens when I get a chance, but I swear one wall of my v carve groove always looks better than the other, and I just wish I could try to run the groove in reverse as a spring pass to help clean up that other wall. Its not critical however, as a Dremel with a wire wheel can help remove 90% of this.


I am wondering if anyone from Carbide 3D (or the rest of the community for that matter) can weigh in regarding some of these path choices. Its very likely I am missing something obvious (which is proven by the fact I am too scared to run any of the g code I have modified). Alternatively, is there any other CAM software I should give a try to address these issues? I cant afford much on a CAM package right now, but if it would reduce a 3 hour files to a 45 minute operation, I would definitely give it a try.


I had noticed similar behavior. The cutter does something then wastes a bunch of time traveling up, doing nothing, and traveling back down for the next cut.

I think in addition to what was already mentioned, it could be helpful if the software had a feature where the user could somehow map in where their hold downs are. If I’m using clamps to hold the part down, maybe I need a safe 0.5" for those clamps, but the clamps are not anywhere near the cutter 99% of the time anyways, so the safe Z could be lowered to almost the top of the work surface.

You can use md8n’s GCodeClean utility to convert retract from G1 to G0 automatically, I used it on CC gcode just today. It doesn’t do any travel optimizations, unfortunately.

I v carved a simulated chip carving today, a rosette surrounded by an border of football shaped patterns. Part of it CC would cut one football, then rapid over the next and cut it towards the previous one, then leapfrog over the next and repeat although it only did about half the border that way. A simple which end is closer could have optimized that, the design was a circular cut with varying depths and could have been done with no rapids or retracts.

Edit: GCodeClean, not gcodetools. Oldtimers.

This topic was automatically closed after 30 days. New replies are no longer allowed.