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

> Learn how the G-code skill slices STL and 3MF files for 3D printing. Discover the process of converting meshes into printer-ready G-code using OrcaSlicer, Prusa-Slicer, or CuraEngine.

- Repository: [earthtojake/text-to-cad](https://github.com/earthtojake/text-to-cad)
- Tags: how-to-guide
- Published: 2026-08-01

---

**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`](https://github.com/earthtojake/text-to-cad/blob/main/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:

```bash
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:

```bash
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:

```bash
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:

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

```

## Summary

- The **G-code skill** in [`skills/gcode/scripts/gcode_tool.py`](https://github.com/earthtojake/text-to-cad/blob/main/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`](https://github.com/earthtojake/text-to-cad/blob/main/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.