Carbide Create Pro- What do you want to see?

I can duplicate the problem. We’ll look into it.


Looking into your file, it’s got a weird quirk that makes it fail- there’s self-intersecting geometry that we fix, then simplify the paths to remove extra data, which causes more self-intersecting geometry.

We just uploaded 425 to with a fix.

I’d appreciate everyone trying out vcarve in this version to see if it works OK.

( Belt-and-suspenders had to be removed so we only have a belt now and that makes me nervous)

EDIT- Pro tip if you’re ever in a crunch and are having this kind of vcarve problem that you must solve ASAP: zoom into the corners and look for weird overlaps and self intersections that you can remove from the vector.


So far so good, and I dunno if its something you did Rob or what but I can now actually enter the simulation while performing a recording, for the past month its been timing out of recording every time I clicked simulation in CC.

Just accidentally did it during a recording and was like oh $h!T I’m going to have to start over now… and it kept recording. I haven’t done any windows updates and this program was the only one having issues recording.

1 Like


I know this is Carbide Motion but when CM looses connection to the controller, I wish that CM would display what line it stopped at and that we could restart from that point (or any line) like when we push pause even if we have to do a homing cycle. In fact it should say something like stopped at line XXX and when you reconnect, CM should say last job interrupted at line XXX, do you want to restart from that point?


It’s a big change to allow a program to be resumed on a particular line but it is something we’ve got on the radar and we would like to add it. (Not sure when that would happen though)

I don’t think we did anything that could affect that since 420 but if it’s better, we’ll just be happy that it’s working well.


maybe it’s more viable to restart on a specific toolpath if there’s a marker in the gcode for toolpaths…

1 Like


While doing a quick project for Uncles Birthday today, noticed that the pocket tool path stopped a bit short.

University of Michigan (235.9 KB)

ps I’m going to check and see how well CC can handle that Large Star Wars Aztec with V carve now.

1 Like

I suspect that the pocket is very very close to the tool diameter and that slot closes in on itself as the outline is offset.

Basically, this is a problem/quirk of some third-party code we use that’s so complicated that we dare not even gaze upon it because the code works 99.999% of the time.

Make that slot/pocket .001" wider and I’d expect that it’ll work fine.

1 Like

That was my original thought but the code was generated for 99% of the file just fine at same thickness so was curious. This must be that 1% variance? I’ll check with smaller tool dia. was using a #201
EDIT: .001 fixed it… LOL wow talk about being PICKY!!!

1 Like

I suspect it’s down much below 1%. I’d be willing to bet that a smaller tool works just fine for the calculation.


I offset that vector by .001 and worked just fine with #201
It worked out just fine without offset changing to 1/8" endmill.
So wow that stuff is Picky lol…

Vector copied, offset .001" to the outside, #201 cuts full pocket now no issues…

Was just funny how it didnt cut that little part… Cut out with a utility knife and chisel just fine.

1 Like

Just uploaded 426 to

  • (NEW) Load SVG as native curve paths, not polylines

There will probably be one more build (427) to make this SVG change more efficient. Other than that, we’re interested in regressions from the current stable version, 413. If you have any cases where this build is a step back from 413, please let us know.


on 427, importing a large/somewhat complicated design from an earlier 4 series CC with a pretty complicated vcarve… the first time I loaded it, all the toolpaths kept saying “calculating”… even the most simple cutout of a “rounded corners” square shape.

I hit save, loaded it up and all but one of the toolpaths are now pretty much done, but the last toolpath is calculating already for an hour or so. Did the Vcarve math get a lot slower? Or is the thing that updates the display when the calculation is done not always doing that? Just noticing that the task manager no longer shows CC using CPU time…
(mind you this design was never fast in vcarve calculations even in the older versions)

(the design is arguably on the extreme end for what CC can cope with, but older versions coped and I’ve made the design in plywood and it looks great and was well received)

CC 427 - small bug.

I loaded an existing design and deleted the cutout tabs and added new ones. The 2CD file was not flagged with an asterix as having been changed.


I like what I’m seeing so far. How about text on a path?


Text on a path is a frequent request which hopefully will work its way up to being done — no idea on timeframe.

Until then, you can use F-Engrave or use Inkscape to set the text, convert it to paths, then use Path | Object to Path on a copy of the file to get geometry which you an import into Carbide Create

Can you share the file you’re using?

Just uploaded 428 to

  • (NEW) Progress notification for vcarving
  • (NEW) Multiple vcarve regions are now calculated in parallel
  • (FIX) Time estimate for disabled toolpaths show correctly (Arjan)
  • (FIX) More consistent progress updates for toolpath calculations

@fenrus - Your file now calculates in a few seconds.


Thanks, Will. Yes, I’ve used Inkscape. Have experienced stretching issues so have to perfect the object to path size.

Again, great work so far. Seriously considering the subscription.

1 Like

Update the keyboard shortcut PDF: