G-code External Slicer

The G-code lane's procedural generators write toolpaths by hand, but real prints need a real slicer. That's this node's job: it takes a MKR_GCODE_MESH, shells out to an installed slicer CLI, and brings the resulting G-code back into the graph - parsed into a previewable plan so the rest of the lane can analyze and export it. It's the bridge between "I loaded an STL" and "I have a printable file."

How it works

You connect a mesh (from MKRGCodeLoadMeshModel), pick an engine - orca, prusa, or cura - and the node writes the mesh to a temp STL, builds the CLI command, runs it, reads the output G-code, and parses it back into an MKR_GCODE_PLAN. That plan is what MKRGCodePreview can render and MKRGCodePlanAnalyzer can scrutinize.

Where do the settings come from? Three sources merge in: an optional profile (MKR_GCODE_PROFILE), an optional slicer_settings (MKR_GCODE_SLICER_SETTINGS, e.g. from MKRGCodeOrcaProfileLoader), and a raw settings_json string. For Orca/Prusa, the merged config is written as a Prusa-style config.ini and passed with --load; for Cura it becomes -s key=value arguments on the command line.

The two flags that decide everything

• dry_run - defaults to true. In dry run the node builds the command and config, validates them, and reports what it would have run without executing the slicer. That's a great safety feature (the README recommends it for testing your config text before you have the slicer installed), but it's also the classic trap: the first time you wire this up, nothing gets sliced until you flip dry_run off.
• save_file - defaults to false, and unlike dry run it just controls whether the output .gcode lands on disk (in ComfyUI's output folder). The G-code text comes back either way.

engine_path lets you point at a specific binary; leave it blank and the node looks for OrcaSlicer/PrusaSlicer/CuraEngine on PATH, or via the ORCA_SLICER_PATH, PRUSA_SLICER_PATH, and CURA_ENGINE_PATH environment variables. engine_args_text is a newline-delimited argument template with {input}, {output}, and {config} placeholders - the escape hatch when your slicer build wants different flags. The pack's own docs warn that the default Orca path is a Prusa-style compatibility call, so if your Orca build chokes, set engine_path and engine_args_text explicitly.

Outputs

• gcode_text - the sliced output (when it ran).
• plan - the parsed MKR_GCODE_PLAN, ready for preview/analysis.
• output_path - where the file was saved, when save_file is on.
• summary - engine used, warnings, and parsed plan stats.

Installing it

The node itself is part of the pack:

# ComfyUI Manager: search "MKRShift Nodes", install, restart.
# or:
cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes
# restart ComfyUI

The slicer is a separate system install. The README is explicit: install OrcaSlicer, PrusaSlicer, or CuraEngine if you plan to use this node. No Python packages beyond the pack's usual numpy/Pillow/torch, no models.

Gotchas

The mesh input is validated strictly - it needs a real triangle list, so don't feed it an empty load from a bad model_path. And since it's a subprocess call, a wrong engine_path or a missing binary fails loudly in the summary warnings rather than crashing ComfyUI. Read those warnings. This node also gives you the full external-slicer power set (infill, supports, brims, multi-material) that the procedural generators can't - which is why for anything beyond a demo vase, this is the node you'll actually reach for.