How the G-code Skill Slices STL/3MF Files for 3D Printing

The G-code skill converts STL, OBJ, and 3MF meshes into printer-ready G-code by inspecting the input, discovering available slicer backends (OrcaSlicer, Prusa-Slicer, or CuraEngine), and executing the appropriate slicing command via subprocess.

The G-code skill in the earthtojake/text-to-cad repository transforms printable mesh files into machine instructions through a robust pipeline implemented in skills/gcode/scripts/gcode_tool.py. This tool handles everything from input validation and format conversion to backend orchestration and output verification, supporting automated slicing workflows for additive manufacturing.

Input Inspection and Validation

Before any slicing occurs, the skill validates the incoming mesh through the inspect_input() function (lines 9940‑9960). This stage ensures the file exists and determines whether it can be processed directly or requires conversion.

The inspection logic checks:

• File existence and extension validation against supported formats (.stl, .obj, .3mf, .ply, .glb, .gltf)
• Unsupported format detection for files like STEP, DXF, or URDF, which trigger remediation messages via the UNSUPPORTED_INPUT_REMEDIATION map
• Pre-sliced archive detection for 3MF files using is_sliced_bambu_3mf(), which checks whether the archive already contains a sliced plate

The function returns an InputInspection object that informs downstream stages whether the mesh can be sent directly to the slicer or requires intermediate conversion.

Backend Discovery and Command Construction

The skill dynamically discovers and configures slicer backends through three key functions, supporting OrcaSlicer, Prusa-Slicer, and CuraEngine in that preferred order.

Discovering Available Slicers

The discover_backends() function searches for executables defined in BACKEND_EXECUTABLES (lines 68‑71) across the system PATH. On macOS, it additionally checks application bundles via find_app_executable(). The preferred order is stored in PREFERRED_BACKEND_ORDER (line 67).

Resolving Backend Paths

backend_path() resolves the final executable path while honoring environment variable overrides such as ORCASLICER_BIN (lines 78‑80). This allows users to specify custom binary locations without modifying system PATH.

Building the Slice Command

Once a backend is selected, build_backend_command() (lines 448‑487) constructs the exact CLI argument list required by that specific slicer. The function maps internal parameters to backend-specific flags, ensuring compatibility across the different slicing engines.

Mesh Conversion and Execution

The execute_slice() function orchestrates the actual conversion and slicing workflow, handling format mismatches and temporary file management.

Format Conversion

If the input requires conversion (e.g., .ply, .glb, or .gltf), the skill invokes convert_mesh_to_stl() (lines 444‑464). This function uses trimesh to load the source geometry, merge any scene hierarchy, and write a temporary STL file suitable for the slicer backends.

Slicing Execution

The execution flow follows this sequence:

1. Create a temporary working directory
2. Convert the mesh to STL if necessary
3. Build the slice plan via build_slice_plan()
4. Execute the slicer command via subprocess.run() (line 779)

After the slicer completes, generated_gcode_candidate() (lines 491‑501) verifies that the expected .gcode file was produced. If the slicer outputs a differently named file, the function locates the correct candidate and renames it to match the user-requested output path.

Practical Usage Examples

The slice_main() entry point (lines 620‑632) provides CLI flags for --dry-run, --execute, and --backend control.

Perform a dry-run to preview the slicer command without execution:

python -m skills.gcode.scripts.gcode_tool slice \
  --input model.stl \
  --output model.gcode \
  --profile my_profile.json \
  --dry-run

Execute full slicing with automatic backend selection:

python -m skills.gcode.scripts.gcode_tool slice \
  --input model.3mf \
  --output model.gcode \
  --profile my_profile.json \
  --execute

Force a specific backend such as CuraEngine:

python -m skills.gcode.scripts.gcode_tool slice \
  --input model.glb \
  --output model.gcode \
  --profile my_profile.json \
  --backend curaengine \
  --execute

Inspect a mesh before processing:

python -m skills.gcode.scripts.gcode_tool inspect \
  --input model.ply --json

Summary

• The G-code skill in skills/gcode/scripts/gcode_tool.py provides a complete pipeline from mesh inspection to validated G-code output.
• Input inspection via inspect_input() validates file formats and detects pre-sliced 3MF archives.
• Backend discovery supports OrcaSlicer, Prusa-Slicer, and CuraEngine, with environment variable overrides for custom binary paths.
• Automatic conversion handles PLY, GLB, and GLTF files using trimesh, outputting temporary STL intermediates.
• Execution flow creates temporary directories, builds slicer-specific commands, and verifies output file generation.

Frequently Asked Questions

What slicer backends does the G-code skill support?

According to the source code in skills/gcode/scripts/gcode_tool.py, the skill supports OrcaSlicer, Prusa-Slicer, and CuraEngine. These are checked in the order defined by PREFERRED_BACKEND_ORDER (line 67), with executables located via BACKEND_EXECUTABLES (lines 68‑71).

Can the G-code skill convert non-STL formats like GLB or PLY?

Yes. The convert_mesh_to_stl() function (lines 444‑464) automatically converts .ply, .glb, and .gltf files to STL format using the trimesh library. It handles scene hierarchy merging before writing the temporary STL file required by the slicer backends.

How does the tool handle pre-sliced 3MF files?

During input inspection, is_sliced_bambu_3mf() checks whether a 3MF archive already contains a sliced plate. This detection occurs within inspect_input() and allows the pipeline to handle already-processed archives differently from raw mesh files.

What happens if the slicer produces a different output filename than expected?

The generated_gcode_candidate() function (lines 491‑501) searches the output directory for generated G-code files if the slicer writes a differently named file than requested. It then renames the located file to match the user-specified output path, ensuring the final artifact appears exactly where the user requested.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}