G-code revisions and known-good verdicts

You sliced the same bracket four times. One used a brim, one changed the layer height, and another lowered the temperature. A month later, the filenames no longer explain which one worked.

PrintStash keeps those slices as revisions on one model record.

The model is the unit, not the file

The source mesh and its G-code files belong together. Each slice receives a revision number and can have a label, notes, status, parsed metadata, and print history.

PrintStash reads common metadata from OrcaSlicer, PrusaSlicer, Bambu Studio, and Cura output. Layer height, material, temperatures, nozzle size, estimated time, and filament use do not need to be copied into a filename. Binary PrusaSlicer G-code is supported too.

Add a short revision label for the reason behind the file, such as 0.16 mm finish or brim after corner lift. The parser can recover settings, but it cannot know why you changed them.

Known good and recommended have different jobs

Known good and recommended answer different questions.

• Known good records that the revision printed successfully. PrintStash can apply this automatically after a successful connected-printer job when the setting is enabled. A manual failed or archived verdict is not overwritten.
• Recommended selects the one G-code revision PrintStash should offer first for that model. You choose it deliberately. A model with G-code keeps exactly one recommended revision.

A successful file is not always the file you want next. A strong prototype may be known good while a slower, cleaner revision remains recommended for the final part.

Other available states include needs test, failed, and archived. Keep failed revisions when their settings explain a useful dead end. Archive a file when it matters historically but should no longer be considered for a normal print.

Why this beats folder discipline

bracket_016_15pct_FINAL_GOOD.gcode tries to store structured state in a filename. It stops working as soon as FINAL changes or the file moves away from the note that explained it.

Revision fields are searchable and stay attached to the model. Content hashing also prevents a byte-identical G-code file from becoming another duplicate just because it arrived under a new name.

Where the notes live, and where the numbers do

Two records sit under one model, and mixing them up is the usual reason people cannot find what they wrote down later.

Prose belongs to the revision. The label and the notes field are where “warped at the corners until I added a brim” or “PETG, plus 5 degrees, matte finish” go, and they stay attached to that slice for as long as it exists. That is the note you will actually reread before reprinting a part.

The print job record holds facts rather than opinions: which printer ran it, which revision, the state it ended in, an error string when something failed, and, on Moonraker, the measured filament and duration plus the cost frozen at completion. Jobs have no notes field of their own by design, so the lesson from a print goes on the revision it taught you about.

Jobs arrive two ways. A connected printer records them as it runs, and Moonraker can import a printer’s existing history onto matching models, which recovers prints from before the library existed. You can also log a job by hand, including against a printer that was never added to PrintStash, which covers the machine at a friend’s place or a print you ran off a USB stick.

A practical habit

1. Add the slice as a revision instead of a separate model.
2. Label the reason for the change.
3. Leave an untested slice as needs test.
4. Let a successful job mark it known good, or set the outcome manually.
5. Recommend the revision you would send if you needed the part again tomorrow.

Record the label and outcome while the reason is still fresh. That is easier than reconstructing the decision from filenames months later.

The full G-code revision workflow covers metadata comparison, the OrcaSlicer hook, and the provider-specific result data that comes back after a print.

Questions that come up

What is the difference between known good and recommended?

Known good records what already happened: this revision printed successfully. Recommended is a decision about what happens next, since it selects the one revision PrintStash offers first for that model. Any number of revisions can be known good, but a model with G-code keeps exactly one recommended. The two come apart more often than you would expect. A quick prototype slice can be known good and still be the wrong file to send for the finished part, so the slower revision with the cleaner top surface holds the recommendation.

What statuses can a G-code revision have?

Four outcomes. Needs test covers a slice nobody has proven yet, known good a slice that printed successfully, failed a slice you do not want repeated, and archived a file that matters historically but should stay out of normal consideration. The recommended marker sits outside those four, so changing an outcome never moves which revision the model offers first.

When should a revision be failed rather than archived?

Mark it failed when the print went wrong and the settings are the reason. Keeping that revision with its parsed settings is what stops you from walking into the same dead end six months later. Archive it when nothing was wrong with the slice but it no longer belongs in the working list: an old nozzle size, or a material you stopped buying. Automatic marking after a successful print does not overwrite either verdict, so a decision you made by hand stays made.

How do I keep notes about how a print actually went?

Write them on the revision, not on the job. Each revision carries a short label and a longer notes field, and that is where the reason for a slice and the verdict on how it printed belong: brim after corner lift, curled on the 0.6 machine, fine on the Voron. Print jobs record the measurable side instead, which is the printer, the state it ended in, any error, and on Moonraker the real filament and duration, so they answer “what happened” while the revision answers “what I learned”. Jobs can be logged manually too, including for a printer that is not connected to PrintStash at all, so a print run off a USB stick still lands in the model’s history.

Why is this better than naming files carefully?

A filename holds one short string, and the record you actually want is a set of settings plus an outcome plus the reason for the change. bracket_016_15pct_FINAL_GOOD.gcode breaks as soon as FINAL stops being true or the file drifts away from the note that explained it. Revision fields stay attached to the model and are searchable, so filtering for known-good slices at a given layer height replaces reading directory listings. Content hashing also keeps a byte-identical file from becoming a second copy because it arrived under a new name.