Version Control and Gcode

I use the date and a serial number to keep my vector drawings straight, but when GCODE is generated, there’s nothing within that file to match it with a particular vector drawing.

At the moment, it is difficult to keep files organized and together without creating a lot of version files and folders.

I’d be really interested in how you folks handle all of your files/folders/gcode.

One folder per project, complex stuff gets nested folders, for example:


and I try to get stuff uploaded to the wiki or GitHub or cutrocket so I have a backup.

I just keep adding underscores to each version of the file name for revision history clarity. tends to be my favorite filename formatting style.


Do you keep regenerating gcode? I have some parts that I make over and over, but perhaps the “trick” is to never reuse gcode files; always regenerate a current one. Perhaps delete all gcode after cutting with it?

1 Like

I’m with @WillAdams, I use folders for each project and I group them in other folders for similar types of projects. I use descriptions to identify what they are but I try to over-write the GCode files if I make changes to correct something. Before the bitsetter, I also had the bit type and the toolpath sequence. If a two-sided project I also have the side (top or bottom) or tiling where you would have each tile. I guess you have to find a system that will work best for your workflow. The BitSetter makes it much easier as the type of bit, the order, rpm are all provided to you inside the file and prompted during the milling process.


Regenerating can be a problem. Some projects take a long time to generate (the more complicated…the longer), and sometimes getting the settings just right takes some trial and error. When you get one the works the way you want it can be a lot easier to just keep. I try and keep notes with each one I save regarding where the zero point is, the tool, expected material type and dimensions, etc. Like @luc.onthego and @WillAdams I keep a hierarchy of folders with subfolders for each version.

1 Like

I use the “Projects” folder and give the gcode a date in it as well as the tool number at the end. So even if I have multiple gcode files for the same thing I can look at the date to see which one was last. As well as the date I may incorporate v1, v2,v3 etc… if I am prototyping and trying to get something perfected.

“workshop” share on a synology, so my office, work bench, and shapeoko tablet can all access everything.

Every project gets it’s own folder, and currently no need to get any more complicated than that.

(Assets, Illustrator Artwork, Vectric/CC Master files, gcode, and a folder of final assembled JPGs).

if a project is complicated i will have dated test folders, with incremntal files for whatever it was ai was doing that day, sometimes they match up with a big unlined journal i use as a sketch/notebook)

Ok, now that is a way to match the files with my engineering journal. Nice.

Another good idea is to save your MASTER FILE that actually performs without errors with the file name starting or ending with the word MASTER. After that NEVER use that FOLDRE/FILE again except to copy and rename the FOLDER of the Copy for the current date or other naming system you have. IF you change the design - then the NEW DESIGN becomes the MASTER. ALSO, keep ALL of your files archived neatly. You never know when you need to go backwards to find some old idea/file, etc. that you need for a new project.