Heads-up: 'Ready to Cut' (state 7 / Idle) won't catch belt-position drift — check $MINFO before you cut

Sharing a gotcha from a long cutting session this week in case it saves someone a faulted cut. Maslow 4, FluidNC v1.15, cutting 2" foam.

Short version: the controller can report State 7 (Ready To Cut) with GRBL Idle — web UI all green, everything looks ready — while a belt is actually ~15 mm out of position. State 7 only means the belts are tensioned, not that they’re where the kinematics think they are.

How it bit me: after loading a fresh sheet I tensioned, and the UI showed Ready To Cut. But $MINFO told a different story:

extension drift (mm):  etl=0.35  etr=3.07  ebr=-15.45  ebl=3.98

Bottom-right belt 15 mm off. Hitting Run there is a position-error → E-stop mid-cut waiting to happen (same failure class as the position-error reboots in [25789]). Earlier in the same session, a recovery left the belts ~110 mm off while still reading tensioned.

What I now check before every $SD/Run: the four $MINFO extension-drift values (etl/etr/ebr/ebl), not just the banner. On a seated machine they sit near zero (mine are typically < 0.1–0.2 mm). Millimeters = a belt isn’t where the controller thinks it is.

Recovery that worked: release tension → apply tension → jog the machine around a little. That re-synced position and dropped the drift from −15 mm back to ~0.02 mm, steady. (Jogging alone cleared the 110 mm case too — moving re-establishes the belt/position relationship.)

Takeaways: (1) read the $MINFO drift before cutting; treat anything past a fraction of a mm as “re-seat first.” (2) It’d be great if “Ready to Cut” weren’t green when a belt is several mm out of position.

Anyone else seen as-cut belt drift after a sheet change / sled bump — what’s your threshold for re-seating before a cut?

Maslow-serial (16).log (6.0 KB)

what version firmware are you running? the system can detect the belt being
±10mm off (about a 1/4 turn of the encoder each way) and will not accept the
stored data if it is in the other just over 10mm of encoder revolution. But it
has no way to detect if the encoder has made a full revolution (back within the
±10mm area of rotation)

current firmware versions will check the belts match the anchor locations when
you do apply tension, and throw an error that requires that you do a full
retract/extend cycle if the belts don’t compute to a valid location with the
stored anchors.

David Lang

I’m on 1.15. I tried to upgrade to the newest firmware and we didn’t have any luck calibrating so I downgraded back to get some work done.

I’m not sure what would have happened if I would have started cutting at that point.Just figured I would share that.