Oleksandr ShyshatskyiandClaude Opus 5 424ef059a7 Stop telling the operator to persist prepare=0 ...

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>

2026-08-24 15:27:54 +03:00

..

creator5-feature-test.gcode

Stop telling the operator to persist prepare=0

2026-08-24 15:27:54 +03:00

creator5-safe-moves.gcode

Ship the two verification files, not the thing that wrote one

2026-08-24 15:05:01 +03:00