Oleksandr ShyshatskyiandClaude Opus 5
057a3a11d7
firmwareExe ran $MODDIR/init.d/S* one at a time in the foreground, and that
loop WAS the boot order. Three of the seven were already thin wrappers over a
supervisor that was already running, so what the loop still carried was not
supervision, it was sequencing -- expressed as filenames, in a directory
nothing but the loop read.
This ships s6-rc and moves the sequencing into a database compiled at build
time. firmwareExe now starts the scanner as its own child, initialises s6-rc,
asks for one machine state, and blocks on `wait "$SCANNER_PID"`.
WHAT THE GRAPH ACTUALLY SAYS
mcu-bringup -> klipper -> ff-startup -> ui
^
moonraker
ok-all = wifi nginx moonraker camera klipper ff-startup ui
Those are the first real edges the plan has ever had; it predicted they would
not arrive until phase 7. bin/ff-startup.py became two services, which is what
made them possible: the MCU bring-up has to precede klipper and the readiness
wait has to follow it, and both facts now live where a program can read them.
Deliberately still absent: nginx before moonraker. S60nginx's header wants it,
but dependencies.d/nginx under moonraker means `s6-rc -d change nginx` stops
moonraker too -- the exact failure splitting S60web into two scripts prevented.
The cost of not writing it is a second where a reloading browser gets a refused
connection instead of a 502.
AND WHAT THEY DO NOT SAY. klipper has no notification-fd, so s6-rc calls it up
when it is forked, not when klippy is usable. ff-startup keeps its own poll of
moonraker's API. moonraker and camera DO carry one, so their readiness is real.
The asymmetry is written down at each site rather than glossed.
init.d/ IS DELETED, REVERSING PHASE 4
Phase 4 promised the S* scripts would survive as thin wrappers, because
`S60nginx restart` is in people's hands. They did not survive, and the reason
is the argument nginx/run already made: a service that only works when a shell
script happened to run first is not supervised, it is lucky. Every prerequisite
a wrapper did belongs in the run script anyway, because s6 restarts a service
without going near a shell. Once they moved, the wrappers were verb translation
in a directory whose S<NN> numbers meant nothing. s6-rc is the interface now.
anvil-service.sh goes with them -- 625 lines whose last caller was firmwareExe,
and a shared library for one consumer is the redundancy the wrappers were.
So do the fallbacks. S60nginx and S62moonraker each carried a second,
unsupervised implementation reachable only via MOD_S6=0; that switch is gone,
and with it the argument for a code path exercised only on broken printers. The
cost is stated plainly in anvil.conf: a printer whose s6 fails now has nothing.
klipperDaemon is replaced with a no-op `start`. It is FlashForge's script and
off-repo callers remain -- stock start.sh, the UI's restart path, habits over
ssh -- and each of them would fork a second klippy beside the supervised one.
WHAT SUPERVISES THE SUPERVISOR, ANSWERED
Phase 3 left this open and guessed a dead scanner was a dead printer either
way. It is not. firmwareExe's tail used to be `while true; do sleep 3600; done`
purely to satisfy app_startup.sh's watchdog, which greps ps for our name 5s in.
It waits on the scanner instead, so exiting IS the recovery: app_startup.sh --
FlashForge's own init, which we never patch -- re-execs us and the tree comes
back. Not a respawn loop in ash, which phase 3 rightly refused. It restarts
everything rather than the scanner alone, and that is written down.
MEASURED, NOT READ OFF THE MANUAL
Host- and target-compiled databases are byte-identical (db md5
80f5261437191fa591744ada6087c6f7 both ways), so the database is built here and
shipped. /run is tmpfs and writable, so the live directory needs no fallback.
Both were BLOCKING UNKNOWNs in the note and are now settled sections.
Three traps the replica found that reading could not:
* s6-svscan resolves s6-supervise through PATH. Without $MODDIR/bin on it the
scanner answers s6-svscanctl -a perfectly and then fails every spawn with
ENOENT for ever, and s6-rc-init HANGS rather than failing.
* s6-rc-init creates one symlink per service in the scandir and dies with
"File exists" if the name is taken. So the cutover is not additive, and
run-append.sh sweeps.
* s6-rc-compile does not reject a `down` file. It accepts it and SILENTLY
DROPS it -- the servicedir is byte-identical. "Down by default" can only
mean absent from the bundle, which is why mcu-bringup is the one service
outside ok-all and arrives as klipper's dependency.
execline turned out not to be optional: s6-rc GENERATES two servicedirs whose
run scripts are execline, and every oneshot's `up` goes through one of them.
The binary list was read off a real compile, not guessed -- seven execline
binaries of 53, plus six s6 ones we built and did not ship.
Two build bugs fell out. fetch-assets.sh compared against a stamp patch.sh
never wrote, so every build pulled the ~100MB toolchain the skip exists to
avoid; S6_STAMP is one string in common.sh now. And `chmod +x .../bin/s6-*`
would have missed all seven execline binaries.
qa: 83 static. The suite gained the s6-rc run scripts and klipperDaemon, which
no glob had ever covered, and lost a dead payload/init.d/S* glob -- exactly the
silently-retired check that file's own docstring warns about. The oneshots'
up/down are NOT in it: they are execline carrying shell inside a /bin/sh -c
argument, so both checkers would parse the wrapper and pass.
Not verified here: no config.env and no stock package on this machine, so the
mipsel cross-build of execline/s6-rc and the ABI gate over 33 binaries have
never run. The native compile and the database are proven; that half is not.
The replica gate is the next commit, and it still owes an answer on whether
helix-screen runs under s6-supervise at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 If something goes wrong
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)
Have the stock package for your model on a spare stick before you begin.
How the mod hooks in — one file, firmwareExe, with the stock boot scripts,
updater and recovery path left untouched — is
docs/how-it-works.md.
What you give up
That one file is FlashForge's whole application, so anything that lived inside
it rather than in a separate service goes with it: the FlashForge network
API on :8898, and with it FlashPrint, Orca's FlashForge profile and the
mobile app. Moonraker's API takes over — upload from OrcaSlicer or Mainsail
instead. Flashing the stock package brings the API back.
Which file do I need
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" — so pick the file whose name matches your machine on the Releases page:
| Your printer | The file |
|---|---|
| Creator 5 | Creator5-anvil-<date>.tgz |
| Creator 5 Pro | Creator5Pro-anvil-<date>.tgz |
Not sure which you have? On the printer: Settings → About.
How to flash
Before you start
- Put the stock FlashForge package for your model on a second stick. That stick is the undo button — see If something goes wrong.
- Read docs/hardware-testing.md first: the go/no-go checks after the flash, in order, and what means stop.
The flash
- Format a USB stick as FAT32. Not exFAT, not NTFS.
- Copy the file for your model to the root of the stick. Not in a folder. Leave the name exactly as it is — the printer looks for that pattern.
- Power the printer off.
- Plug the stick in and power the printer on. It finds the package by itself, shows the update screen and installs. This takes a few minutes.
- Wait for it to reboot on its own, then pull the stick — your root
password is on it, in
anvil-password.txt.
After the flash
Everything is on the printer's own address:
http://<printer-ip>/ |
Mainsail |
http://<printer-ip>:7125 |
Moonraker's API — what slicers upload to |
http://<printer-ip>/webcam/ |
the camera stream (mjpg-streamer on :8080) |
ssh root@<printer-ip> |
the shell — password from anvil-password.txt |
Logs worth reading, all on the data partition and all surviving a reboot:
/usr/data/anvil-install.log what the installer did
/usr/data/logs/anvil-boot.log services + UI choice at each boot
/usr/data/logs/printer.log klipper
/usr/data/logs/helixscreen.log helixscreen
Then run the go/no-go checks in docs/hardware-testing.md, in order, with the emergency stop within reach.
Before your first print: calibrate
Prints refuse to start on an uncalibrated toolchanger — by design. The sequence is short, and the first part happens without you.
-
Your unit's factory calibration imports and saves itself on the first boot (Klipper restarts once, before the screen is up).
-
Take the PEI sheet off — the calibration station sits below the bed plane — then home and calibrate:
G28 CALIBRATE_TOOL_OFFSETS SAVE_CONFIGStep by step, with every message it can refuse with: docs/calibration.md.
-
TOOLCHANGE_STATUSandTOOL_OFFSET_STATUS— every tool should show a nozzle triple and a dock position, nothing should sayNOT CALIBRATED. Then check the Z offset against a sheet of paper before trusting a first layer — Verify shows the exact moves. If the nozzle presses into the plate, stop.
The full procedure is docs/toolchange.md. Two files
under gcode/ are there for the first runs:
creator5-safe-moves.gcode (cold, nothing below Z50), then
creator5-feature-test.gcode (the real thing, two tools).
Slicer setup
OrcaSlicer, with the stock FlashForge profile left alone. The one field to
touch is Change filament G-code: clear it down to a bare Tn — the
toolchanger takes it from there. Upload through Orca's Klipper/Moonraker
target or drop the file into Mainsail. Details:
docs/toolchange.md.
Your files and the mod's files
| File | Whose |
|---|---|
/usr/data/config/printer.cfg |
Yours — never overwritten. Overrides go here, after the includes: restate only what you change, the last value wins. |
moonraker-custom.conf |
Yours — created once, never rewritten, included last so your settings win. Do not delete it. |
ff-*.cfg, printer.base.cfg, moonraker.conf |
The mod's — overwritten on every update; do not edit. |
anvil/helixscreen/config/settings.json |
Yours — everything you set on the screen. Written by HelixScreen itself; carried across updates along with helixscreen.env and its spool map. |
Upgrading
A newer release installs exactly like the first flash: stick in, power on.
Your printer.cfg with its saved calibration, moonraker-custom.conf, your
root password and everything you set on the screen survive; the ff-*.cfg
family is replaced. If a release changes helixscreen.env, yours is kept and
the new one is left beside it as helixscreen.env.mod-new.
If something goes wrong
Flash the stock FlashForge package for your model. It restores everything it carries and installs the same way — stick in, power on. Keep one on a spare stick before you start; the stock packages are published at ghzserg/FF.
The one thing it cannot bring back is FlashForge's Moonraker: the stock package does not carry it, so the mod's build stays — it works, and Mainsail is happy with it (details). The symptom table, the logs worth reading, and the factory-restore last resort are in docs/hardware-testing.md — and there are people to ask on the Discord.
Versions
| Component | Pinned at |
|---|---|
| Stock FlashForge base | 1.9.7-1.2.9-20260810, fetched from ghzserg/FF at build time |
| Klipper | a current fork (branch creator5) with the ff_* toolchanger extras |
| Mainsail | v2.18.2 |
| Moonraker | commit 9d0d09d — a commit, not a release, for a hard reason: docs/how-it-works.md |
| HelixScreen | v0.99.115-creator5.1 |
Documentation
| docs/hardware-testing.md | The on-hardware procedure, with the checks that say go or stop |
| docs/how-it-works.md | How the mod hooks into the stock firmware, and what the stock firmware does that surprises people |
| docs/toolchange.md | The toolchanger mod: the ff_* Klipper extras, the ff-*.cfg configs, and the Z offsets to get right before you print |
| docs/calibration.md | XYZ tool calibration from the operator's side: the order of commands, what each prints, and what every error means |
| docs/notes/70-error-codes.md | Every error code the firmware can raise, by subsystem |
| docs/building.md | Building your own packages from a stock FlashForge one |
| docs/testing.md | The test suite, and how we know a package does not brick a printer |
| docs/printer-replica.md | The printer replica: what is authentic, what is not |
| docs/notes/ | Reverse-engineering notes on the stock firmware, behind the toolchanger work |
| gcode/ | The two verification files for the first runs on hardware |
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.