Timelapse ships always but nothing exercised it. This file takes 72
frames with no filament and no heat, at the Z50 floor that
creator5-safe-moves.gcode uses, so a dead camera or a disabled
component is found in two minutes rather than at the end of a print.
The verdict is in the video: 36 unparked frames catch the head wherever
it is, then 36 parked ones must show it in the same place every time.
Three frames are asked for with the gate shut first, and must be
refused.
Two traps the header spells out, both specific to this machine.
PARK_POS=FRONT_RIGHT and BACK_RIGHT derive from the axis limits and
land on X310, inside the dock lane at X~297, so only CENTER and an
explicit CUSTOM position are used. And TEST_STREAM_DELAY is left out
of the body for the same reason -- it travels to X305.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XnNvM8U26jzH9bopsg7dPi
An adversarial re-read of master..HEAD, checking the new text rather than
trusting it. The substantive work held up -- all eight dead-code removals prove
out, SAFE-MODE->MOD_UI is complete, A3's reordering is correct -- but eleven
claims were wrong, and one made a document worse than it found it:
* docs/notes/10-hardware.md said `temperature_sensor motor_value` on
eboard:PA1 is "not in anything this repo ships". It is:
printer.motor.cfg:37 declares it and that file is in the package, which is
also why ff-toolchange.cfg can name MOTOR_STOP. The real nuance is that
printer.base.cfg does not include printer.motor.cfg. A correct claim in
25-app-vs-klipper-ownership.md was "corrected" into a false denial.
* docs/toolchange.md pointed at a worked example that reaches 0.125 mm. The
only example is NOZZLE=220 BED=80, which gives 0.045; the 0.08 bed term
needs a bed at 100 or above. Both numbers now stated, no forward reference.
* docs/testing.md said 48 tests; pytest collects 53.
* test_config_ownership.py cited bin/patch.sh:80/:88/:128 -- correct on
master, shifted by two when this branch deleted MARK_BEGIN/MARK_END. The
line numbers are dropped rather than re-pinned, so they cannot rot again.
* test_includes.py invented a reason for ff-legacy being last ("so its import
sees every [ff_tool] already declared"). ff_legacy resolves tools at
klippy:ready; order does not matter.
* fetch-assets.sh's replacement usage text omitted BUILD_MOONRAKER and was
less accurate than the vague line it replaced.
* 49-runout's sensor table still claimed `extruder: extruderN` after the A1
fix made that true only of our override, not of the stock file it describes.
* firmwareExe kept "newest version directory" after the same claim was
corrected in how-it-works.md.
* 25-app inverted the preflight call order and omitted that an M23 print gets
neither call.
* creator5-safe-moves.gcode called the prepare's G1 Z10 "the one move" below
Z50; the G28 and offset move before it also go below.
* DOC-DRIFT-AUDIT.md asserted both "Every finding has been applied" and
"Nothing in this file has been applied", and cited five commits after a
hash the rebase had rewritten.
53 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
E -- values and counts. The START_PRINT prologue has no M400 and an idle
timeout of 864000, not 1800000. The nozzle-clean temperature comes from the
material table FIRST, so NOZZLE=240 with no per-tool temp cleans at 220 --
documented backwards before. TOOLS is the paired 0:220,2:240 form. The wipe Z
is the raw eddy frame, not the homed one. The runout M117 strings are
"T<n> clog" / "T<n> out of filament", not E-codes. Grab-verify raises
E0051+tool, not E0143. Docks are at X~297; 250/280 are staging waypoints. The
grab sequence is documented in the order _grab actually emits it. ff_print
exposes seven status fields, not nine, and never emits TOOLS=. Package sizes
reconciled against the real artifacts (62MB built, ~93MB stock, ~370MB of CI
assets, ~60s not 90s). testing.md's sample output block matched no header the
code prints, so it is replaced with the real ones; its pytest row listed two
of six suites.
F -- stale claims. _FF_PREFLIGHT is not "missing". SDCARD_SET_CHANNEL is not
still issued (764af2a). The app and Moonraker do not coexist; the app is gone.
TOOLCHANGE_STATUS has nothing to compare against since the JSON reader was
removed. The JSON is re-imported every boot until a nozzle is saved, not once.
The 23-check render harness was deleted in 91604c2. PURGE now wipes by
default. 50-print-lifecycle.md gained the section on how the sequences are
actually entered now -- [ff_print], not the slicer. The dead "profiles"
concept is gone from three files, one of which printed it on every replica run.
G -- overclaims. The README no longer says a stock reflash puts the printer
back "exactly as it was": it says what is restored and what survives inert,
which is what test-recovery actually asserts. The random ssh password is
conditional on ROOT_PW_HASH being unset. verify.sh no longer warns "ssh will
not start" on every build for a dropbear we deliberately do not ship -- the
check now reads the way round it means. case-install.sh's read-only block says
it asserts nothing. An uncalibrated tool contributes z_adjust, not zero, in
three operator-facing places. offset_base does not cancel out in X/Y. The
safe-moves file's Z50 promise is scoped to its own lines, with the implicit
prepare's G1 Z10 spelled out.
48 passed, 5 skipped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
