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.
