Sending G0 X0 Y0 caused controller reboot — no motion, lost position

Troubleshooting
1

Just had something weird happen and want to understand what triggered it.

After a clean 11-minute foam cut completed (M30 sent at 02:06:10Z), machine sat Idle for ~80 minutes at MPos -1222.470, -517.558, Z=70 (bottom-left corner of the sheet, bit safely retracted). FluidNC v1.15 on Maslow S3 board.

I sent G0 X0 Y0 over the WebSocket (port 81) to bring the sled back to sheet center — same command the “Go to Home” button in the UI sends, as far as I know.

Expected: rapid travel to (0, 0), continuous <Run|MPos:...> status reports along the way, ending at <Idle|MPos:0,0,...>.

Actual: no <Run> reports ever appeared. The board rebooted instead. From my session log:

03:28:42.938Z   <Idle|MPos:-1222.470,-517.558,70.000,0.000,0.000|FS:0,0>
03:28:42.965Z   [MSG:INFO: FluidNC v1.15]
03:28:42.966Z   [MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
...
[boot continues, encoder + motor detection runs]
03:28:42.989Z   [MSG:INFO: TL encoder moved 540 counts (-5.797mm) since save, adjusting position]
03:28:42.989Z   [MSG:INFO: TR encoder angle difference too
03:28:43.185Z   large (-1744 counts), treating belt positions as stale]
03:28:43.186Z   [MSG:INFO: Starting Maslow Version v1.15]

27 ms between the last Idle status and the FluidNC boot banner. No error:, no ALARM: message before the reboot — just dead silence then firmware coming back up. After reboot, position is NaN and the machine is in Alarm with belt positions flagged stale.

One possible factor: my PC was running low on RAM around this time (lots of tabs and other programs open). Could a host-side RAM/network hiccup somehow propagate to the controller and crash it? My mental model says no — the ESP32 is standalone, the PC just talks to it over WebSocket, and a dropped WS connection should leave the board happily sitting in whatever state it was in. I get why I’d need to reconnect the WebSocket. What I don’t understand is why the controller itself rebooted and lost its belt positions / forced me to re-tension. A PC stall shouldn’t reach across the wire and reset the board.

Questions:

  1. What could cause sending a simple G0 X0 Y0 rapid to crash the controller? Power glitch coincidence, or is there a known issue with long-rapids from corner positions?
  2. The TR encoder reporting -1744 counts difference on reboot is suspicious — does that suggest motion did start before the crash, or is that a normal “stale since last save” reading after any unclean shutdown?
  3. Is there any plausible path by which a host-side hiccup (low RAM, WS disconnect) could trigger a controller reboot? Or are these always independent and a reboot here means a genuine board-side fault?
  4. Is there a way to dump a crash log / panic trace from FluidNC after this kind of reboot?

Log file attached.

Thanks.

2026-05-17-controller-reboot-log-excerpt.txt (6.5 KB)

Anyone running a long USB cable to the Maslow controller for better logging?
Snapshot/restore flash to recover known-good Maslow position after a reboot?
Snapshot/restore flash to recover known-good Maslow position after a reboot?
2

Wes wrote:

  1. What could cause sending a simple G0 X0 Y0 rapid to crash the controller?
    Power glitch coincidence, or is there a known issue with long-rapids from
    corner positions?

nothing that we know of. If you ever manage to reproduce this problem, hooking
up a usb cable to get the logs from there will show details of a crash if it
happens

  1. The TR encoder reporting -1744 counts difference on reboot is suspicious —
    does that suggest motion did start before the crash, or is that a normal
    “stale since last save” reading after any unclean shutdown?

when the machine shuts down or reboots with the belts extended, and it is not
able to trust the belt lengths that were saved, the belt positions at startup
are length 0 (it has no way to know they are anything else) and when you
retract-all, it will pull them in until it stops, so the error for that
retraction will be -1 * how much belt was out (it started at length 0 and moved
in a negative direction until it stopped)

every time that it starts moving, it marks saved belt positons as stale, it
doesn’t save new belt positions until it becomes idle again. so when it has a
reboot/shutdown while moving, this is to be expected

  1. Is there any plausible path by which a host-side hiccup (low RAM, WS
    disconnect) could trigger a controller reboot? Or are these always independent
    and a reboot here means a genuine board-side fault?

no way that we know of

  1. Is there a way to dump a crash log / panic trace from FluidNC after this kind of reboot?

no, you have to be connected to the USB in real time to catch any crash log /
panic trace

David Lang

3

I agree with your thinking there.

I don’t know of any issues which match that description, but you could have found something new.

I agree that does seem like a lot. It could be due to motion starting before the crash, but it could also be that the system relaxed when the servos powered down

Yes, but it only gets dumped over USB. If you have a USB cable plugged in and a serial monitor open it will catch the cause of the crash, but there isn’t a way to get that info over wifi (Because wifi probably isn’t working anymore at that point)

4

Update — got more data tonight running the same cut on a third sheet. Pattern is clearer and WiFi is ruled out.

Three reboots tonight, all coincident with the start of a long G0 XY rapid:

Event Move Approx Z Outcome
03:28Z G0 X0 Y0 home from (-1222, -517) — ~1300mm diagonal 70 mm (safe) reboot
03:26Z mid-cut crash, ~9 min into a fresh cut varies reboot — see analysis below
04:39Z G0 X0 Y0 home from (-1219, -531) — ~1329mm diagonal 70 mm (safe) reboot

Between #1 and #3 I restarted my router — that rules out WiFi as the trigger. The pattern is reproducible from the controller side.

The mid-cut one is the most interesting: I audited the per-cut transition distances in the G-code (a 5-piece nest on 4×8 foam, 7 cuts). All inter-cut XY rapids are tiny — 3–11 mm — except the cut 5→6 transition at 100 mm. That’s the only rapid in the file with any real distance. Timing puts the crash right there.

So all three reboots correlate with the start of a G0 XY rapid where all four belt motors have to accelerate simultaneously. Cut motion (G1 at 1444 mm/min, steady) is fine. Z-only G0s (g0 z1, g0 z-40) are fine. Short inter-cut hops (≤11mm) are fine. The trigger is specifically long G0 with significant XY component.

Working theory: motor inrush spike at G0 acceleration → brownout. Same physical pattern fits all three. The Counter:1 cosmetic startup WARNs were normal in every case; no [MSG:ERR:Panic] strings before any of the reboots. From the WebSocket side it looks like silent disappearance for 7–8 seconds, then reconnect lands on <Alarm|MPos:nan,nan,70.000> with MINFO: { homed: false, tl/tr/br/bl ≈ 0, extended: false } — the post-boot, pre-belt-load state.

Mitigation I’m testing next session: dropped belt-axis acceleration from 50 → 30 mm/s² on all four belts (kept max_rate at 2000 so retract/extend speed unchanged). That reduces peak motor current spike by ~40% at the start of any motion. If a long G0 X0 Y0 from a corner survives next session, accel was the issue and I’ll narrow further.

Workaround in the meantime for anyone hitting this: split or chain your cuts so no inter-cut G0 XY rapid exceeds ~10mm. Avoid G0 X0 Y0 return-to-home unless you’re sure your power supply can handle the 4-motor inrush.

Will follow up after the next cut session with the acceleration-test result.

5

If it’s a power related reboot, the reboot will be clear on the USB console

I don’t know what it will say, but if it just goes to a reboot without any
error, that would be a power issue)

David Lang

6

Any kind of reboot will dump a big chunk of hex data over the USB connection which relates to the processors current state at the time of the restart. I’ve found it to be pretty much completely unintelligible, but the AI seems to be really good at understanding what is going on with that data.

If you get a log from a reboot and create an issue here the AI will automatically be triggered to try to solve it.

Here is a quick intro on how that system works if you haven’t seen it already:

1 Like