FINISH fix test builds (2.94.3 and FB3-U 1.0.1)

Internal bench-test builds

These compile and pass CI but have never moved a real actuator. They are here so they can be flashed for bench testing. Do not put them on a customer unit and do not share this URL.

What these are

Two builds, one change, nothing else:

• FL_S2_FB2_XP_2.94.3 - stable 2.94.2 plus the fix. FarmBoard 2, X/P kit.
• FL_S2_FB3_U_1.0.1 - stable FarmLoop 1.0 plus the fix. FarmBoard 3, either kit.

Same triggers, same timings, same safety behaviour, same pin assignments. Neither is a beta and neither carries any beta feature.

The problem they fix

The markers that drive the cycle live in the end g-code. M104 S2 opens the door, M104 S3 runs the bender, M104 S5 closes the door again.

The board only listened for those markers while the printer reported the job as active: preparing, running or paused. The moment the printer reported it finished, the board disarmed, and nothing could re-arm it until the next job started.

With SimplyPrint the job is reported finished before the remaining markers arrive. So the board stopped listening first and the markers landed on deaf ears. The cycle halted wherever it had got to, in practice with the door still shut, and the limit switch could not take over either, because the manual gestures are suppressed while the printer link is alive.

What changed

The board now stays armed when the printer reports the job finished. Cancelled and idle still disarm it exactly as before.

On the FarmBoard 3 build this covers every printer brand at once, not just Bambu. Prusa, Snapmaker and Elegoo all report a finished print through the same internal state, so all four were affected in the same way and all four are fixed together.

What is deliberately still open

Two side effects were left in on purpose and will be handled separately. Worth knowing while testing so they are not reported as new faults:

1. Older, marker-less end g-code loses its two automatic fallbacks from the second print onward. Anything written with the M104 markers is unaffected, which is every FarmLoop job the app generates.
2. The board keeps treating later jobs as FarmLoop jobs once it has seen a FarmLoop job since power-on.

How to test

1. Flash the build that matches the board. Confirm the banner shows 2.94.3 or 1.0.1 on the setup page.
2. Run a normal FarmLoop print through SimplyPrint, end to end.
3. Watch the serial log at the end of the print. The line to look for is that the board does not print [FL_S2] Disarmed (state=FINISH…). It should stay armed, then act on the remaining markers.
4. Confirm the physical sequence completes: fan on, door opens, bender runs, door closes.
5. Run a second print immediately after, without power cycling, and confirm the whole cycle runs again.
6. Then cancel a print part way through. The board must still disarm and reset cleanly on a cancel, which is unchanged behaviour.

Files

FarmBoard 2, X/P kit — 2.94.3

Download OTA .bin

⚡ USB-C flash 2.94.3USB-C flash (Chrome / Edge only)USB-C flash needs HTTPS

sha256: merged 6380dfc4…, OTA 152bd8b1… · app image 1,133,920 bytes

FarmBoard 3, either kit — 1.0.1

Download OTA .bin

⚡ USB-C flash 1.0.1USB-C flash (Chrome / Edge only)USB-C flash needs HTTPS

sha256: merged de0d8139…, OTA da370cfb… · app image 1,232,832 bytes

Both app images are exactly 16 bytes larger than the stable builds they came from, which is the one extra comparison and branch and nothing else.

Rollback

Flash the stable build for that board from the Firmware page: 2.94 for FarmBoard 2 X/P, FarmLoop 1.0 for FarmBoard 3.