Best Practices - Labeling GCode Files

[mattgriffin 28]

As I spend more and more time digging deep into slicer nuances accompanied by hunting through YouMagine and other repos, I've been looking for a better solution for creating a folder template and naming scheme for STLs and .gcode files to take some of the extra effort after setting up each thing.

Here's what I'm doing right now, and I'd love feedback from other users about what they prefer and why!

I'm starting from how to name the gcode files themselves. These are most critical and this scheme, as awkward as it appears, means i never have ambiguity about what I sliced and when I sliced it. I drop this file name into a printing log I keep in plain text that has the details for myself about the actual experiments. And i rely on settings in comments (and add settings in comments if not there) to make the gcode itself also a key way to learn about how it was created.

GCODE files:

 

{Machine+State}_{FileName}_{YYYYMMDD-TTTT}_{FileID}.gcode

 

for example:

 

UM2+PLA8_NozzleMag_20160911-1520_ym9450.gcode

 

Machine+State :

- I create a new machine setting for each of my machines in any state that is annoying to setup.

- So for my UM2+ unit by my desktop, I'll have a "machine" for each of the common configs I setup for it.

- Right now this is UM2+PLA25, UM2+PLA4, etc for UM2+ slammed up next to the material and the nozzle size.

- I'm tempted to create a lookup table for a tighter 3 digit prefix listing to save real estate for the display -- like AA8 for UM2+ with PLA using 8mm nozzle.

- This is an adhoc solution, I think the evolution of Cura 2 series is already getting closer to a better option.

FileName :

- Smash it down the way ProTools and Avid use to, killing vowels and making sure i can still guess

- Again, this is a real estate consideration, and there are probably better ways to do this.

YYYYMMDD-TTTT :

- While adding a manual timestamp in the file title is handy for looking at the card in a computer, you can rarely see to the end on the display.

- By adding 4digit time in 24hr time, i never have clashes between slicing experiments. That's kinda critical to me, even though this isn't clear on the card.

- Right now I'm using card management to remove any no-longer valid gcode from a card before running a model.

- I'm okay with that, I think. Though again a tighter date-time code from a lookup table my save real estate.

FileID :

- This totally betrays my years of working hardcore with thingiverse, but I see this as handy with youmagine and others as well

- Typically there is some sort of item ID for each design post in a repository -- I use it as a museum accession number to make sure even if just stumble on an old SD card with some files on it, i know what the heck "Mount" referred to" or similar.

- For YM, there is a hidden ID you can find in the source (search for "contribution_design_id") or another trick I'll let other community members share if they know about it.

- For Thingiverse, MyMiniFactory, etc, usually you can find the ID right in the URL or on the page (MyMiniFactory ends the design post URL with the number).

Look forward to your thoughts!

[neotko 1,417]

For my prints, since most of the time it's to print the same in series, for the sdcards I do:

Kind of print / Name / type_x(number of repetitions.gcode

For example. Keychains/Cactus/Tall_x3.gcode

Or

Brooch/Dinosaur/tricerap_x2.gcode

For the temps I have postits on each printer with the +/- temp of each machine, so when th job starts I adjust the temperature since each machine has different heat readings from -7 to + 10C (umo+ doesn't have the fancy ultigcode for temperature profiles)

Also when doing a new design I make folders on the sdcard of the day it was made on the root until they go from beta to production ready. I just make v1/v2 etcetc until they are ok so I can match the gcode name with the stl/factory file used.

[rooiejoris 5]

I use Neotko style as well, sort of... I prefer the name of the object first and version as well

Many times I copy all files on the sd card to the folder called "old" so you can find the current files faster.

Important is also that the names are not so long, when working with octoprint in the 8.3 format when printing from SD. That means extension on .g [instead of .gcode]

When I resume prints I use the same name but ending on r1.g, r2.g etc...

And for production on multiple different machine include machine name [uMO, UM2] and nozzle size [without a dot]. Never included PLA in filename since that is my default, maybe add material when it is different.

cheers / joris

[gr5 2,265]

I'm always making my file names too long and when I go to print a part the screen on the UM2 doesn't show the whole name so I can't tell which is which. Because of this when I print my own designs I put the version number first as that changes the most often like:

v17_wrench_nz8_2go.gcode

Would be version 17 of the "wrench" sliced with 0.8mm nozzle for um2go (things sliced for um2go work on any um2 but not the other way around).

On my main network drive which gets backed up every day I store every gcode file and never delete a gcode file if it printed anything - even if it was a failure. That way I can always check back e.g. "how did I print this awesome thing 2 years ago - what were those settings?" The gcode file stores all your cura settings at the end and cura can read them back in so I can find out years later. I also take notes in a notebook I keep near the printers of anything not stored in the gcode file e.g. temperature.

[mattgriffin 28]

I use Neotko style as well, sort of... I prefer the name of the object first and version as well

Many times I copy all files on the sd card to the folder called "old" so you can find the current files faster.

Yeah, i use "zARCHIVED" as a folder, so that on the laptop it is always alpha-sorted to bottom where I can tuck everything that's not active now, but worth not tossing out at the moment.

 

When I resume prints I use the same name but ending on r1.g, r2.g etc...

That's handy -- I'm thinking to take a few of my machines to tinkergnome firmware and use those scripts -- will try that naming scheme.

[mattgriffin 28]

On my main network drive which gets backed up every day I store every gcode file and never delete a gcode file if it printed anything - even if it was a failure.  That way I can always check back e.g. "how did I print this awesome thing 2 years ago - what were those settings?"  The gcode file stores all your cura settings at the end and cura can read them back in so I can find out years later.  I also take notes in a notebook I keep near the printers of anything not stored in the gcode file e.g. temperature.

 

Are these gcode files tucking into folders with the STLs or somewhere else with all of the other gcode? Given the reasonable size of gcode, this suggestion sounds pretty good -- but folders full of STLs and gcode can quickly get messy for me, which is why I started messing with this stuff. And this is why I included the item ID to help me both figure out what the original source was (including my designs -- so I could archive all recent work but search for that ID number and bring up everything associated with it.

This is really handy -- do you ever find yourself adding other comments into the head of your g-code for later review? And also do you ever consider keeping a log of these items and adding other details in another file listing? I'm tempted, but never remember to do this in the heat of the moment when printing something urgently.

[mattgriffin 28]

By the way, was having an excellent conversation off this forum about s3d's file management strategy, and realized that I should be clear here that I'm really looking for what works for YOU and the thinking, not only solutions with Cura. Because if you roll up your sleeves, any behavior is possible with any of the options, as long as you have decided what information is useful to you!

So to bump this again -- what is crucial to you to include in your file naming and where do you put your files so that you can reference how you prepared them in the future?

[neotko 1,417]

When I confuse my file naming or forgot what version did I use I just check the fff (format that s3d uses to save all the slicing parameters with stl objects) and I compare the creation/modification file dates of the gcode with the fff files. So basically I check the timestamp of the files. That for me it's more useful to check 'what settings' did I use at that time or what I changed.

Also I only name the materials when they are special (not pla) like carbon_glassesb7, wood06_cactus. The 06 it's for nozzle size. But I don't print much with anything else than 0.4

For settings I never use the profiles on s3d, but I use the profiles as they evolve saved on their fff zips, this for me it's easier to manage. I don't need to use 15 profiles but I reuse the settings that did work for a job and readjust if needed (temp, retracttion, layer height).

Also for me the gcode it's like the last thing to reuse, I could import settings etc, but for me it's like a ps file for a 2d printer.

I wonder how someone with Octoprints makes his workflow? That could be interesting, since they have more freedom to use and access more than just what it's on the sdcard.

[STEMedTeacher 13]

So for me in a classroom setting, the CAD files and g code files that go to the SD are named somewhat differently.

CAD files get more information as they are not on a small display screen.

filename_version#_ProjectName_studentID# and if it is to an assembly I include that after Project Name

Example: NameOfFile_V01_ProjectName_12345

The file retains the same name when in STL form and we keep them in the same folder so when looking at the structure it is CAD file followed by STL of the same name.

When the g code is saved it retains just

filename_version#_revision#_studentID#

NameOfFIle_V01_R01_12345

Typically I don't need the Student ID# shown here but it is helpful if there are issues that need to be addressed.

The Revision # acts as a place for updates to gcode only when the model is unaffected. It is not descriptive enough however if running multiple materials on the machines.

This works for me as my only SD card reading machines are currently Ultimaker running PLA, but if you are running multiple materials on multiple machines it may be beneficial to include something like a material type# and perhaps a machine# such as: FileName_V01_M03_T02_R01_StudentID#

FileName

V01- Version #

M03- Machine #3 (must label machines by type, Ultimaker vs. Printrbot, etc just give each one a number value

T02- Material type maybe have PLA=01 ABS=02 etc.

R01- Revision # which may or may not be useful

StudentID#- This is case by case, you may need to go with Last name First Initial or something of the sort.

With all of this, I can still link the file name on the SD card to a CAD file and a student who created it, which is most important for me.

[geert_2 558]

I sort my designs first by directory, with an appropriate directoryname for each project. Then within each directory I usually use a syntax similar to this: "modelname_yyyymmdd.extension" to differentiate between versions.

For example, a cable clamp in the shape of a snake (a "snakeclamp"), would sit in the directory "clamps", and its name could be:

"snake_v20160912.rsdoc". In which "rsdoc" is the native file format extension of my DesignSpark Mechanical 3D-editor (on Windows).

Often I have more than one version a day, so I add "a", "b", "c", etc... to the version.

Then I always save a JPG-file of the design too, with the same name. And the STL-file and G-code file.

The JPG-files make it very easy to browse through the directory with an image viewer (I use IrfanView), and to recognise each design immediately.

In summargy, for this "snakeclamp" that would give these four files:

 snake_v20160912a.rsdoc

 snake_v20160912a.jpg

 snake_v20160912a.stl

 snake_v20160912a.gcode

If an update is required to the model on the same day, the files would be:

 snake_v20160912b.rsdoc

 snake_v20160912b.jpg

 snake_v20160912b.stl

 snake_v20160912b.gcode

If in the gcode a model is duplicated, so I get multiple printed at once, I usually add that amount to the filename too, with syntax: "..._x2.gcode". Thus this clamp will be printed twice:

 snake_v20160912c_x2.gcode

Of these files, I only copy the gcode-file to the SD-card for the printer.

Maximum size of the filename to be displayed on the printer is 20 characters, so I try to limit my filenames to that. If the name has to be too long to differentiate between models, then I leave out a few characters of the filename on the SD-card only.

E.g.: a too long name like "snakeclamp_bighead_v20160912a_x2.gcode" could be truncated to "snk_bg_20160912a_x2.gcode" on the SD-card. This is still recognisable, and I can still see the version and the amount of copies. But on the computer, I always keep the full filenames.

Usually I do not include much other parameters into the filename, since I print most of my prototypes with the same settings anyway, optimised for a good balance between quality and speed, and they are close to the defaults.

This syntax, in combination with the JPG-images, makes it very easy to quickly find back all my designs.

Edit: for a picture of the snake clamps for the Ultimaker bowden tube, see at the bottom of this page:

https://www.uantwerpen.be/nl/personeel/geert-keteleer/manuals/

Edited September 13, 2016 by Guest

[gr5 2,265]

Are these gcode files tucking into folders with the STLs or somewhere else with all of the other gcode? Given the reasonable size of gcode, this suggestion sounds pretty good -- but folders full of STLs and gcode can quickly get messy for me,

For one-part simple youmagine downloads (or thingiverse) they just go into my generic ultimaker folder.  If it's a multipart part (more than 1 stl) then it usually goes in it's own folder.  All my own designs go in their own folder as there are ALWAYS multiple versions.  I can stare at a part in cad for an hour and declare it perfect only to print it and seconds later I think (ooh - I should add a hole here), lol.

My ultimaker folder is indeed a mess but I always sort by date and so the relevant stuff is almost always in the top 5 files.

Edited September 13, 2016 by Guest