FarmBoard 3 universal firmware (bench test)

Internal bench-test build

This build compiles and passes offline checks but has never moved a real actuator. It is here so it can be flashed for bench testing. Do not use it on a customer unit and do not share this URL.

What this is

One FarmBoard 3 image for both kits, and from rev4 it works out which kit it is on by itself.

At every power-on the board drives the fan port briefly, in both directions, and measures the current:

What it reads	Verdict	What the board does
An actuator (both directions draw, roughly 0.002-0.020 A)	H series	selects the H kit
A fan (draws one way only, above 0.050 A)	not H	selects the P/X kit
Nothing (both directions under 0.002 A)	not H	selects the P/X kit
Anything else	unsure	changes nothing

A fan conducts one way and an actuator conducts both, which is what separates them; the two cases were about 28x apart on the bench board.

The measurement only tells H from not-H. So a not-H reading is allowed to move an H board onto the P/X kit, but it is never allowed to overwrite another not-H model. That protects a Snapmaker or Elegoo selection, where the bender mount is reversed, from being silently moved onto Bambu.

Setting the Printer Model by hand wins and sticks. The moment you pick a model on the config page, that choice is locked and detection will not change it again on any later boot. Clearing the printer config hands control back to automatic. If a locked model disagrees with what the port reads, the board warns on the serial log and still runs - the override is meant to win.

The kit decides real behaviour: the H kit drives two alternating benders (Bender 2 on the fan channel, polarity reversed) with H stroke timings and no fan; the P/X kit drives one bender plus the fan.

rev4 also carries the door-open safety fix: T1 now always drives the door open instead of trusting a remembered flag, and T2 opens the door first unless a door-open travel actually completed this cycle.

rev5: PrusaLink username and password

Current Buddy firmware shows a username and a password on the printer under Settings → Network → PrusaLink, and no “API key” at all, so there was nothing to put in the old API-key-only field.

rev5 asks for both, with the username defaulting to maker as the printer shows it. The board works out which login the printer wants:

1. It sends the password as an X-Api-Key header. That is the path verified on a real CORE One on 2026-08-10, and it costs one round trip.
2. Only if that comes back 401 with a Digest challenge does it do proper HTTP Digest with the username and password, and retry once.
3. The challenge is then cached, so from the second poll onwards Digest goes out up front and polling stays at one round trip. A stale challenge is renewed automatically.

If your printer shows a single API key rather than a username and password, leave the username as maker and put the key in the password box.

Boards already configured with a working API key migrate silently: the password reuses the same stored value, and the username defaults to maker. No action needed on an existing unit.

The image grew 5,472 bytes for this, to 62% of the slot.

rev6: test the connection before saving it

Test printer connection now tests the values currently on the page instead of the stored ones. Previously it answered “save the printer settings first” even when the page was full of good values, which forced save, test, correct, save again. That was worst on PrusaLink, where the username and password are copied by hand off the printer’s screen and are exactly what you want to try before committing.

Nothing you type reaches storage until you press Save. The values are used for the duration of the test and then put back, so a failed test cannot leave the board pointing at the wrong printer, and the board reconnects to its real printer afterwards.

Every test result now ends with a reminder that nothing was saved. An incomplete form is told what that particular printer still needs. And a Prusa success says which login worked, which is the quickest way to see whether the new Digest path ran or the simple API-key form was accepted.

Feature base is the P/X 2.95-beta line, so the board page over your normal WiFi is switched off in this build; use config mode (five taps on SW2, join the FarmLoop network).

This build uses the new FB3 partition layout (1.9 MB app slots) and fills 1225632 bytes of it, 62%. It is meant for boards flashed over USB-C, which writes the new layout. An existing FB3 board can also take the OTA file while the image fits its old slot.

rev7: no more mode flip in the middle of a print

On a Prusa, Snapmaker or Elegoo the board deliberately stops polling the printer while an actuator is moving. That was fine for a door travel, but a five cycle bend is an unbroken chain of bender travels lasting about 90 seconds, which is three times the 30 second window the board uses to decide the printer has gone quiet.

The board therefore decided mid-print that the link was dead, and handed the triggers back to Mechanical mode while the print was still running. On a G-code file that still carries the old mechanical Z-taps alongside the M104 markers, the safety check and the final door close then fired twice, once from the marker and once from the tap.

rev7 holds the liveness clock for as long as the board is choosing not to poll. A real WiFi drop is still caught immediately, and a printer that has genuinely gone quiet is still caught on the first polls after the movement ends. Bambu was never affected, because its connection is push-based and never had this guard.

rev9: the board page, reworked

Same firmware underneath as rev7. The setup page is now built around the two things every customer has to decide, in this order:

1. Your printer, first, with its own Save. Needed in both trigger modes, because it decides the kit and the bender direction.
2. Status in plain words: “Waiting for a print”, “Bending”, “Safety check”, and the trigger mode currently active.
3. Trigger mode: a Mechanical / Digital choice, with what each means and why Digital is recommended. Only choosing Digital reveals the WiFi and printer login steps, the test buttons and the LED legend. A Mechanical customer sees a two-screen page and never meets a credential field.
4. Firmware, one card: check for updates, file upload folded underneath.
5. Diagnostics, then This board.
6. Advanced, collapsed: manual control, live log, tuning.

The printer model save goes through the same path as before, so the kit lock and the door-travel default still follow it. LAN access code and PrusaLink password are masked with a show button.

Nothing changed in how the board behaves. If rev9 misbehaves on a print, drop to rev7: the page is the only difference.

rev10: Elegoo Centauri Carbon opens the door again

A captured print on the CC showed the door closing at the start and never opening. The cause was a guard added in the 2.95 line: marker values were only believed while the printer reported “printing” (SDCP status 18). The CC emits the start marker before it reaches that status and runs the whole FarmLoop end section in status 1 or 16, so every marker was being ignored. The door only closed at all because of a fallback that fires on “printing” starting.

rev10 believes the markers while a job is active in status 18, 1, 16 or 9, and ignores them only in the three transitional states (6, 20, 21) where the CC’s pause/stop path is known to replay an old marker. A genuine pause writes a real temperature, not a marker value, so it cannot fire anything.

Two log lines that misled the diagnosis are also fixed: the boot log now names the real transport instead of “PrusaLink polling” on every non-Bambu printer, and an Elegoo no longer reports “API key: MISSING” when it has no authentication at all.

The G-code keeps its mechanical Z-taps on purpose, as the Mechanical-mode fallback. They are ignored while Digital owns the switch; the capture shows thirteen of them ignored correctly in one print.

rev11: the release-review fixes

Four things H 3.1 did that the universal build had lost, all put back:

1. Reconnect back-off. After three failed connects the board tries once a minute instead of every five seconds, so a board that cannot reach its printer (guest WiFi, wrong IP) keeps its buttons responsive.
2. Test mode drives Bender 2 on the H kit: Bender 1, then Bender 2, then the door, as the H2 assembly page says. No fan wait on the H kit.
3. Door-blocked threshold follows the kit: 0.15 A on H, 0.12 A on P/X, swapped only while still at the other kit’s default, never over a value you tuned by hand.
4. A bend is refused while the kit is unsure and nobody has ever set the model. That is the one state where the P/X default is inherited rather than measured, and on an H kit it would drive Bender 2 as a fan at T1. The Status card says “Set the printer model first”. Any confident detection or any manual save ends it; a manual choice still always wins.

Policy, now written down: tuning is not wiped on a version change. A board upgrading from H 3.1 keeps its 10 s door travel and 0.15 A threshold.

rev12: the LED legend and the Bambu test in setup mode

Two things from the P2S bench run on 2026-09-07:

1. The LED legend is complete. The board page and the serial help listed only the boot codes. They now also say what the LED means while running: an even blink once a second is Digital mode with the printer connected and sending data, two flashes then a pause is Digital mode with no printer data (on Bambu almost always the serial number), off is Mechanical mode, and a fast flicker is setup mode. The legend also mentions the single longer blink after the three boot blinks, so “4 blinks” is not read as a failed printer connection.
2. “Test printer connection” for a Bambu in setup mode says why it cannot run. Bambu is the only transport with a TLS handshake, and that needs one contiguous block of roughly 35 to 40 KB. With the setup access point, captive portal and web server up the largest free block is about 17 KB (heap free 27304, largest block 17396 ... Failed, rc=-2), so the test failed before reaching the printer and reported a connection failure for settings that worked on the next boot. The board now checks the largest free block first and, when it is too small, tells the user to save and reboot, which LED pattern confirms the link, and that the next setup page shows the pre-setup link state. Prusa, Snapmaker and Elegoo keep the live test.

rev13: the MQTT starvation fix, watchdog brackets, door-blocked detection opt-in

Bench-diagnosed by a second session on an H2S that received 3% of the printer’s stream while reporting “connected”, then reviewed here before merge (PR #56).

1. MQTT receive buffer 32 KB to 24 KB. The buffer is allocated once at boot, so its size never decides whether a packet fits. It decides how much heap is left for the layers that allocate per packet, the TLS record buffers and the network stack’s segment buffers. With 32 KB plus the 32 KB parse copy, the running heap had a 34 KB largest block and segment allocation failed under the H2S’s 18 KB/s stream. Measured over 62 minutes: 116 packets with 32 KB, 3571 with 24 KB, reconnects 15 to 0. This is the fault behind the reconnect loop in the 2026-09-07 H2S log; the printer and the network were ruled out with a laptop client on the same broker.
2. Watchdog brackets on the synchronous TLS calls, the same treatment the connect handshake already had. A blocked loop() or publish() no longer reboots the board.
3. Door-blocked detection is opt-in, off by default, 0.20 A when on. Normal unobstructed door current measured 0.146 to 0.174 A across three machines; the old 0.12 A and 0.15 A defaults sat inside that band and one of them cancelled a live print. A stored 0.12 or 0.15 is lifted to 0.20 once; any other stored value is left alone. The checkbox sits on the Trigger mode card and is the only place the threshold is set.
4. With detection off the safety step is skipped outright. M104 S4 and the mechanical safety gestures go straight to “ready for T3” with no door movement and a log line saying why. With detection on, the check runs as before at 0.20 A.
5. A door block no longer retracts the bender, and bend2Stop() runs at init completion on the H kit, which rev4 through rev12 had missed.

Not yet on hardware: the safety skip, the 0.20 A threshold and the single control were added in review after the bench soak. Steps 21 and 22 cover them.

Bench test checklist

Detection, before anything else

0. The page itself. Enter setup mode and open the page on a phone. The printer selector should be the first thing you see, then Status, then the Mechanical / Digital choice. Change the printer model, press its Save, and confirm the serial log prints [KIT] Printer model set by hand. Pick Mechanical: the credential fields must disappear. Pick Digital: they must come back with your saved values. Open Advanced and check the actuator buttons still work.
1. USB-C flash the merged image below with nothing on the fan port. Watch the serial log at boot: it should read nothing and select the P/X kit.
2. Power off, plug a fan into the fan port, power on. Should read fan, still P/X.
3. Power off, plug the 75 mm actuator in, power on. Should read actuator and switch itself to the H kit.
4. Serial kitdetect re-runs the measurement on demand and prints both readings, so you can check a port without rebooting.
5. Set the Printer Model by hand on the config page, then power-cycle with the wrong thing on the fan port. The model must not move, and the log must carry the mismatch warning.
6. Clear the printer config and power-cycle: detection should take over again.

Then the kit behaviour

7. H kit: B1 and B2 alternate with the handover overlap, both park home after reset, and bend2 out / bend2 in / bend2 stop drive B2 directly. Fan buttons must do nothing.
8. P/X kit: the fan runs on the H-bridge channel and B2 controls are absent from the page.
9. One full cycle per kit, mechanical and Digital.

Then Digital mode against each printer

10. Bambu (MQTT), Prusa (PrusaLink), Snapmaker U1 (Moonraker), Elegoo CC (SDCP): connect, confirm live data, run one FarmLoop print. On the Snapmaker and the Elegoo also confirm the bender still goes the reversed way, since detection is what could have moved that.
11. Prusa login, the new code path. Type the username and password from the printer’s PrusaLink screen and press Test printer connection without saving anything first - that is the rev6 behaviour and the quickest way to check you transcribed them correctly. The reply names the login that worked: “logged in with the password as an API key” means the simple form was accepted, “logged in with username and password” means the new Digest path ran. The Digest path has never run against hardware, so this is the step worth doing carefully. Then deliberately test a wrong password and confirm the board says the credentials were rejected rather than that the printer is unreachable. Only save once the test passes.
12. Door check on every one of them: the T1 line in the log must be followed by [P1] Door opening: lines. A T1 with none of them is the defect rev4 fixes and means something went wrong.
13. Run one full Digital print on a Prusa, Snapmaker or Elegoo with the log running, and watch across the bending. This is the rev7 fix. Bending takes about 90 seconds and the board is not polling for any of it. There must be no liveness warning and no fall back to Mechanical mode during that stretch, and the safety check and final door close must each happen exactly once. If either happens twice, the board flipped mode and the G-code’s own Z-taps fired as well.
14. Elegoo, the rev10 fix. One full Digital print on the Centauri Carbon with the log open. The door must open at T1 and the log must show marker edges (T1, T2, safety, T3) firing, not RUNNING fallback lines. If T0 still says (RUNNING fallback) the start marker is still not being seen; send the log.
15. Elegoo pause, resume, stop. During a Digital print: pause on the printer, wait, resume, then stop it, and keep the log running until the printer is back at idle. The door must not move on the resume or the stop, and the log must not show a marker edge during them. This is the one replay case the fix could not be checked against, because the original capture ended before the printer finished stopping.
16. Unreachable printer. Set a wrong printer IP, save, reboot, and press the buttons over the next two minutes. After the first three attempts (about 15 s) the log must say it is retrying once a minute, and the buttons must respond in between. Fix the IP: Digital must resume by itself.
17. Test mode on the H kit. Long-press the door button with the H model set. Bender 1 must move first, then Bender 2 out and back, then the door. With a P/X model set, the fan runs first and Bender 2 never moves.
18. Threshold follows the kit. Clear the printer config, power on with the 75 mm actuator on the fan port, and read the Configuration line in the log: door threshold 0.15 A. Set Bambu P/X by hand: it must go back to 0.12 A. Then type a value of your own, switch the model again, and confirm your value is left alone.
19. The refusal. Clear the printer config, power on with nothing on the fan port but with Bender 1 disconnected too, or with a fan on a shaky connector, so detection reads unsure. Trigger T2. The log must say the bend was refused and the Status card must say “Set the printer model first”. Save any model on the page: the refusal must clear.
20. Bambu test in setup mode. Enter setup mode, test WiFi, enter the P2S details and press Test printer connection. The message must start with “NOT TESTED” and explain the reboot, not “FAILED”. The log prints [MQTT] Test skipped in setup mode: largest free block. Save, reboot, and watch for 10 fast blinks, then the even 1 Hz blink. Enter setup mode again: the Status card must show the printer link as connected with the board IP. Repeat the test on the Prusa: it must still run live.
21. Safety skip, rev13. Detection off (the default after upgrade). Run a Digital cycle: between the last bend and the final close the log must show SAFETY CHECK SKIPPED - door blocked detection is off and the door must not move. Then tick Door blocked detection on the Trigger mode card, leave 0.20 A, save, and run the same cycle: the door must close and open for the check and pass. Check status on serial prints Door Blocked Detect: ON (threshold 0.20A). On the H2S, also block the door by hand during that check: it must reverse, fail, and send STOP.
22. First pushall on an AMS-heavy machine. On the H2C with every AMS unit attached, power cycle the board and watch the first ten seconds of the log for [MQTT RX MAX]. Anything above 24,000 bytes or a TRUNCATED line means the first report does not fit the new buffer, and a board that connects mid-print would never learn the file name. Repeat on the P2S with its AMS as the second data point.

Files

Download OTA .bin (existing FB3 boards)

⚡ USB-C flash rev13 (writes new partition layout)USB-C flash (Chrome / Edge only)USB-C flash needs HTTPS

sha256: merged f6a0fe44…, OTA e07e1b63…

Earlier revisions

• rev12 - LED legend and the Bambu setup-mode test, but with the 32 KB MQTT buffer that starves the H2S link. OTA · merged
• rev11 - the release-review fixes, but the LED legend stops at the boot codes and a Bambu connection test in setup mode fails on memory. OTA · merged
• rev10 - Elegoo markers unfrozen, before the release-review fixes (no reconnect back-off, no Bender 2 in test mode, P/X threshold on H kits). OTA · merged
• rev9 - the reworked page, but with the Elegoo markers still frozen: the CC’s door does not open in Digital mode on this one. OTA · merged
• rev8 - first page rework, setup form on top. Superseded the same day by rev9’s printer-first order and the Mechanical / Digital fork; hosted, never published here. OTA · merged
• rev7 - same firmware, the old page layout. OTA · merged
• rev6 - test before save, but a five cycle bend could still flip the board out of Digital mode mid-print on a polled transport. OTA · merged
• rev5 - PrusaLink username and password, but the connection test still needed the settings saved first. OTA · merged
• rev4 - kit auto-detection, without the PrusaLink username and password. OTA · merged
• rev3 - same detection, but advisory only: it recorded the verdict and blocked a bending cycle on a mismatch instead of setting the kit. OTA · merged
• rev2 - door fix only, no detection at all; the Printer Model decides the kit. OTA · merged
• v1.0-beta - the original merge of the two firmwares. OTA · merged

Rolling a bench board back

USB-C flash any FB3 build from the Beta firmware page (FarmBoard 3 tab). That rewrites the partition table back as part of the full image, so switching between this build and the older ones over USB-C is always safe in both directions.