The feature print's header and docs/hardware-testing.md both said to set
FF_BEFORE_PRINT_START.prepare to 0 and offered "persist it by editing
variable_prepare" as the way to make it stick. Following that breaks
every other print on this machine.
The Orca profile here deliberately carries no START_PRINT: [ff_print]
wraps SDCARD_PRINT_FILE and the implicit prepare is what homes and heats
the bed. FlashForge's start block has no G28 and no M190 of its own, so
with prepare persisted at 0 an ordinary file's first move -- G1 Z5 F2400
-- runs on unhomed axes, and nothing has heated the bed.
The feature print is the one exception, because it carries its own
START_PRINT with the TOOLS= list the automatic path cannot derive
(nothing in a sliced file names the tool set without reading the
slicer's config block). So it is a per-print toggle, and both files now
say to put it back afterwards -- or just RESTART, which does it anyway.
Comments and docs only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
