Is Carbide Create having problems

Hello all,

I am so frustrated. I spent countless ours the last couple days designing my first cuts. I saved two that were finished in a gcode file but the others that I was working on I saved in carbide create and they are now gone. They never disappeared before but my carbide create file is now empty and they are no where to be found. URG I am so crazy frustrated about this. Never had this problem with other programs and the words I want to use due to my frustrations I cannot. Any help would be appreciated.

Jennifer T

Yes Carbide Create has limitations and some bugs but it is an easy program to get you going. I’m still new at this and I upgraded to VCarve Pro. One thing that you have to be aware of and has to do with the two types of files. One saves the whole project while the other saves the GCode only. If you save the GCode and not the file, you will not be able to re-open the project. If you save only the file, you will not be able to produce your project on the Shapeoko. This is inherent to all the CAD/CAM software. Unfortunately, one of the issue with Carbide Create is that contrary to most program, it will let you shut the program without saving if you have made changes to the project. The Save and Save As menu bar items are orange to indicate that changes have not been saved but it does not give you a message saying the file has been change do you want to save it before quitting or closing the project.

1 Like

If you have a G-Code file, but no .c2d file, you can use G-Code Ripper from Scorchworks to recover the toolpaths as geometry:


Unfortunately, it does not appear to save an SVG, just a DXF and CSV that you can’t open in CC.

I’ve been looking for a GCode to SVG converter and could not find one. I would think that compared to a DXF, it would be relatively easy to program such a thing.

The DXFs should open — if you find one which doesn’t, let us know at and we’ll look into it.

I believe there’s a G-Code module as part of pstoedit:

Hmm… So, if I were writing a G-code import extension for Inkscape, the questions I’d have are:

  1. Would I just convert all G1 moves to paths, dropping G0 rapid movements?
  2. What do I do about Z? (For basic 2.5D files, one could hypothetically attempt to make layers/groups out of each depth. For fully 3D toolpaths, on the other hand, the only thing I can think of is ignoring Z entirely.)
  3. Whatever the choice regarding Z, would filtering overlapping paths be necessary for the results to be useful?
  4. How useful would the results be given the SVG paths would be tool centerline paths? Hypothetically, one could make the centerline path and create two linked offset paths based on a user-provided tool diameter, and the user could delete the non-useful paths, perhaps? (Making this work for multiple tools in one file would add complication.)
1 Like
  1. agreed, g0 isn’t useful information
  2. I’d map Z to darkness — deepest Z is black, lightest Z is 10% grey — scale as appropriate in-between
  3. Put the lowest things at the bottom of the layer stack and you should still get useful information out of all of it.
  4. If you assign the stroke widths to match the tool paths folks could instantiate the strokes as objects, union them, and then have the cut region
1 Like
  1. Discard Z-only movements.
  2. For XY movements (G1/G2/G3) at constant Z, scale for Z.
  3. For linear XY moves (G1) at non-constant Z, potentially create a linear gradient for each, I suppose? Definitely complicates things.
  4. For arcs (G2/G3) at non-constant Z, the only thing you could do is break the arcs into linear moves and then treat them as 3. You can preserve arcs or preserve non-constant Z, but I don’t believe you can get both into an SVG.

Stroke width to match the user-supplied tool diameter (so you can do “Path/Stroke to Path” in Inkscape) makes sense. Regardless of how you convert G-code to SVG, it’s likely going to be a bit messy and is certainly going to take some finessing by the user to get a cromulent design-equivalent result out of it. A “minimum viable product” implementation approach seems appropriate – get something together, then see how it can be improved.

Maybe your first iteration will not be perfect but I think that that the assumptions you and Will have made will provide a good base. Not knowing if the bit is supposed to be inside, outside or on the line may be an issue but the user should have a good idea of the finished product. The offset tool should provide the ability to adjust some parts.

A quick search on Google will show you that many people have been looking for the ability to convert GCode to SVG for many reasons like being able to modify the design, re-import project files they have lost or re-purpose files they have access to.

I’d also discard any exact overlapping strokes which are higher up in the Z stack.

Ramping in is pretty unusual, and there are very few tools which do it, and even fewer whose output would usefully be represented as SVG as you note.

For my part, I just wish Carbide Create would force a File | Save before allowing a G-Code export.

Hello Luc,

Thanks so much for your response. I had a bunch of unfinished files that I did save and when I opened carbide create today they were gone. They were there the last few days and bam they are gone. Does the program not save unfinished files that I did not convert to G code?

No, I guess it assumes that you are a person that will remember to save. I think this is something that should be changed in a future version as many people have complained about this.

If you save in Carbide Create (using the Save/Save As menu options), you’re saving a .c2d file of the Carbide Create design. If you save the G-code (using the “Save GCode” button on the Toolpath page), you’re saving a .nc file of the compiled G-code.

Assuming you did the former and saved the Carbide Create .c2d design file(s), they are wherever you left them. Carbide Create does not keep a record of what you’ve done (there’s no “recent files” list like most programs), and it may or may not open to the same directory as where you saved last, but it most certainly does not delete .c2d files you’ve saved.

If you’re on Windows and you want to search for “misplaced” files, I highly recommend installing “Everything”, an absolutely wonderful program for making searching for files on Windows work the way Microsoft should have made it work in the first place. You can then start Everything and type *.c2d in the search box, and you’ll see any Carbide Create .c2d design file you have, even if it’s somewhere odd. (Somewhere odd, including saved under a Windows user profile that Windows has arbitrarily decided to replace with a new one, for example.)


Thanks so much Clay. You have been a savior.

So, with the actual issue of the thread solved, back to the digression, eh?

Okay, in the case of identical paths at multiple Z depths in normal mode, I’m keeping just the deepest. That wasn’t difficult, thank Python. :grin:

Ramping is unusual… but then there’s V-carving. For G1 moves in V-carve mode, I’ve got it creating one closed curve per move. I’m doing the math for a circle at each end with a radius calculated from V-bit angle and depth, plus the two outer tangent lines connecting the two circles (or one circle and one point, if one end of the segment is at the surface). I then create a closed curve for each segment. Once in Inkscape, you can Union the paths and get the original geometry. For my very basic first test (a triangle, woo!), this is working.

So, I may have managed parsing V-carve G-code with G1 linear moves, but do V-carving programs (other than Carbide Create) throw in G2/G3 arc moves, too? I’m trying to grok the geometry that would create, and I think a stepwise linear approximation may be “good enough”, although it would embiggen the SVG.

Yes, one of the reasons Vectric Vcarve creates crisper appearing V carves is that it can use G2/G3 arcs to represent them.

I don’t think I’ll be able to parse G2/G3 arcs on a V-carve into SVG elements with anything but a numerical solution (given that the curves they define when at non-constant Z are not themselves circular arcs). Then again, except in cases where the geometry lines up perfectly, it’s all numerical solutions, anyway, to generate the G-code, whether moving linearly or in circular arcs.

(The reason G2/G3 arcs make crisper looking V-carves seems to be more due to a limitation in how many segments Carbide Create can make. As I understand it, G2/G3 arcs are interpolated by GRBL itself, which allows for much finer interpolation than linearizing early, as you can only shove so much G-code through the link so fast.)

My basic test of V-carve G-code import mode (linear G1 moves only, from Carbide Create) seems to be passing now. Got to do some cleanup, but a V-carved triangle and the word “Test” both came in cromulently.

I’ll have to start a new thread once I get things rolling, but for now, there’s just a taste. (Normal mode is also coming along, but I took a side trip to work on V-carve mode, since that was going to be more difficult. There’s a lot more post-import work you have to do in normal mode to recover whatever you’re trying to get, as only you know what to do with the raw data, but I’ll write up some help on that.)


I now have the V-carve path optimization working (as shown below), so I need a V-carving G-code file with G2/G3 arcs in it so I can see about adding code to support those files. Can someone with Vectric Vcarve please make and attach a basic test G-code file for me? (A triangle and the word “Text” is what I’ve been using for my basic test case, obviously.)

With the optimization algorithm working, I should be able to interpolate G2/G3 arcs and then optimize them back down to something reasonable, so I’m thinking it shouldn’t be too difficult to add support to the new Inkscape extension.

(After that, it’s just a bunch of debugging, then cleaning things up and adding some more UI and help.)

1 Like

There is a basic Gcode test file from VCarve with a triangle and the word text I added the zip extension to be able to upload, it is not zip, just removeProfile Test (21.1 KB)

1 Like

Alas, that file is a normal carve, not apparently a V-carve. It also doesn’t have any G2/G3 arc moves in it.

(Is there a certain post processor one has to use for arc support? I’m priced out of the market for Vectric software, so I have no experience to go by.)

As for attachments, if you just change the extension to .nc, it should attach. Inkscape also seems to only allow an .inx extension definition file to provide support for one extension (although there is zero documentation to refer to, other than delving the source), but I believe I can just add two .inx files for that.

1 Like