ff_extruder.py was taken from #29 but never enabled. The fork already accepts
the four [extruderN] sections' repeated pins through duplicate_pin_override,
each extruder keeps its own stepper and pressure advance, and no failure on
a stock config has been shown. It can come back if one is.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
With restore_axis naming X or Y, a real tool change can now raise the old
tool before it crosses the part to its dock, retract the new tool while it
is still seated in its dock, travel back raised, descend, and give back part
of the retract at the target. The options are restore_z_hop, restore_retract
and restore_unretract with their feeds; all are zero as shipped.
From Niels Sedat's #29 without the prime-tower registration, the model-skip
rule, the shared-stepper sync or the stats hooks.
Co-authored-by: Niels Sedat <nlssdt@gmail.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
ADAPTIVE_MESH no longer starts heating the file's second tool, and ff_print
no longer reports next_tool and next_nozzle. Orca's own preheat M104 stays
the only thing that heats a tool ahead of its change.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
From Niels Sedat's Creator 5 branch, the parts that stand without the rest
of it:
- ff_bed_mesh: mesh probing lifts 2 mm above the last trigger instead of to
one fixed height. Active through [ff_bed_mesh] in ff-print-macros.cfg.
- ADAPTIVE_MESH, ADAPTIVE_MESH_TOGGLE and DEFINE_PRIME_TOWER_OBJECT, with
ff_print reading the active plate's prime tower. Used only by a profile
that calls them and sets FF_BEFORE_PRINT_START.defer_mesh.
- START_PRINT heats the bed before the first homing. ADAPTIVE_MESH preheats
the second tool when its first M109 is near the start of the file.
- ff_extruder, the shared-stepper adapter. Shipped inert: no [ff_extruder]
section is configured.
Left out on purpose: the used-tools list and the whole-file scans that fed
it, the ff_stats hooks, the plate and material offsets, and the toolchange
travel changes. The next-tool search reads only the head of the file, so a
second colour far into a print is not heated from the start of the job.
Co-authored-by: Niels Sedat <nlssdt@gmail.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* klipper: clear active mesh before parking with Z unhomed
* Make the park status and mesh tests agree
The unhomed-Z mesh guard reads printer and reactor, which the status
test's park stub lacks, and the status handling reads `changing`, which the
mesh test's stub lacks. Give each stub what the other change needs.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Oleksandr Shyshatskyi <shalal545@gmail.com>
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Add Fluidd and custom boot scripts, migrate DC24V control, update the web UIs and filament macros, improve startup status reporting, and expand upgrade and replica coverage.
Include config examples and reference documentation from the pinned Klipper source so Moonraker can register both file roots. Exclude upstream documentation website tooling, which requires Bash and does not belong on the printer.
OrcaSlicer 2.4.0's Moonraker agent offers to map a project's filaments onto
the printer's slots, and it learns those slots from the `lane_data` namespace
in Moonraker's database. Nothing in the tree said where that data comes from,
so the question "what does this need to work?" had to be answered by reading
three codebases: ff_toolchange's status surface, HelixScreen's AMS backend
and override store, and MoonrakerPrinterAgent.cpp.
The note is that answer as one diagram plus the reasoning around it. Klipper
supplies the slot count and nothing else -- it cannot sense what filament is
in a tool; the operator supplies the identity through HelixScreen; Moonraker's
database is the only durable record; OrcaSlicer reads it once at connect and
never writes back.
It also records the two things that surprised us. The mapping is not applied
at print time -- start_local_print() ignores ams_mapping, so it selects
presets and temperatures at slice time and does not rewrite tool numbers. And
the reason this does not work on our build yet is not a missing feature but a
missing merge: AmsBackendToolChanger was the last AMS backend without a
FilamentSlotOverrideStore, upstream gave it one on 2026-08-24, and our last
catch-up from upstream is four days older than that.
Claude-Session: https://claude.ai/code/session_01PU5nCo85xuFQuub4kJzWt9
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The page says a release is a fixed set of these versions, and two rows did not
hold that up. HelixScreen read v0.99.115-creator5.1 while versions.env has
pinned creator5.5 since it shipped in v20260827d, and Klipper read "a current
fork (branch creator5)" -- a branch is not a pin, and the build uses a commit.
versions.env is right as it stands: HELIX_FILE is the release asset's own name
because the URL is .../releases/download/$HELIX_VERSION/$HELIX_FILE, and the
pinned sha256 matches the creator5.5 asset, which is what CI fetches.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
chelper/__init__.py and c_helper.so are one unit: the first declares the cffi
cdefs, the second is what they describe. FlashForge's 1.9.7 declares
void extruder_set_pressure_advance(struct stepper_kinematics *sk
, double pressure_advance, double smooth_time);
and ours takes a fourth argument. A stock flash restores c_helper.so -- it is
in the chelper.tar their software component carries -- and restores nothing
else in that directory. Their klippy.py, toolhead.py and mcu.py come back too;
gcode.py, bed_mesh.py and chelper/__init__.py do not, because their overlay is
thirty files against the three hundred and twelve in the factory tree.
So a printer that took v20260827 or v20260827b, whose software component
carried our klippy, comes back from a stock flash with our cdefs against their
library and their extruder.py calling it their way: "expects 4 arguments, got
3", at the first extruder, on a machine that has already been flashed back to
stock and has nothing left to flash.
$MODDIR/prog/stock-chelper is FlashForge's directory, off a 1.9.7 factory
/usr/prog, and anvil-link-prog.sh restores it over ours. The whole directory
rather than the two files that disagree: their __init__.py is upstream's,
check_build_code and all, so a .c newer than c_helper.so sends klippy to
mips-linux-gnu-gcc, which no printer has. c_helper.so is touched last for the
same reason.
ONLY UP TO 1.9.7. That is the firmware this copy came off; a newer FlashForge
release may pair a different __init__.py with a different library, and
overwriting it would be this bug pointed the other way. An unreadable version
is left alone too. The version is theirs to state -- no package of ours ships
a software component, so /usr/prog/PROGRAM/software still names FlashForge's.
It rides in anvil-klipper rather than anvil-core, which qa/static caught: a
MIPS c_helper.so in a package declaring Architecture: all installs on anything.
That recipe gets a postinst of its own for the same reason anvil-klipper-config
has one -- anvil-core's pass runs before this package's payload has landed.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
apk decides whether to upgrade from the version string alone. Three recipes
pin an upstream version -- anvil-moonraker on ${MOONRAKER_VERSION#v},
anvil-klipper on the pinned commit, anvil-helixscreen on its tag -- and each
ships a payload/ of ours beside that upstream tree. Our half changes without
the string moving, so the feed serves new bytes under the name every printer
already holds and `apk upgrade` finds nothing to do. #16 did exactly that to
moonraker.conf, the file that moves Moonraker's config to
/usr/data/anvil-data/config.
PKG_RELEASE is that string's other half, and it is the release date now:
pkg_release_stamp, monotone, with the same-day letter as a trailing digit so
20260827b sorts between 20260827 and 20260828. Nobody has to notice that a
payload changed, which is the only version of this that holds.
PKG_STAMP_EXTRA="$(pkg_payload_hash)" is not this and reads as though it were.
It hashes payload/ so the BUILD rebuilds; it says nothing to a printer. All
three recipes had it, and all three would have shipped stale.
test_recipe_layout.py makes it the rule for recipes added later: a pinned
recipe with a payload/ must take pkg_release_stamp, and the failure names the
recipe and the line to write.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A stock package restores every path the mod points at itself except
/usr/prog/klipper/klipperDaemon, which it does not carry: not in the software
component, not in its md5sum.list, no line in run.sh. Whatever sits there
survives every stock flash and stock's start.sh calls it on each boot, so a
printer whose copy was replaced cannot be returned to stock at all -- the file
FlashForge shipped it with is gone, and no package of theirs will put one back.
anvil-core ships that copy now, and anvil-link-prog.sh restores it whenever it
finds a link into $MODDIR at that path -- on a flash and on an `apk upgrade`
alike. One update is enough, and it costs 845 bytes.
The population this is for is the one that keeps up to date: they took a
release that owned the file, they upgraded, and the link is still there --
dangling, since the payload no longer carries what it pointed at. Under the
mod nothing calls it and nothing looks wrong; the bill arrives when they flash
stock and get a UI with no Klipper. Owners who have already rolled back cannot
be reached from here at all and are served by the recovery package.
The shipped copy is FlashForge's, byte for byte, so it is in the parse list
and out of the shellcheck list: they write `mkdir -p $(dirname $KLIPPER_LOG)`
and a lint fix would put a script on printers that no FlashForge machine has
ever run. The replica asserts its md5 after the restore for the same reason.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
It is the one file a stock flash cannot undo, and replacing it is what left
owners with a printer that would not print. A stock package restores the other
two paths the mod points at itself -- its run.sh copies its own firmwareExe and
start.sh over them, and busybox `cp -f` unlinks a symlink rather than writing
through it. It carries no klipperDaemon at all: not in the software component,
not in its md5sum.list, no line in run.sh. So the link outlived the mod, and
stock's start.sh, whose last line is
/usr/prog/klipper/klipperDaemon start
ran our shim, whose `start` does nothing on purpose. The UI came up, klippy did
not, and flashing stock again changed nothing because there was nothing in it
to change.
The shim guarded that same line: klippy is an s6-rc longrun here, and stock's
klipperDaemon forks a second, unsupervised one that fights it for /dev/ttyS4
and /tmp/uds. But no caller is left on a modded machine. Our own start.sh
replaces stock's and asks s6-rc; FlashForge's firmwareExe execs
/usr/prog/klipper/start.sh and names no other script (`strings` on their
binary); Moonraker runs with `provider: none`, so a restart from Mainsail goes
over the API rather than through a service script; ff-startup and S70klipper
drove it once and neither exists now. What remains is a person typing
`klipperDaemon start` over ssh, who gets FlashForge's behaviour and a second
klippy -- s6-rc and s6-svc are the supported way, and that trade buys back a
printer that can be returned to stock.
test_install.py asks the machine the inverted question now: klipperDaemon is
not a link into $MODDIR, it exists, and it is FlashForge's own script.
Printers that already took an earlier release still carry the link and cannot
be repaired from here -- nothing of ours runs during a stock flash. The
package at Klipper4FlashForge/stock-recovery puts their copy back.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A printer still on 1.9.4 does not come up on this package: the board firmware
that release pairs with differs from the one klippy is built to talk to, the
MCU never connects, and the failure is at the bottom of the stack -- no
Klipper, so no screen and no Mainsail. From the outside it is indistinguishable
from a bad flash, and the only way out is flashing stock again.
So it is refused before anything is written, with the fix in the message:
install FlashForge's own current firmware first, then this. That costs one
more flash and leaves a working printer either way.
WHAT IS READ is /usr/prog/PROGRAM/software, which holds one directory named
for the version of FlashForge's software component -- install_component wipes
the previous one before renaming the new one in. No package of ours ever ships
a software component, so it goes on describing the printer rather than the
mod. The highest is taken when a machine somehow holds two, so a leftover from
an interrupted install cannot refuse a printer that should go ahead, and the
comparison is field-by-field numeric because a string compare makes 1.9.10
older than 1.9.6.
AN UNREADABLE VERSION IS INSTALLED ON. The two failures are not the same size:
letting one through costs a printer that has to be flashed back to stock,
while refusing on one would break the install path on every machine whose
layout is not the one being read.
THE REFUSAL HAS TO BE VISIBLE. It happens before the panel is switched to
start.img and app_startup.sh goes on booting the printer, so from the outside
the flash would just have done nothing. installer/stock-too-old.img is the
frame it paints instead -- the same raw 480x800@32 framebuffer dump start.img
is, rendered by the same ffscreen.py, so it needs nothing on the printer but
`cat > /dev/fb0`. The version in it is DRAWN, so bin/pack.sh carries the
command to re-render it when MIN_STOCK_VER changes. anvil-NOT-INSTALLED.txt on
the USB stick is the copy that survives the power cycle.
Three tests, on the replica. The machine there is a real one in the way that
matters -- its /usr/prog/PROGRAM/software holds FlashForge's own 1.9.7 -- so
"current firmware installs" needs no setup, the refusal swaps that directory
for one holding 1.9.4 and restores it, and the third asserts that a stale
1.9.4 left BESIDE the real version does not refuse. The control matters more
than the refusal: a gate that refused everything would pass the refusal test
and brick every flash.
qa/replica/test_upgrade.py is 19/19; the lane's 10 other failures are the ones
master has on this bake.
Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Keep the config in a directory of our own
Flashing a stock FlashForge package back over the mod left a printer that
would not start. /usr/data is the DATA partition: a stock flash rewrites
/usr/prog and does not touch it, so the symlinked printer.base.cfg and the
ff-*.cfg beside it outlived the mod, pointing into a /usr/data/anvil that was
gone -- and Klipper treats an [include] it cannot resolve as fatal. Nothing of
ours runs during a stock flash, so there is no undo to write from inside the
mod. Not writing there is the only version of this that works.
The live config is /usr/data/anvil-data/config now, seeded once by
anvil-link-prog.sh with a copy of everything in /usr/data/config: printer.cfg
with the SAVE_CONFIG block of calibrated values at the end of it, and the stock
includes the mod neither ships nor parses. The seed test is printer.cfg, which
is copied last and through a temp name, so a machine that never finished seeds
again on the next boot rather than staying half-configured, and no update ever
re-seeds over a tuned file. It is outside $MODDIR, so the installer's
wipe-and-extract cannot reach it and nothing has to be stashed on /tmp.
Moonraker moved with it, and the lever is the data path rather than -c:
moonraker registers its config root as <data path>/config and nothing
configures that separately, so -c alone would move the file it READS while
file_manager kept registering FlashForge's directory. With -d
/usr/data/anvil-data its config directory is klippy's, which is also what
Mainsail's config editor lists. gcodes and logs stay where the machine keeps
them -- /usr/data/gcodes is klippy's [virtual_sdcard] path -- as symlinks
inside the data path, which works because register_directory() realpaths a
root that is a link. The database is carried across once, by the service,
below the stray-killer: the one point where moonraker is provably not running.
What an older release left in /usr/data/config STAYS there. A sweep could
delete the links but could not put stock's own printer.base.cfg back, because
the release that replaced it kept no copy -- and stock's run.sh force-copies
its own onto every flash, which repairs that directory whether or not anything
was swept.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG
* Ask the config-directory test about this installer, not the bake
test_flashforges_config_directory_is_never_written asserted that the mod's
filenames are absent from /usr/data/config. On a replica baked from a release
that still WROTE them, that is a question about the bake rather than about the
installer under test, and it fails for a reason the change cannot fix.
Remove them, run the installer over the top, then ask. The property is "an
install writes nothing there", and that is now what is measured.
Verified on the replica: qa/replica/test_upgrade.py is 18/18. The five
test_install.py assertions about the seeded directory still need a machine
baked from a package built with this branch -- work/out holds one from
2026-08-30, which symlinks into /usr/data/config as the old code did.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG
* Ask the config directory of a machine that has one
The five assertions about /usr/data/anvil-data/config could only pass on a
replica baked from a package built with this branch, and the bake installs
work/out/*.tgz -- whatever was built last. So they failed for a reason the
change cannot fix, and the gate could only go green after a full build, which
is exactly when nobody runs it.
Two different fixes, because the questions are two different kinds.
WHAT THE INSTALLED PACKAGE PRODUCED is still asked of the bake, but the
directory is now read off the machine instead of written down: PRINTER_CFG in
the installed etc/s6-rc/source/klipper/run is the command line klippy is
exec'd with, and therefore the only thing that decides which directory is
live. test_install.py and test_klippy_extras_import.py follow it, so the
include set, the graph walk and the user's printer.cfg are asked about
whichever side of the move the installed package was built on.
WHAT THIS CODE DOES is a new module, test_config_directory.py, which stages
anvil-link-prog.sh from the checkout and runs it -- the way test_upgrade.py
stages the installer. Only the timing is mocked: it seeds from a real
printer.cfg with FlashForge's real includes beside it, links the ff-*.cfg the
installed package really shipped, and reads MACHINE= out of the real
app_startup.sh. It asserts the seeding carries the machine's own marker, the
links point into $MODDIR, the chamber config matches the model, every include
resolves, a second run does not re-seed over an owner's edit, and the run adds
NOTHING to /usr/data/config.
That last one is a DELTA, not an absolute. A machine that has been through a
release which symlinked into FlashForge's directory still holds those links
and nothing can restore what they replaced. What this code owes is that it
adds nothing.
Verified on the replica: 135 passed, and the 10 failures are the same ones
master has on this bake -- ffmpeg, numpy, the timelapse component and the
hardware services, all missing from the 2026-08-30 package in work/out.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG
* Link every .cfg the packages ship, not a list of names
test_every_include_resolves_in_the_new_directory failed on CI:
printer.base.cfg has [include timelapse.cfg] and no timelapse.cfg was in
/usr/data/anvil-data/config, which Klipper treats as fatal.
anvil-link-prog.sh linked printer.base.cfg and the ff-*.cfg by name.
timelapse.cfg is anvil-timelapse's and matched neither, so it reached the
live directory only through the installer's copy of $MODDIR/config -- and
never at all on the `apk upgrade` path, where the link script is the only
thing that runs. A named list is a file that resolves on a fresh install
and goes stale the moment a package adds one.
So the rule is the glob: every .cfg in $MODDIR/config is linked, and the
installer skips every .cfg rather than the four names it knew. The .conf
beside them stay the installer's -- moonraker-custom.conf is the owner's
file to edit, so it is copied once and never linked to a package's copy.
test_the_mods_configs_are_links_into_moddir asks the same way now, so a
package whose config nothing includes is covered too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YULWHVHyxKm2HE9kiPfEjP
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Document automatic pressure-advance calibration
FF_PA_CALIBRATE/FF_PA_PROBE and HelixScreen's calibration-screen
integration shipped without owner/experienced-user documentation --
only the reverse-engineering notes covered it. Adds a table row and
full section to how-calibration-works.md, and links back to it from
the notes page.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147AQiPYgtafuy1x5NjqJuy
* Add a simple pressure-advance calibration page
Owner-facing procedure alongside XYZ tool calibration and bed mesh --
FF_PA_CALIBRATE with a temp and tool number, what the output means,
and how to save it. how-calibration-works.md's mechanism section now
links here instead of duplicating the command walkthrough.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147AQiPYgtafuy1x5NjqJuy
* Point pressure-advance results at the slicer, not printer.cfg
PA is a filament property, not a printer one -- a value baked into
printer.cfg is wrong the moment you switch material. Recommend the
slicer's per-filament Pressure Advance field instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147AQiPYgtafuy1x5NjqJuy
* Correct pressure-advance page: there is no factory value
Unlike tool offsets and bed mesh, PA calibration doesn't import a
factory number on first boot -- FF_PA_CALIBRATE only measures and
reports one. Say that instead of implying it's pre-populated.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147AQiPYgtafuy1x5NjqJuy
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* Show the first-boot screen instead of describing it
bin/preview-boot-screen.py already renders every ffscreen.py phase to PNG
on the host, byte-identical to what the printer draws (make boot-screen-sim
proves it against the real replica). Four of those frames -- waiting,
importing, saving, complete -- now sit in installing.md's first-boot
walkthrough instead of leaving the reader to picture a progress bar from
prose alone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RMV6mRtJ4dCxAj2QAifT8v
* Two big frames beat four small ones
24% width left the boot-screen text unreadable. Down to importing and
complete at 48% -- the same sizing the README already uses for the
HelixScreen pair -- and dropped the two frames no longer referenced.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RMV6mRtJ4dCxAj2QAifT8v
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
FF_PA_CALIBRATE TEMP=245 heated the hotend for the sweep and then left
it sitting at 245 forever: _heat only ran M104 + TEMPERATURE_WAIT and
nothing restored the target. Now _heat snapshots the heater's previous
target (usually 0) and both FF_PA_CALIBRATE and FF_PA_PROBE put it back
in a finally, so the heater comes back down even when the run fails.
A heater the operator set by hand -- no TEMP= given -- stays theirs,
the same put-back-what-we-found rule as the rest of _guarded.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RLsVzXppRdXChrDCsMKkA
v0.99.115-creator5.4. The screen was built for a printer with one hotend --
one nozzle reading, a Load button that never said which head it meant -- and
on this machine that was not merely thin: preheat resolved "the nozzle" to the
ACTIVE extruder, so selecting T2 and pressing preheat heated T0. Every nozzle
target now goes to the selected tool's own heater, cooldown builds its heater
name the same way, and where no heater resolves the command is dropped with a
log line rather than sent to the wrong hotend. The panel above it is a row of
tool chips, and the reading, the graph and the presets follow the selection.
HELIX_PKG_VERSION MOVES WITH THE TAG, which is the whole reason the two lines
are neighbours in versions.env: `_p4` for `-creator5.4`. The upstream release
title calls this build 5; the tag's own revision is 4 and that is what a
package version can be ordered by.
Measured: `make packages PKG=helixscreen` builds anvil-helixscreen
0.99.115_p4-r1 against the new tarball, whose sha256 is the one the release's
own SHA256SUMS publishes, and qa/static passes at 319.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017rgrDeu9YAUuMM2G7gKTpL
Phase 3 of docs/notes/85-packaging.md was three things: signing, a URL the
printer asks, and a tree at that URL. The migration landed the first. This is
the second, and the tooling for the third.
THE POINTER HAS TO SHIP BEFORE THE HOST EXISTS, which is why this lands with
nothing serving yet. A feed cannot tell a printer where the feed is: a machine
installed without etc/apk/repositories needs a USB stick before it can ever
fetch anything, which is the thing packages were adopted to stop. So the file
travels in the .tgz, naming a host that does not answer yet, and every printer
installed from today starts fetching the day one does.
The cost of that is bounded, and was read out of apk's source rather than
assumed: an unreachable repository fails `apk upgrade` and nothing else --
apk_db_repository_check is called from app_upgrade.c and not from app_add.c,
so `apk add ./file.apk` does not consult a repository at all.
http://reforge.8941973.xyz/apk/mipsel_xburst2/anvil.adb
bin/common.sh's FEED_URL is the base, config.env can override it for a fork,
and pkgs/anvil-core generates the file from it beside the public key it
already shipped. Three things about that URL:
* IT NAMES THE INDEX FILE, not a directory. src/repoparser.c reads a line
ending .adb as a v3 index in place, with the packages as siblings named by
the pkgname-spec mkndx wrote into it; anything else sends apk looking for
<url>/<arch>/APKINDEX.tar.gz. That is the layout this repo already builds
and the stick already uses, so the network feed is the same shape --
exercised by every payload build rather than only in production. The v3
directory form would work too, but only with
`mkndx --pkgname-spec '${arch}/${name}-${version}.apk'`.
* THE ARCH IS A DIRECTORY. Package file names carry no architecture, so two
architectures served from one directory would be two files with one name.
* PLAIN HTTP. libfetch defaults to SSL_VERIFY_PEER and this printer has no
certificate bundle -- the same gap tools/python/README.md records for
CPython. Every package is signed, and the signature rather than the
transport is what decides whether a printer installs one.
bin/publish-feed.sh writes the matching tree and optionally rsyncs it.
Packages go first and the index last, because the index names every package by
sha256 and a mirror carrying a new index with old packages hands printers a
checksum for a file that 404s. Nothing is deleted at the far end. It refuses
an unsigned feed unless ALLOW_UNSIGNED=1: a printer verifies against the key
that shipped in its own anvil-core, so an unsigned feed is one no printer
installs from. The release workflow attaches the same tree as
reforge-apk-feed.tar.gz, so a host can be filled from any release -- including
ones tagged before the host existed -- without rebuilding.
THE REPLICA STOPPED WRITING THE FILE IT USED TO DELETE.
case-build-payload.sh wrote its own etc/apk/repositories naming /mnt and
removed it before tarring; it now passes --repositories-file with a path on
the stick, which apk reads INSTEAD of the default (database.c consults the
default file and repositories.d only when no file is named). So what ships is
whatever anvil-core installed and the build never reads it. The `apk info`
line takes the same flag: without it that one command reads the shipped file
and reaches for the network, which a build's output must not depend on.
Measured: 47 packages built from a cold cache, the payload assembled in the
replica twice, qa/static at 319 passed. Two of those are new -- the default
URL in common.sh (read from the file, not resolved, so a fork setting
FEED_URL in config.env still passes) and the built payload carrying a
package-owned entry that ends /mipsel_xburst2/anvil.adb.
What is left is operational: a host answering at $FEED_URL, and who runs
publish-feed.sh -- a release step with a deploy secret, or a person with the
tarball.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017rgrDeu9YAUuMM2G7gKTpL
_probe wrote the PARK= argument into self.park before running the
pre-flight checks, but the restore sat in the finally inside _guarded --
so a probe refused for a cold extruder or unhomed axes kept the
override. FF_PA_PROBE PARK=0 followed by any refusal would silently
turn parking off for every later FF_PA_CALIBRATE, landing the gram on
the plate instead of down the chute.
The override now goes on inside its own try/finally that covers the
checks too, with the rest of the probe split into _probe_inner.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBzgZQiUiARJcG1NupWgY2
_guarded snapshots the pins on entry and _restore puts back what it
found, which is right for every value except one. If a run ever ends
with the latch still on, the next run snapshots 1.00, faithfully
restores 1.00, and the drivers stay dead -- one aborted run turning
into a printer that relatches itself on every subsequent run. Release
the latch instead of reinstating it; only a non-latched value is worth
restoring truthfully.
Also correct an overstatement in the previous commit. A klippy or MCU
shutdown does NOT leave the drivers latched: [output_pin] hands
shutdown_value, which defaults to 0., to setup_start_value, so the MCU
drives PH2/PH3 low by itself. The guard earns its keep on the ordinary
failures -- a command_error, a cancel, an exception out of the sweep --
which unwind through _restore with the machine still running.
The latched and released values are named rather than spelled 1.00 and
0.00 at four call sites, since the comparison in the snapshot now
depends on them agreeing.
SET_PIN PIN=enable_pin_tmc_x VALUE=1.00 disables the X driver outright.
It is not Klipper's stepper enable -- that is !PJ6 and !PJ2 -- but a
second latch on PH2/PH3 that Klipper knows nothing about. So for the
whole sweep every G1 X in the ladder is planned, step-generated and
clocked out against dead drivers, and the gram of filament falls
straight down from wherever the toolhead was standing.
clearNozzleEddy settles it. Just before its jal to paTestMgr it builds
the string resetTmcPa replays: X = 275 + tool_dx, Y = 254 + tool_dy,
Z = probeZ + 2.8, from the constants at 0xdb6b2c/0xdb6b28/0xdb6b24 --
the purge chute, the same pair ff-filament.cfg carries as purge_x and
purge_y, with a -8.0 that is literally our tool_dy[3]. The app parks
over the chute, kills X and Y, dumps into the chute, and then tells
Klipper the carriage is still at the chute, which is only sane because
it never left.
We inherited the latch and the height without the park, so the ladder
piled onto the plate wherever the nozzle happened to be. Park in
_FF_FILAMENT_PREP's own three moves before the latch goes on, replay
SET_KINEMATIC_POSITION after, and shout when the pins will not unlatch
rather than leaving a printer that cannot move.
The replay lands after RESTORE_GCODE_STATE, not before: set_position
fires toolhead:set_position and gcode_move recomputes last_position
from base_position/homing_position, so it has to see the restored
offsets.
The 0.05 mm default was derived from what the guard can resolve rather
than from what the machine actually measures: with four symmetric points
one bad point of error e shows up as only ~e/4 in the residual while
moving the fitted centre by e/2, so 0.05 trips at centre errors of about
0.1 mm. That is inside the ESTOP's own repeatability. A healthy run on a
Creator 5 Pro fits with a worst residual of 0.23, which the guard
rejected -- and rejecting means aborting without saving, so a good
calibration was thrown away.
Default is now 0.5, which trips at centre errors of about 1 mm. A probe
that missed the bore edge or fired on the way in still lands far outside
that; ordinary scatter of a couple of tenths passes. 0 still disables,
and the option is still settable per printer.
The other guards are unchanged: min_radius/max_radius are off by
default, gap_min/gap_max is a 1.5..5 mm window around a nominal 3.2 mm
rise, and plate_z_tolerance is one-sided at 0.8 mm.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013DYQe3sx9XDhz59PDHCDNU
The station pass needs an empty carriage, so with a toolchanger it always
parks: PARK=0 only said "I docked it by hand", which the sensor check
right below already decides for itself. Without [ff_toolchange] there is
no TOOLCHANGE_PARK to call and no sensor to ask, so the pass just runs --
where it used to demand PARK=0 before it would.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UfsqVZ3aXL3qxr3BFDS35x
It served an operator who does not exist: anyone who wants the axes left
alone simply does not run a calibration command, and nothing in the tree
passes HOME=0. Both commands home when an axis is unhomed, full stop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UfsqVZ3aXL3qxr3BFDS35x
Every move both offset commands make is in absolute machine coordinates,
so an unhomed axis is a crash, not a warning -- but refusing with "home
all axes first" just made the operator type the G28 we were about to
need. Both commands now run it themselves; HOME=0 keeps the refusal for
anyone driving the axes by hand.
Homing docks a mounted tool (Z homes on the carriage's eddy sensor), so
the tool pass no longer keys its re-grab off the plate check having run:
it asks the toolchanger what is on the carriage, picks the tool back up
if it is not there, and refuses to measure a carriage it cannot verify.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UfsqVZ3aXL3qxr3BFDS35x
Brought onto this branch rather than onto master so one CI run covers
the combination. #9's own green run predates the apk migration: it was
proved against an opkg feed, and the klipper-config payload it edits is
now built and installed by a different package manager.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rbKEyLXrzSE6wm3iNApVp
ci.yml writes MOD_VER=ci into config.env, and MOD_VER is anvil-core's
PKG_VERSION. apk's version grammar wants a digit first, so mkpkg
refused it -- with "info field 'version' has invalid value", naming
neither the package nor the value nor where it came from. A free-form
version was fine for .ipk, which is why the line survived the
migration unread.
MOD_VER=0 now. It is pinned rather than left to the date default so
two runs of one tree produce the same bytes, and 0 says "not a
release" as plainly as the word did while ordering below every real
version.
emit_apk checks the version before calling mkpkg and names the
package, the offending value and the config.env setting to fix. The
grammar test covers the recipes, and could not have caught this: the
value comes from config.env, so anvil-core answers with whatever the
machine running the test happens to say -- a date, locally, always
valid. The new gate reads MOD_VER out of the workflow files
themselves, which is the only place that value is written down, with
a companion asserting a workflow still pins one at all so the check
cannot pass by having nothing to check.
busybox's pkg.conf expanded $BUSYBOX_BIN bare and let a failed
sha256sum through a pipeline. Sourced under `set -euo pipefail` it
therefore failed -- correctly skipping the recipe, since pkg_recipes
evaluates PKG_WHEN in a subshell, but printing "BUSYBOX_BIN: unbound
variable" twice into every CI log immediately above the first real
failure, where it reads like the cause. With that fixed every recipe
reads under the build's own flags, so the unsigned-recipe gate now
covers all of them rather than only the ones a build would make: a
recipe that cannot be read is dropped by that subshell rather than
reported, so the failure mode is a package silently leaving the feed.
Verified with the production key: 290 static, 135 replica, 47 signed
packages and a payload. MOD_VER=ci reproduced locally against the new
message, and MOD_VER=0 built and pruned clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rbKEyLXrzSE6wm3iNApVp
EXCLUDE_OBJECT installs the ExcludeObject move transform, and inside a
cancelled object _ignore_move updates Python state without ever calling
next_transform.move(). Nothing reaches the toolhead, so the lookahead
buffer that normally blocks gcode.run_script never fills, and
virtual_sdcard.work_handler runs on its own yields alone -- one
reactor.pause per 8192-byte read, about 330 lines apart. The eboard's
soft-PWM refresh misses its deadline and the MCU shuts down with
"Timer too close".
Measured on a Creator 5 Pro: 37 s from "Excluding object" to the
shutdown, with 1 Hz status queries answered in 1.30-1.78 s throughout
while the main MCU sat at mcu_awake=0.000 and gcodein=0.
EXCLUDE_OBJECT_DEFINE is not the cost. The line costs 115 ms through the
live klippy and nothing thereafter; three prints of the same file
without a cancel complete with bytes_retransmit=0. Removing it removes
the object there is to cancel, not the work.
tools/gcode-bench holds the harnesses, including the shlex fast path
that takes that DEFINE from 91.6 ms to 5.9 ms on the printer -- worth
having for large plates, but not this bug.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AVUMfbNuKUWWV32PBcydwb
PR #10 was green on this machine and red on both CI jobs. Three
separate faults, none of which a local signed build could show.
apk-tools is cloned from gitlab.alpinelinux.org, which answers a
GitHub runner with HTTP 418 or with nothing until the connection
times out. It clones from the GitHub mirror now. Which host serves
it cannot change what is fetched: the pin is a commit sha, and git
names a commit by the hash of its content, so a mirror answering
with this sha is serving this tree or is not answering. get_git also
sets the remote url on every run, so a checkout made before this
commit does not keep fetching from the host that refuses.
anvil-core's cache key hashed the feed's public key as
sha256sum "${APK_SIGN_KEY:-/dev/null}.pub" 2>/dev/null | cut ...
With no key that file is absent, sha256sum is non-zero, pipefail
makes the pipeline non-zero, and build-packages.sh -- which sources
every pkg.conf under `set -euo pipefail` -- died before emitting a
single package. The 2>/dev/null ate the reason, so `make packages`
exited 1 having said only that it had sealed a cache entry. Every
signed build passed. Every CI build is unsigned. It is now
pkg_signkey_hash, which answers `unsigned` and succeeds.
The build container mounts the checkout and nothing else, so a key
at the documented ~/.anvil/anvil.rsa was visible in the developer's
shell and invisible to apk. The Makefile reads APK_SIGN_KEY out of
$(CONFIG_ENV) and bind-mounts its directory read-only. This survived
review because the key used while writing the migration sat under
work/, inside the one directory already mounted.
Gates for all three, each verified against its own bug by reverting
the fix under it. The recipe-reads-unsigned test runs pkg_conf under
the same flags build-packages.sh uses -- the existing _conf helper
does not, and would have stayed green throughout. Its companion
asserts the recipe SET does not change with the key, because
pkg_recipes evaluates PKG_WHEN in a subshell and a recipe that fails
to source is dropped rather than reported: broken only when
unsigned, a package would leave the feed with nothing turning red.
Both are scoped to what pkg_recipes lists, so busybox -- gated off
whenever there is no stock firmware to take one from -- is not
asked a question it cannot answer.
release.yml takes the private key PEM from secrets.APK_SIGN_KEY,
writes it to $RUNNER_TEMP outside the checkout where no later step
can archive it into a release, and derives the public half rather
than storing a second secret that could drift out of step with the
first. Unset, the release builds unsigned with a warning: a fork has
no such secret, and firmware nobody else can build is worse than a
feed untrusted on a stick the printer was handed by hand.
Verified from a cold work/host and work/packages, three ways: no key
(the CI case), a key inside the tree, and a key outside it at the
documented location. Each gives 47 packages plus the index, a
payload, 286 static and 135 replica tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rbKEyLXrzSE6wm3iNApVp
docs/notes/85-packaging.md chose opkg in 2026-08 on one argument: every package
is cross-built here anyway, so the winner is whichever format is cheapest to
PRODUCE -- and .ipk had an upstream tool where .apk meant abuild, a keypair and
an Alpine host. Two lines of that comparison were wrong.
apk mkpkg is an applet of apk itself: -I key:value metadata, -F directory, no
keypair, no abuild, no Alpine host. The "making a package" row described
apk-tools 2. And the on-device client was counted a wash when it is better than
one -- openssl and zlib were already cross-built for CPython, and libarchive
existed in this tree only for opkg, so adopting apk REMOVES a cross-build.
What made it possible at all is that apk resolves its database relative to
--root and uses the same root as the file destination, while / here is a
read-only squashfs -- measured: neither /lib/apk nor /etc/apk can be created.
pkgs/3rdparty/apk-tools/prefix.patch splits the two. Upstream already carries
root_fd and dest_fd separately and merely aliases them in context.c, so the
patch defaults the database root to $MODDIR and leaves files extracting at /.
That is opkg's compile-time VARDIR plus `dest root /`, in apk's spelling.
THE FEED IS SIGNED NOW, which it never was: opkg signed the index and
bin/build-packages.sh signed nothing, so nothing was verified on a printer.
apk verifies with raw PEM public keys, not X.509 -- measured on the machine,
where every certificate directory is empty. ./bin/apk-keygen.sh makes an RSA
pair, APK_SIGN_KEY in config.env points at the private half, and the public
half both seeds the USB stick (so the first install can verify) and ships in
anvil-core (so the printer keeps trusting). An empty APK_SIGN_KEY still builds
an unsigned feed, deliberately: `make packages` has to run on a bare checkout
or the packaging lane stops being a CI gate.
WHAT IT COST is a carried patch, against an internal with one consumer, on a
branch mid v2->v3 transition, on an architecture with no upstream apk port to
share the rebasing. That is the standing risk and it does not go away.
Four bugs this shook out, all silent, all found by a gate rather than by
reading:
* The prune deleted seventeen packages it had just built. The all -> noarch
mapping went into the emitter and not into pkg_pkgfile, so the prune looked
for a name nothing wrote. `make packages` exited 0.
* Whitespace-separated Depends dropped nineteen packages. opkg's pkg_parse.c
splits that field on ',' and nothing else, so the whole list became one
dependency whose name contained spaces and resolved to nothing -- and opkg
neither warned nor failed. `make build` shipped a payload with no Tornado
in it. test_the_payload_is_dependency_closed is what catches that now.
* Ownership was recorded as `nobody`. apk resolves an owner to a NAME against
<--root>/etc/passwd and the build lane runs --user with no passwd entry, so
every file in every package would have installed as uid 65534, with no
error at build or install time. build-packages.sh writes a two-line
synthetic passwd naming the build user root and points --root at it.
* Four recipes carried versions apk cannot parse -- two spelled a commit
+git<sha> where the grammar's hash slot is ~, x264 had a snapshot name
whose -2245 reads as a malformed release, and helixscreen had
0.99.115.creator5.3 where apk allows one trailing letter and then only a
suffix from a closed set of nine words. All four were valid opkg versions,
which is why nothing had noticed. pkg_version_ok gates every recipe now.
A v3 .apk begins with ADBd magic and is not a tar stream, so there is no apk
equivalent of the `ar -p | gunzip | tar` that hand-unpacked anvil-opkg: you
cannot open a package without a package manager. bin/build-payload.py puts the
cross-built binary on the stick at /mnt/apk instead. It is the same build
anvil-apk-tools contains, that package installs normally, and the bootstrap
copy never lands.
Two gates retired rather than moved. apk's installed database is plain text
(F: sets a directory, R: names a file in it), so the payload-ownership check
reads one file where it used to glob info/*.list. And it carries no clock at
all -- apk records no install time and mkpkg sets no build-time -- so the
Installed-Time normalisation case-build-payload.sh did on every build is gone,
and the test asserts the ABSENCE of a t: line instead. Clock-free by
construction rather than by repair.
Also removed: PKG_SECTION, which 45 recipes declared and nothing read once
apk's schema had no field for it, and the `make apk-host` target -- the
packager is built on demand by bin/build-packages.sh and stamped on the pin,
the way pkg_toolchain and pkg_buildpython already work.
Verified from a cold work/host and work/packages: 47 packages built and signed,
`make build` installs 35 and verifies them against the shipped public key,
`make qa-static` 195 passed, `make qa-replica` 135 passed -- the printer
installing off a simulated USB stick and booting. The installed set was checked
against the declared closure of the eleven roots: 35 expected, 35 installed,
nothing extra and nothing missing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rbKEyLXrzSE6wm3iNApVp
firmwareExe was the only thing that knew the chamber element needed air.
CommMgr::heatManager case 5 fired SET_FAN_SPEED FAN=chamber_heat_fan SPEED=0.9
and chamber_loop_fan SPEED=0.3 immediately before every SET_HEATER_TEMPERATURE
HEATER=chamber_heater, on a bare "target != 0" test evaluated once, at the
instant the target was written -- no state machine, no delay, no run-on, and on
the way down it stopped the fans a moment BEFORE dropping the target. Nothing on
the printer knew about the pairing: set a chamber target from a sliced M141,
from Mainsail or from Moonraker and the element ran with its fans stopped. This
mod replaces that binary, and it added M141/M191, so the coupling had to move
somewhere every client passes through.
chamber_heat_fan becomes a [heater_fan] bound to chamber_heater. That follows
the TARGET rather than the heater pin, which matters: PE13 is a PID output on
Klipper's default 0.1 s pwm_cycle_time, so a fan slaved to the pin would chop at
10 Hz and never reach speed. It also runs below G-code -- a pause, a cancel or a
klippy fault cannot strand a hot element behind a stopped fan -- and
fan.Fan(default_shutdown_speed=1.) drives PD12 to full on an MCU shutdown, the
one case where a macro is already dead. There is no tach on any chamber fan, so
nothing here detects a stall; this is not stall protection and does not claim to
be.
The section had to MOVE out of printer.base.cfg. [heater_fan] resolves its
heater at klippy:ready and lookup_heater() raises on the plain Creator 5, which
has no element -- and a pin may be claimed only once, so the plain model keeps
FlashForge's [fan_generic] and the Pro declares the [heater_fan], in the
per-model chamber/<model>.cfg that already exists for the heater itself.
chamber_loop_fan deliberately does NOT go the same way: HelixScreen publishes it
by object name as the user's aux fan ("aux": "fan_generic chamber_loop_fan"),
and a [heater_fan] is neither that object nor settable, so converting it would
take the aux slider away. It stays a [fan_generic] driven from the
SET_HEATER_TEMPERATURE wrapper -- where the app drove it, except this reaches
every client rather than only the touchscreen. ff-filament drops its
chamber_heat_fan blackout for the same reason it can no longer set it, and
because a filament change over a hot element is the last moment to stop
ventilating it.
SEPARATELY, A BUG THIS FOUND. SET_HEATER_TEMPERATURE is a mux command keyed on
HEATER: _cmd_mux raises "The value 'chamber_heater' is not valid for HEATER" for
a heater that was never registered, and a command error aborts a running print.
The gate in ff-chamber.cfg only blocked TARGET > 0, so TARGET=0 went straight to
the base command and threw -- and M141 S0 is what slicers put in their END
G-code. On a plain Creator 5 a chamber-aware profile ran the whole print and
died at the last line. The file's own header claimed "chamber off behaves
exactly as before"; it did not. The gate now covers every chamber command on a
model without the heater, warning only when a real request is dropped and
staying silent for an off that has nothing to turn off.
bin/unpack.sh's drift guard was already broken and is fixed here, because this
change would otherwise have deepened it. strip() dropped the moved sections'
HEADER lines but left their option lines on the stock side with nothing to match
them, and did not know about [include timelapse.cfg], so it printed "printer.
base.cfg DIFFERS" on every single unpack and had been silently useless. It
compares whole blocks now, and reports a match.
qa/static/test_klipper_config.py is new: there was no config coverage at all,
and test_ipk checks that the chamber configs are PACKAGED, never that they
PARSE. It asserts pin uniqueness, that every macro compiles, and -- the half
that earned its place -- it EXECUTES M141/M191 on both models, because reading
the macro did not show the mux bug and running it did. It reproduces klippy's
real parsers rather than approximating them: Environment('{%','%}','{','}') with
single-brace delimiters, RawConfigParser(inline_comment_prefixes=(';','#')) so a
';' inside a string literal survives as configparser leaves it, and both of
gcode.py's disagreeing parameter parsers -- traditional args_r.split(line.
upper()) for M141, shlex with keys-only uppercasing for the extended form, which
is what makes the macro's |lower load-bearing. Both fixes were mutation-tested:
re-adding the duplicate section and restoring the target > 0 gate each fail the
tests written for them.
qa-static green in the container: 171 passed, 3 skipped, including the ipk
packaging tests and shellcheck. make packages PKG=klipper-config builds clean
and the packaged tree is correct -- heater_fan on the Pro, fan_generic on the
plain model, and printer.base.cfg declaring chamber_heat_fan zero times.
qa-replica has NOT been run: this worktree has no work/ tree, so the lane needs
a full make build. Nothing has yet had the real klippy load this config, which
is the check that matters most here, since the failure mode is a printer that
will not boot klippy after a flash. The heater_temp 50 over-run and the 0.9 fan
speed also still want one real chamber heat-up; no test settles those.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FDJmG2hGGqNEYwc6Hj5P12
test_every_named_extra_imports skips a section whose module is absent --
deliberately, because that is what klippy's load_object does. But it means the
test could go green on a machine where the klippy tree had lost
stepper_resonance_tester, having never asked the question it was written for.
So it now names that module and asserts it actually imported.
Checked in both directions before being trusted. On the baked replica, with the
real shipped tree under qemu: the module imports with numpy present, and with
site-packages/numpy moved aside it raises ModuleNotFoundError at line 1 -- an
ImportError, which is the one load_object does not catch. That is the original
diagnosis reproduced on a machine rather than argued from source.
All three lanes green: qa-static 148, qa-replica 135, mkdocs --strict.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJr2x7aDaY889qwSxbdLt8
how-calibration-works.md is the mechanism page under "For experienced users",
and it already ends with input shaping -- which is exactly the section a reader
would otherwise confuse this with. The touchscreen listed the two next to each
other and they are not the same kind of thing: input shaping changes how moves
are planned, VFA changes the current going into the motor.
NOT docs/calibration.md, which is the XYZ tool offsets procedure and nothing
else, and NOT "Using Reforge": the procedure is console work and needs
SAVE_CONFIG and a macro name to describe at all, which is the line the docs
map draws between the first section and the second.
The section says the three things a reader can act on. That the correction is
applied by the driver rather than by Klipper, so it is live on every move and
is not something printing drifts -- which is why this is the calibration you
are least likely to need. That SAVE_CONFIG is required and is deliberately not
in the macro. And that the commands underneath are FlashForge's: the stock app
ran this from its own flow, so it is not claimed as a gain.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJr2x7aDaY889qwSxbdLt8
extras/stepper_resonance_tester.py opens with a bare `import numpy as np`;
klippy.py:122 walks EVERY config section through a load_object whose
importlib.import_module is not wrapped in except ImportError; printer.base.cfg
includes FlashForge's printer.vibration.cfg, which declares
[stepper_resonance_tester]. Since klippy moved to our own CPython 3.13 that has
not been a printer missing resonance testing. It has been a klippy that never
reaches ready.
So this is not a scientific extra. anvil-klipper depends on anvil-python-numpy
the way it depends on cffi, except that the others mean "klippy imports this"
and this one means "klippy starts". It also gives back SHAPER_CALIBRATE and
TEST_RESONANCES, dead since the same switch, and the VFA calibration behind
STEPPER_RESONANCE_FACTORY_CALIBRATE that docs/notes/44-vfa-calibration.md
traces end to end.
WHAT WAS NOT OBVIOUS, in the order it bit.
numpy 2.x builds with meson-python, and meson has never heard of
_PYTHON_SYSCONFIGDATA_NAME -- the trick every other python-* recipe here leans
on. pkg_mesoncross writes a real cross file instead, naming the $PKG_XW
wrappers rather than the raw toolchain: the wrappers carry -EL -mnan=2008, and
a cross file that reaches past them builds a tree that passes every gate which
only reads symbols and is refused at exec() on the printer. pkg_pywheel grew a
PKG_PY_PIP_ARGS branch to pass the file as --config-settings, which is the one
thing PEP 517 does standardise.
The cross file's `python =` is the BUILD python, and that is not a mistake:
meson introspects an interpreter by running it and asking sysconfig, and
pkg_pytarget has already made that sysconfig answer for mipsel. The old trick
does reach meson, just not by its own mechanism.
numpy's meson.build hard-errors below gcc 8.4 and ours is 7.2. The gate is the
SciPy Toolchain Roadmap's support statement, not a requirement of the code:
this toolchain compiles if constexpr, structured bindings, std::optional,
std::string_view, and pocketfft_hdronly.h -- 3635 lines of the heaviest
template C++ in the tree, and the half np.fft.rfft needs. Probed before the
floor was lowered, and lowered rather than removed, behind a guard that fails
loudly if upstream moves the check. 19 extension modules, every one at e_flags
0x70001405/0x70001407, 14MB shipped after pruning tests/, f2py/, stubs and
static libs.
meson-python is self-hosting, so pkg_buildpython runs meson and ninja just to
install the backend -- hence ninja-build in the image and PYPKG_HOST_LIST in
dependency order rather than alphabetical. And pip puts meson and cython in
work/.py-host/bin, which nothing had ever looked in: without that on PATH the
backend fails to install with `meson executable "meson" not found` while pip
list shows it right there.
THE GATE THAT WOULD HAVE CAUGHT ALL OF IT is qa/replica/test_klippy_extras_import.py:
walk the real /usr/data/config include graph, map every section to its extra,
import each on the printer's own interpreter. It needs no MCU, because config
load happens before klippy:mcu_identify. Nothing asked that question before,
which is how two comments in this repo came to assert the module guarded its
own import. test_numpy.py asks for numeric answers rather than a module object
-- linalg.lstsq specifically, because -Dallow-noblas selects the bundled
lapack_lite and _r2_sinusoidal_fit calls it every calibration round. And
test_install.py's include check read only ff-*.cfg, so FlashForge's four --
printer.vibration.cfg among them -- were never asked about at all.
ff-toolchange.cfg wraps the two search commands in _FF_SHAPER_PREP, as
SHAPER_CALIBRATE already was. STEPPER_RESONANCE_FACTORY_CALIBRATE is
deliberately NOT wrapped: it is a gcode_macro, not a registered command, and
same-named sections merge under RawConfigParser(strict=False) -- a wrapper
would not wrap it, it would BE it, with rename_existing pointing at itself. It
needs none, since its body is two calls to a command that is wrapped. No
SAVE_CONFIG in any macro either; it restarts klippy and stays the operator's.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJr2x7aDaY889qwSxbdLt8
