Oleksandr ShyshatskyiandClaude Opus 5
6dc89469ac
Two gates go, both of the same shape: a pkg_die run against $PAYLOAD_DIR a few
lines after bin/build-payload.py filled it, asking whether opkg had installed
the packages it was handed.
* section 1: a klippy tree at $MODDIR/klipper/klippy, and a c_helper.so
inside it
* section 5b-2: etc/s6-rc/compiled/current resolving
Neither was ever this script's question. patch.sh no longer builds either
subject -- anvil-klipper installs the klippy tree, and case-build-payload.sh
compiles the database in the replica with the s6-rc-compile anvil-s6-rc ships
-- so a gate here can only report that a package manager did what it said it
did, on a staging directory, on the build host.
Both are already asked on the two vehicles that actually reach a printer:
* bin/verify.sh reads the PACKED artefact -- the klippy tree, c_helper.so,
and compiled/current resolving, plus the one thing about the database a
host can genuinely tell that patch.sh never asked: the execline named by
the oneshot runner's #!.
* qa/replica asks an INSTALLED filesystem. test_install.py's
test_klippy_is_present is the klippy question by name, test_abi.py sweeps
c_helper.so for the ABI, and test_s6rc.py boots the thing -- s6-rc-init
reads the database, the boot set comes up, and a database moved aside is
reported as a negative control.
The two `say` lines went with them. Both existed to narrate a gate; the
Klipper one printed a pin that pkgs/klipper/pkg.conf already stamps into
PKG_VERSION, and the s6-rc one readlink'd the path the gate had just tested.
KEPT, and it is the same call 4ce928f made for the toolchain wrapper: the
anvil-core check in section 0. It judges the INPUT feed rather than the
produced payload, which is a question no downstream gate can ask, and it
guards a silent failure -- the MOD_INSTALL loop drops a root with no .ipk
without a word, because that is how PKG_WHEN reaches this script, so a missing
anvil-core would otherwise build a payload without it rather than stop.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GAQKdBfZxbnPagQyidFk6Y
Reforge
Custom firmware for the FlashForge Creator 5 and Creator 5 Pro.
It installs the way a normal FlashForge update does: copy one file to a USB stick, plug it in, power the printer on. No jailbreak, no soldering, no opening the case, no ssh needed to get started — the printer's own updater does the work.
Packages are published on the Releases page — two files per release, one per model, marked pre-release while the mod is young. Help and support: the Discord.
Unofficial and unaffiliated with FlashForge. It voids your warranty and you are responsible for your machine. See Status for what has actually been tried on hardware before you flash anything.
Status
It runs on a real printer — a Creator 5 Pro, flashed and printing:
A checked box happened on that machine; an empty one has not, yet.
For everyone:
- Install and migration from stock firmware — the printer's own updater does it; your unit's factory calibration imports itself on the first boot
- Printing — gcode straight from the slicer, nothing edited
- Toolchanges — a current Klipper with real toolchanger support, in place of the 0.12-era tree FlashForge ships
- Nozzle-offset calibration
- Mainsail at
http://<printer-ip>/, with a current Moonraker behind it — anything that speaks the Klipper API works - Camera — mjpg-streamer, already on the printer; the mod just starts it
- Wifi
- HelixScreen on the printer's own screen
- Chamber heater
- Creator 5 (non-Pro) — its package builds and passes the same replica test suite, but has not touched hardware
- Going back to stock — proven on the printer replica, not yet needed on the machine. The stock package restores everything it carries; Moonraker is not in it, so the mod's build stays and keeps working — see Support
For the tinkerer:
- ssh as root — a random password is chosen on the first install
and written to
anvil-password.txton your stick; updates keep it (make passwdbakes in your own)
What you give up
FlashForge's application is one binary, and replacing it takes everything
that lived inside it: the network API on :8898, and with it FlashPrint,
Orca's FlashForge profile and the mobile app. Moonraker's API takes over.
Flashing the stock package brings them back.
If your prints already come out the way you want and you like the printer's own screen, this mod is not for you. It trades FlashForge's polish for Klipper's reach, and it expects you to be comfortable with a Klipper config and an ssh session when something breaks — Is this for you is the honest version of that question.
Get it
Creator 5 and Creator 5 Pro are not interchangeable. The printer refuses a package built for the other model — the most common reason a flash "does nothing". Yours is in Settings → About.
| Your printer | The file on the Releases page |
|---|---|
| Creator 5 | Creator5-anvil-<date>.tgz |
| Creator 5 Pro | Creator5Pro-anvil-<date>.tgz |
Download the stock FlashForge package for your model before you begin. It is the undo button: flashing it back puts the printer as it was.
Start here
| Is this for you | Who should flash this, who should stay on stock, and what it asks of you |
| Installing | The flash, the first boot, your root password |
| Your first print | The go/no-go checks, calibration, and the two verification files |
| Support | The logs, and the way back to stock |
The full manual is at
reforge.readthedocs.io. If you want the
insides — one file, firmwareExe, with the stock boot scripts, updater and
recovery path left untouched — How it works is under
For contributors.
Credits
Built on the work of others: ghzserg/FF publishes the stock packages and factory image everything here starts from; Mainsail, Moonraker and HelixScreen are shipped as released; the toolchanger status API follows viesturz/klipper-toolchanger so tool-aware UIs work unchanged.