Circles in Carbide Create seem to be inefficient and inaccurate

Hello everyone,

I’ve been using Carbide Create (the free version) for a short time, and very quickly I noticed that the gcode files it’s producing are enormous, for the (lack of) complexity in the toolpaths.

For example, I drew a circle of radius 0.78125 inches, then made a toolpath for a pocket 0.090 inches deep, cutting 0.040 inch per pass (so two full-depth passes and one shallow finishing pass.) The tool diameter is 1/4 inch and stepover is 0.125 inch (50%.)

The resulting gcode is 973 lines long, which seems INSANE for such a simple toolpath. Examining it reveals that it’s not circles or even arcs at all (i.e. G2 or G3 is not used once) but rather a zillion tiny little linear cuts to approximate a circle. Srsly?


Also the precision seems to be weirdly off. Notice the start point in the above snippet is X = 3.9779 and Y=1.9780 inches. In CC the circle I drew was centered on X = 4.000 and Y = 2.000 (typed values, not just clicked or snap-to-grid.)

This error doesn’t seem to be big enough to be explained by tool radius or something like that, but it’s also way too big to be explained by unit-conversion rounding (e.g. inches to mm and back again?)

Any thoughts on what’s going on here? I’m curious whether Carbide Create Pro has the same (apparent) lack of precision and/or arc usage in its gcode.

Is this a post-processor issue? I’ve got GRBL selected but maybe I should be using something else? (If so, what?)

BTW, I’m posting this here instead of asking the Carbide 3D people because I’m also looking for recommendations for simple-but-accurate 2D design software (also inexpensive as possible.) Some of the other solutions (e.g. VCarve, Fusion360) seem far more complex than I need. I like the simplicity of CC but not if it’s going to risk making the 1F controller freak out by processing 133,000 lines of code just to cut 49 small pockets (and position them inaccurately.)


The software is not capable of doing true arcs so any curve is converted to small lines to make this arc. The amount of code does not determine the speed or time its going to take to execute the cut so this is not a good way to tell if it is going to take a long time or not. Even though there are 100s of lines of code if it only takes a fraction of a sec to execute each one in will go through the code really fast. This is a really good thread that talks more about this in depth.

1 Like

“The software is not capable of doing true arcs…” which software, Carbide Create? Because Gcode certainly is.

Also I didn’t say anything about the length of time it takes to cut. I mentioned the insanely long amounts of code generated because the 1F controller has to parse and execute hundreds of lines a second, and the cutting movement is not particularly smooth when code like this is run.

The OF controller software. It doesn’t matter how you generate your gcode the controller isn’t capable of arcs so its never going to be perfectly smooth.

Got it, thanks! And thanks for the link too.

I’m still interested in finding CAD software that will generate gcode with G2/G3 … I comprehend that the 1F controller software will convert the arcs to a series of linear segments anyway, but it seems like it might be a good idea to let the 1F do that on its own? (which also gives some control over it, i.e. the max-deviation setting)

VCarve and Fusion 360 both generate G2/G3 arcs, this is what I have been using. I’m actually looking to do the opposite test now, using software to convert arcs to linear segments in the hope that I may have more control over the conversion as opposed to the 1F controller. I’ll need to give Carbide Create a spin to see how that compares.

I’m getting acceptable results now in plastics. Thinking of ordering a controller-less 1F next and pair it with a controller that is capable of performing arcs for cutting aluminum.


Did you ever find a good combination of deviation and tolerance? Ive been working in aluminum and its been frustrating. this is 32 microsteps .0002 deviation

That’s about as good as I have been able to get it too. At 0.0001 Deviation I started to encounter loss of steps/torque. I’m quite happy with 0.0005 Deviation for plastics, and the default for wood, but for aluminum you may want to eventually look at upgrading the controller to something that does Arcs. I haven’t played with it yet, but I have Marlin based controller I used for a DIY CNC a few years ago… one of these days I may try it, but the interface is horrible :frowning:

1 Like

Is the issue Carbide Create or the controller? If it’s the controller, changing CAM software won’t achieve the needed outcome.


It’s a limitation of the Buildbotics controller.

Just to revisit this…I don’t think what’s being said here is entirely true. If you’re using Carbide Create with OneFinity and exporting the grbl-based g-code, I believe it’s Carbide Create that’s actually converting arcs to linear segments. At least, in files that I’ve created, I see no existence of G2/G3 anywhere.

A lathe would be a better option for the above part, Ha Ha

1 Like

That may be the case, and if so, the Buildbotics controller should not have to re-convert them to linear. But if they come over as true arcs, Buildbotics will indeed convert them to linear segments.

1 Like

Agreed. The difference here is that with the Buildbotics, you at least can control the max deviation but when done via CC, I guess you just get what it gives.

1 Like