Commit Graph
2 Commits
Author SHA1 Message Date
Oleksandr ShyshatskyiandClaude Opus 5 30b21262ed Ship the two verification files, not the thing that wrote one
The generator was a build step for an artifact that is written once and
then read by a person standing at a printer. Keeping it meant the file
you send to the machine did not exist in the repo, and the header of the
file you did get told you to re-run a script instead of telling you what
to watch. gcode/ now holds the G-code itself and bin/gen-test-gcode.py
is gone.

Added alongside it: creator5-safe-moves.gcode, the feature print with
the heat and the filament taken out. Once homed, nothing in it goes
below Z50, nothing extrudes, no heater is ever given a target. It homes,
laps the bed slow then fast, runs the diagonals a failing corexy motor
turns into an L, changes tools, sweeps the fans and checks the chamber
gate -- so that a dock that does not latch or a Z offset that is wrong
is found 50 mm up rather than in the plate.

It names its tools with SELECT_TOOL rather than a bare `Tn`, and carries
no M104 or M140. ff_print scans a file's head for exactly those to
decide what to prepare, so this one leaves it nothing to find and is
safe whether FF_BEFORE_PRINT_START.prepare is 0 or 1. The feature print
still wants it at 0.

test_gcode.py reads the committed files now instead of running a
generator, and covers both. The safe file gets the two checks that are
its whole reason to exist -- never below Z50, and never a heater target
or an E word -- because those are exactly the properties a later edit
would break while leaving a file that still runs and still looks safe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 15:05:01 +03:00
Oleksandr ShyshatskyiandClaude Opus 5 959fbd356a Generate the print that proves the macros, not just the machine
The on-hardware checklist ended at "a single-tool test print" and "a
multi-tool test print" without saying which print. Any cube proves the
motion system; none of them prove START_PRINT's preflight gate, the
per-tool purge, the print Z offset, the M106 fan map or the M141 model
gate, which are the parts of this firmware that have never run on a
printer.

bin/gen-test-gcode.py writes one file that drives all of them in the
order a real print drives them, and lays down nested squares -- one ring
per tool, a fixed gap apart -- so the tool offsets can be measured with
calipers afterwards instead of eyeballed.

It calibrates nothing: TOOL_OFFSET_CALIBRATE and STATION_CALIBRATE need
the build plate off, which a print does not have, so the file only reads
the geometry into the log. PAUSE is left out for the same kind of
reason -- a resume that fails should not be buried inside the print the
offsets are being measured from, so the header tells the operator to
press Pause in Mainsail instead.

Four things the first draft got wrong on the machine and not on paper:
T<n> ships with restore_axis unset, so a change restores no position at
all and every move after one has to re-state itself; descending to layer
height before the cross-bed travel dragged the nozzle back over the work
from the dock; START_PRINT's clean leaves each tool retracted by
purge_retract and the start block primes only the tool it starts on, so
a tool's first ring was the one recovering those 5 mm; and parked tools
sat at full temperature oozing into their docks for the whole print.

test_gcode.py is the gate that keeps the file honest: every command in it
must be one the shipped configs or extras define, TOOLS= must list every
tool the file uses, and every coordinate must be inside the configured
axis limits. Renaming a macro now breaks the suite rather than the print.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 15:05:01 +03:00