azab2c
May 13, 2026, 10:28pm
1
Observed a few “Connection drop” issues. Curious whether some tweaks to FluidNC would help root cause underlying cause faster, e.g. loose power adapter cord/connections.
main ← aaronse:main
opened 10:24PM - 13 May 26 UTC
Thoughts on these edits, or something like them, to help Users self diagnose and… root cause job failures faster?
Adds a few ESP32 runtime fields to `$ESP420` / `System/Stats`:
* `uptime_ms`
* `reset_reason_code`
* `reset_reason_name`
* `previous_panic`
This helps users and support tools quickly tell whether a connection loss or job failure likely involved a controller reboot, brownout, panic, watchdog reset, or a network-only disconnect.
Kept intentionally small... no new command, no event history, no persistent boot ID. I'd like to propose/contribute more, but figured narrow scope might be low risk and helpful enough to incorporate.
Change would add a few fields to $ESP420 output…
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Pn:XYZ>
$ESP420
Chip ID: 26639
CPU Cores: 2
CPU Frequency: 240Mhz
CPU Temperature: 41.7°C
Free memory: 107.57 KB
SDK: v4.4.7-dirty
Flash Size: 4.00 MB
uptime_ms: 3334062
reset_reason_code: 1
reset_reason_name: ESP_RST_POWERON
previous_panic: false
[MSG:Mode=AP:SSID=FluidNC:IP=10.42.42.1:MAC=68-25-DD-FB-0F-69]
FW version: FluidNC v4.x.x (main-6f103818-dirty)
Helpful, or would something else be better ROI?
It’s a real shame there isn’t a non-volatile boot counter in FluidNC. Then you’d be able to look at the telemetry and see if the controller was having significant rebooting going on.
Also a shame there doesn’t appear to be an RTC on board where you could again put a timestamp on stuff like last boot output in $SS
azab2c
May 13, 2026, 10:35pm
3
Yeah, agree, was going to try adding a boot id depending PR response.
RTC would be sweet for sure. Figure there’s some failure conditions a client can detect if uptime unexpectedly resets.