Anyone have any idea as to why the Z up is causing all of the motors to release tension?
Serial Messages
Index.html Version: v1.15
[MSG:INFO: Channel auto report interval set to 50 ms]
[MSG:INFO: FluidNC v1.15]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:maslow.yaml]
[MSG:INFO: Machine Maslow S3 Board]
[MSG:INFO: Board Maslow]
[MSG:INFO: UART1 Tx:gpio.1 Rx:gpio.2 RTS:NO_PIN Baud:115200]
[MSG:INFO: SPI SCK:gpio.12 MOSI:gpio.11 MISO:gpio.13]
[MSG:INFO: SD Card cs_pin:gpio.10 detect:NO_PIN freq:8000000]
[MSG:INFO: Stepping:Timed Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:240ms]
[MSG:INFO: Axis count 5]
[MSG:INFO: Axis A (-4000.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis B (-4000.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis C (-4000.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis D (-4000.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis Z (-100.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: tmc_2209 UART1 Addr:0 Step:gpio.15 Dir:gpio.16 Disable:NO_PIN R:0.11]
[MSG:INFO: Motor1]
[MSG:INFO: tmc_2209 UART1 Addr:1 Step:gpio.46 Dir:gpio.38 Disable:NO_PIN R:0.11]
[MSG:INFO: Z Axis driver test passed]
[MSG:INFO: Z2 Axis driver test passed]
[MSG:INFO: Using spindle NoSpindle]
[MSG:INFO: Connecting to STA SSID:MegaDome]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 192.168.0.190]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://maslow.local/\]
[MSG:INFO: SSDP Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
Grbl 1.15 [FluidNC v1.15 (wifi) ‘$’ for help]
Grbl 1.15 [FluidNC v1.15 (wifi) ‘$’ for help]
[MSG:INFO: ‘$H’|‘$X’ to unlock]
[MSG:INFO: Encoder connected on Top Left]
[MSG:INFO: Motor detected on Top Left]
[MSG:INFO: Encoder connected on Top Right]
[MSG:INFO: Motor detected on Top Right]
[MSG:INFO: Encoder connected on Bottom Left]
[MSG:INFO: Motor detected on Bottom Left]
[MSG:INFO: Encoder connected on Bottom Right]
[MSG:INFO: Motor detected on Bottom Right]
[MSG:INFO: Center coordinates updated in MaslowKinematics: X=2365.830 Y=1714.057]
[MSG:INFO: Current z-axis position loaded as: 136.840]
[MSG:INFO: loadBeltPositions() called]
[MSG:INFO: Validity check: ret=0 validityMarker=1]
[MSG:INFO: TL encoder moved 195 counts (-2.094mm) since save, adjusting position]
[MSG:INFO: TR encoder moved 143 counts (-1.535mm) since save, adjusting position]
[MSG:INFO: BL encoder moved 131 counts (-1.406mm) since save, adjusting position]
[MSG:INFO: BR encoder moved 181 counts (-1.943mm) since save, adjusting position]
[MSG:INFO: Belt position load: Set currentState directly to EXTENDEDOUT]
[MSG:INFO: Starting Maslow Version v1.15]
[MSG:INFO: Channel auto report interval set to 50 ms]
Release Tension
[MSG:INFO: Requesting state change from Belts Extended to Releasing Tension]
[MSG:INFO: Succeeded]
[MSG:INFO: Requesting state change from Releasing Tension to Belts Extended]
[MSG:INFO: Succeeded]
Apply Tension
[MSG:INFO: Requesting state change from Belts Extended to Taking Slack]
[MSG:INFO: Succeeded]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.000 TR: 0.000 BL: -3.696 BR: -7.094]
[MSG:INFO: Center point deviation within 12.000mm, your coordinate system is accurate]
[MSG:INFO: Current machine position loaded as X: 2.860 Y: 14.952]
[MSG:INFO: Before update - mpos: X=4.747 Y=12.153 Z=136.840]
[MSG:INFO: Setting motor positions directly from measurements:]
[MSG:INFO: TL belt: 2746.419 TR belt: 2760.980]
[MSG:INFO: BL belt: 2775.715 BR belt: 2762.980]
[MSG:INFO: After update - mpos: X=1.501 Y=27.096 Z=136.840]
[MSG:INFO: Requesting state change from Taking Slack to Ready To Cut]
[MSG:INFO: Succeeded]
JogTo: $J=G91F300Z1 (mm)
Release Tension
[MSG:INFO: Requesting state change from Ready To Cut to Releasing Tension]
[MSG:INFO: Succeeded]
[MSG:INFO: Requesting state change from Releasing Tension to Belts Extended]
[MSG:INFO: Succeeded]
Apply Tension
[MSG:INFO: Requesting state change from Belts Extended to Taking Slack]
[MSG:INFO: Succeeded]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.000 TR: 0.000 BL: -3.925 BR: -7.490]
[MSG:INFO: Center point deviation within 12.000mm, your coordinate system is accurate]
[MSG:INFO: Current machine position loaded as X: 4.915 Y: 18.674]
[MSG:INFO: Before update - mpos: X=1.499 Y=27.092 Z=137.840]
[MSG:INFO: Setting motor positions directly from measurements:]
[MSG:INFO: TL belt: 2745.917 TR belt: 2757.139]
[MSG:INFO: BL belt: 2779.341 BR belt: 2763.132]
[MSG:INFO: After update - mpos: X=3.548 Y=30.934 Z=137.840]
[MSG:INFO: Requesting state change from Taking Slack to Ready To Cut]
[MSG:INFO: Succeeded]
Anyone have any idea as to why the Z up is causing all of the motors to release tension?
this log is showing that the UI issued the command to release tension
any chance that there is a second browser/phone connected that could be issuing
the command?
the MSG:INFO lines are the firmware reporting what it’s doing.
the JogTo and Release Tension lines are commands to the machine
[MSG:INFO: Requesting state change from Taking Slack to Ready To Cut]
[MSG:INFO: Succeeded]
JogTo: $J=G91F300Z1 (mm)
Release Tension
[MSG:INFO: Requesting state change from Ready To Cut to Releasing Tension]
[MSG:INFO: Succeeded]
[MSG:INFO: Requesting state change from Releasing Tension to Belts Extended]
[MSG:INFO: Succeeded]
Thanks for your input. No other devices connected and touching buttons.This also happened yesterday. Seems to happen after I pause and then stop an active job.
Thanks for your input. No other devices connected and touching buttons.This
also happened yesterday. Seems to happen after I pause and then stop an active
job.
Thanks for your input. No other devices connected and touching buttons.This
also happened yesterday. Seems to happen after I pause and then stop an active
job.
how were you doing the jog? keyboard (pgup/pgdown) clicking in the UI? other?
Z-Stop may not be affected; it could be only Z home is incorrect.
It doesn’t always corrupt the Z value, but if it does then this will warn and stop any movement until action is taken or user accepts condition.
See Show confirmation popup when a movement would raise machine Z above 72mm #933
Z-Stop may not be affected; it could be only Z home is incorrect.
It doesn’t always corrupt the Z value, but if it does then this will warn and stop any movement until action is taken or user accepts condition.
See Show confirmation popup when a movement would raise machine Z above 72mm
I saw that, but I don’t see any case where one Z value would be corrupted and
there is no chance the other wasn’t also corrupted.
plus, if there is an unclean shutdown, why would the Z height be any more
trusted than the belt lengths?
While I have been testing and regularly updating index and firmware files I have noticed numerous occasions where Z home is corrupted, but Zm is still accurate. This can be proven by running Z down by the amount displayed against Zm and checking the router is at the bottom. I have been able to do this easily because I don’t have a bit in the router while proving changes. In practical terms, having to zero out the router every time it generates an Unknown condition, with a bit mounted, would be extremely frustrating and generally not required.
The only times I have noticed Zm to be inaccurate is when the Maslow goes off the screws or is lowered past where the router bottoms out.
This addressed with: Show confirmation popup when machine Z exceeds safe bounds — on startup, before movements, and when Z is outside safe range #933
While I have been testing and regularly updating index and firmware files I
have noticed numerous occasions where Z home is corrupted, but Zm is still
accurate.
let me clarify, times when the belt lengths get corrupted but Zm does not?
when we invalidate the belt lengths (i.e. the machine is moving), shouldn’t we
be invalidateing the current Z position as well? are we trusting the reported Z
position in the nvram even when we don’t trust the belts?
This can be proven by running Z down by the amount displayed against
Zm and checking the router is at the bottom. I have been able to do this
easily because I don’t have a bit in the router while proving changes. In
practical terms, having to zero out the router every time it generates an
Unknown condition, with a bit mounted, would be extremely frustrating and
generally not required.
given that you are having to do the rehang dance, is it really adding much to
that?
It may be that you have been lucky and the Z wasn’t in motion since it was last
saved. but from a first-principals thinking way, I can’t see why you would be
able to trust it.
It’s an extra step, which in my observation, is not generally necessary. It means removing the bit in order to lower the Z to the bottom or blocking the Maslow up to allow lowering of the Z fully without removing bit. In first case you have to then retest the Z home position.
If you make a note of the home position after checking when loading a bit, from the Zm = 0 level you can just raise the Z to that value and set Z home. So long as the Zm is within a reasonable approximation of its correct position, it won’t affect cutting accuracy.
Reviving this one — I’m getting the same jog-triggers-Release-Tension behavior again on v1.15, except this time it’s on the Y axis, not Z.
After tensioning to Ready To Cut, the moment I jog the sled (X or Y — moving it around the sheet, not the Z/bit), it drops out of tension. The bottom two belts are the ones that visibly go slack — they unspool a little, tighten back up, then unspool again. Release Tension → Apply Tension recovers it every time, but the next jog drops it again. 100% repeatable.
The serial log shows the same signature from this thread — a JogTo immediately followed by a Release Tension:
JogTo: $J=G91F2500Y2 (mm)
Release Tension
[MSG:INFO: Requesting state change from Ready To Cut to Releasing Tension]
...
JogTo: $J=G91F2500Y-2 (mm)
Release Tension
[MSG:INFO: Requesting state change from Ready To Cut to Releasing Tension]
Likely trigger, matching Ian’s “Z value too high / off the screws” point earlier in this thread: a few cuts ago I stopped a cut mid-way and manually reset the machine, but I never went back and re-zeroed Z afterward — so my machine Z is probably off.
My question: would re-zeroing Z — i.e. Set Z-Stop / the retract → extend → reset-Z routine — be expected to stop the jog from triggering Release Tension? Is a bad machine-Z the trigger here, the same root cause as #930? Trying to confirm before I redo it.
that is a bug, jogging is not supposed to do release tension. if you have completed calibration, please try updating to 1.21
my guess is that the UI is thinking the settings tab is open and the release tension and jog buttons are in the same place
what URL is showing at the top of your browser? if it’s a captive portal URL, then going to the maslow correctly may help (captive portal browser windows have done strange things for me in the past)
Update — fixed, and it was exactly the corrupted-machine-Z cause Ian flagged.
Root of it: a few cuts back I stopped a cut mid-way and manually reset the machine, and before that the Z had been jogged up into the top stop (clicking / skipped steps). That left the machine Z reading way too high — 176 — while the bit was nowhere near that height. With a bad machine Z, jogging X or Y was firing a Release Tension and dropping the bottom two belts.
What surprised me: the machine looked completely normal sitting there, and Apply Tension passed clean — so I almost dismissed the high Z. It only showed up once things started moving.
The fix — and notably I did NOT need to retract + extend the belts:
Released tension.
Moved the sled to a spot where the bit could travel all the way down without hitting my workpiece.
Jogged Z fully down to the physical bottom stop.
Hit Set Z-Stop ($SETZSTOP).
Raised Z back up to my z-home height and re-set Z Home.
Re-applied tension → jog tests came back normal.
Afterward machine Z read a sane 64 instead of 176, and jogging X/Y no longer drops tension.
Two things worth flagging for anyone hitting this: Define Z Home (G10 L20) does NOT fix it — that only sets work Z; only Set Z-Stop re-establishes the machine Z. And after Set Z-Stop you have to re-Define Z Home before cutting, or your cut depths reference a stale zero.
Thanks @dlang and @ian_ab — the “Z value too high / off the screws” call was spot on. Lines up with #930.
