Potential bug though unclear from what

[nerdybobo]

I need help diagnosing a problem with the k1 max 3d printer.
The symptom:

1. Prints fine. Send a second print, and it looks wrong, first layers off, retraction is bad, and z can also be affected creating thin print lines.
2. Reboot, then send the same file from orca (without change), and it prints fine again.
3. When it's going into this weird mode where its printing poorly, going into fluid and adjusting the flow, z offset, or any calibration setting seems to have 0 affect. Reboot, send print is the only way its fixed.
4. I have been monitoring hardware stats and usage on my 3d printer, but I'm not seeing a starved resource. It's unclear what the problem is, where it's coming from and why it is happening on multiple k1 max as I've seen this happen on all 3 that I own.

My solution so far is to either create a macro: reset_diag.cfg

[gcode_macro RESET_STATE_DIAG]
description: Reset state and report active values
gcode:

    # --- Capture current runtime values before reset ---
    { action_respond_info("=== STATE REPORT BEFORE RESET ===") }
    { action_respond_info("Current Z-Offset: %.3f" % printer.gcode_move.homing_origin.z) }
    { action_respond_info("Current Pressure Advance: %.3f" % printer.extruder.pressure_advance) }
    { action_respond_info("Current PA Smooth Time: %.3f" % printer.extruder.pressure_advance_smooth_time) }
    { action_respond_info("Current Retraction Length: %.3f" % printer.firmware_retraction.retract_length if printer.firmware_retraction is defined else 0.0) }

    # --- Now clear/reset states ---
    BED_MESH_CLEAR
    SET_GCODE_OFFSET Z=0
    SET_PRESSURE_ADVANCE ADVANCE=0
    SET_PRESSURE_ADVANCE SMOOTH_TIME=0
    SET_RETRACTION RETRACT_LENGTH=0

    # --- Report reset confirmation ---
    { action_respond_info("=== STATE RESET ===") }
    { action_respond_info("Z-Offset reset to 0 (cfg/default reapplies)") }
    { action_respond_info("Pressure Advance reset to 0") }
    { action_respond_info("Retraction reset to 0") }
    { action_respond_info("Bed mesh cleared") }

And add RESET_STATE_DIAG to my slicer end gcode (or manually run it if I need to).

Or alternatively, a simple shutdown, and turn it back on.

[nerdybobo]

ok doing that does not help exactly and the issue appears to be related to a hardware issue related to the wifi (even if not connected)

1. Recent Kernel Messages - Wi-Fi Errors Present

dmesg | tail -20

Results:

[ 4896.589130] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[ 5648.801579] start st7701 init.
[ 6286.633391] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[ 7546.609316] IRQ Error, cpu: 0 Cause:0x08800000, Status:0x14001c00
[ 9741.439480] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[32000.058710] IRQ Error, cpu: 1 Cause:0x08800000, Status:0x14001c00
[38164.634455] IRQ Error, cpu: 0 Cause:0x08800000, Status:0x34001c00
[43270.170600] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc

Key Findings:

• CFG80211-ERROR messages (Wi-Fi driver errors)
• IRQ Error messages on both CPU cores
• SPI activity (st7701 display controller)

2. Recent Klipper BlockingIOError - FOUND ACTIVE ISSUE

tail -50 /usr/data/printer_data/logs/klippy.log | grep -E "BlockingIOError|Resource temporarily unavailable|ERROR"

Results:

[ERROR] 2025-09-06 09:58:32,247 [root] [gcode:_respond_raw:551] Write g-code response
BlockingIOError: [Errno 11] Resource temporarily unavailable

CRITICAL FINDING: BlockingIOError occurred TODAY at 09:58:32 during g-code response write - this is exactly what causes Fluidd unresponsiveness!

I disabled the Wi-Fi, and it appears to clear the blockingioerror and return to a "normal" functioning state, but after a reboot, the printer goes back to the same issue after X time..

I don't think this is related to fluid or this helper script but an actual problem with the motherboard wifi. Still diagnosing.