Organizing CAD revisions and printing profiles: tracing a part from model to machine file

Four separate artifacts behind one printed part

A printed part can be traced through several artifacts used in different software. This page separates the CAD document, a geometry export such as STL, STEP or 3MF, the slicer project or presets, and the generated machine file. These are not necessarily four independent files: a project can contain multiple objects and settings, and a sliced result can use the Gcode.3MF format.

Do not infer the CAD version or original presets from the machine file alone. In its Import Sliced section, the OrcaSlicer wiki describes loading G-code to visualize toolpaths, then recommends Gcode.3MF for printer, material, and process context. This describes the OrcaSlicer workflow; it does not mean every G-code file lacks comments or metadata. Keeping only CAD, conversely, leaves slicing settings to be recovered separately.

The method here is to give each of the four artifacts its own identifier, then record in a log which combination produced which part. A spreadsheet or a text file next to the project folder is enough.

What a CAD version actually freezes in Onshape

Onshape's documentation separates three concepts that map neatly onto a revision convention. A version is a named and saved state of the document; it is immutable, view only, and separate from workspaces. A workspace is the modeling space where you keep editing. A branch is where the document splits: it can hold zero or more versions and at most one workspace.

In practice, once a geometry is ready to print, you create a version with a name and description from the Versions and history panel. To experiment afterward, you branch from that version, which opens a new workspace without touching the original snapshot.

Two details matter for traceability. The Copy link command gives you the URL of a specific point in history, branch or version, which makes a reliable identifier to paste into your log. On the other hand, the same source says Search history does not include version names or descriptions, so your naming convention also needs to live outside Onshape.

Exporting geometry without losing the link to the source model

Exporting breaks the automatic link between the model and the file you load into the slicer. The OrcaSlicer wiki explains that STL describes a surface with triangular facets and that every other supported format, including STEP and 3MF, is converted to STL on import. It also notes that a model created in CAD software may lose details on export depending on the export settings, while a model built in mesh software is usually represented well.

The file name should therefore carry the identifier of the CAD version it came from. Otherwise a file called v3 is just a label with no proof behind it. If you use Onshape, the copied version link is the safest reference; with a local CAD tool, write down the exact version name or source file. Your choice between STL and 3MF changes what the file carries: per the wiki, a generic 3MF exported from OrcaSlicer holds the model without printer, material or process information.

For STEP files, the wiki describes linear and angular deflection parameters that control how fine the generated mesh is at import. Those choices deserve a line in the log, because different settings can produce different meshes from the same STEP. A hash of the exported file identifies its bytes, not its compatibility or its print quality.

Slicer project, presets and machine file: three levels not to confuse

The OrcaSlicer wiki distinguishes the project, exported presets and sliced output. “Save Project” stores objects, print settings and associated configurations in one file. Preset bundles are separate exports: a printer bundle includes its associated filament and process presets, while filament, printer or process presets can also be exported separately. Archive the project and any bundles you need to retain; reimporting them does not guarantee identical behavior in every software version.

The wiki describes two sliced-result exports: G-code intended for printing and Gcode.3MF, which combines the G-code with printer, material, and process information. It recommends the latter for sharing that context. This does not replace the CAD source or prove compatibility with another machine or software version. Keep the editable project to revisit settings too.

After a local edit, save the project with those settings and record overrides in the log. An exported preset bundle does not by itself establish that it contains those edits: check the values and presets actually saved. For an unknown 3MF project, the wiki says OrcaSlicer tries to apply embedded information and ignores it when incompatible. Record what actually loaded.

A naming convention and a minimal log

One fictional example is enough to fix the convention. Say the part is called sensor-bracket. The CAD version is named sensor-bracket V4, with its Onshape link copied. The export becomes sensor-bracket_V4.step, imported with the deflection parameters noted. The slicer project is saved as sensor-bracket_V4_petg-black_p1s-04.3mf, so material, printer and nozzle size appear in the name. The machine file reuses the same prefix followed by whatever suffix the slicer adds.

The log itself is one line per slicing job with blank columns to fill: CAD version identifier or link, exported file name and hash, modeling unit, CAD and slicer version numbers, selected printer, nozzle and filament presets, unsaved local changes, project and machine file paths, then an observation column for the produced part. Leave the result columns empty until a part has actually been printed and inspected.

This discipline resolves the common doubts. A file that opens at the wrong scale points to the unit column, a question covered on the unitless STL files page. A part that differs from the previous one points to the local changes column. A file received from someone else with no log entry simply means it is untraced; it says nothing about its compatibility or its license.

Recording software versions and environment changes

Keep the slicer version number with the project, without assuming that reopening it always yields the same result. The OrcaSlicer wiki hints at this with export statistics: the .statistics.json file carries a version key that goes up only when a key is removed, renamed or changes meaning, and new keys can appear without it, so a script should check the version and ignore unknown keys. The same logic applies to your presets: record the slicer version number in the log.

On the CAD side, Onshape's documentation describes an Update workspace command that brings a workspace created in a previous version of Onshape to the latest version; the document is inaccessible during the update, and each workspace must be updated separately. In the proposed method, record that environment update even if the geometry appears unchanged; it does not automatically constitute a new geometric revision of the part.

In short, for a part you may need to reprint months from now, keep together the CAD version link, the exported file, the slicer project, a preset bundle and the Gcode.3MF, plus the version numbers of the software involved. The software hub gathers the site's other guides on slicers and file formats.

Sources and limits

• Onshape — Versions and History, October 15, 2026
• OrcaSlicer — import_export, wiki

We organize manufacturer and community documentation; we have not measured these products ourselves. The manual for your exact model takes precedence over general guidance.