v0.1.7-ZNP MCU 'mcu' shutdown: Timer too close after adaptive bed mesh scan

[ChrAdlerNorderstedt]

Hi,

I open a new bug report due to the fact, that other reports mentioned to 0.1.6.

My setup:

• Neptune 4 Pro, stepper 1.2, PCB 1.0
• v0.1.7 on new eMMC, build from scratch as per wiki
• all MCU's on v0.13.0-406-gbaf188bd
• BTT-Eddy with eddy-ng (actual software)
• openneptune v0.1.7-1-gc8100e17
• display 80320b29

My PRINT_START (relevant part):
_ G28

PROBE_EDDY_NG_TAP

{% if BED_MESH == 'full' %}
BED_MESH_CALIBRATE METHOD=rapid_scan
{% elif BED_MESH == 'adaptive' %}
BED_MESH_CALIBRATE METHOD=rapid_scan ADAPTIVE=1
{% elif BED_MESH != 'none' %}
BED_MESH_PROFILE LOAD={BED_MESH}
{% endif %}
Smart_Park
SET_FILAMENT_SENSOR SENSOR=filament_sensor ENABLE=1
SET_HEATER_TEMPERATURE HEATER=extruder TARGET={EXTRUDER_TEMP}   ; Set and heat the final extruder temperature
TEMPERATURE_WAIT SENSOR=extruder MINIMUM={EXTRUDER_TEMP-4} MAXIMUM={EXTRUDER_TEMP+10}  ; Wait for extruder to reach near target temperature
LINE_PURGE                                                      ; KAMP Line Purge near print
G92 E0                                                          ; Reset Extruder
G1 Z2.0 F3000                                                   ; Move Z Axis up 
M117 Printing      _

After starting a new print job I get the terrible 'mcu' shutdown: Timer too close after scanning the bed.

I tried different tests and found, that a bed mesh scan started manually via fluid or console works fine.

Now I store a full mesh as "default" and start the print in my slicer with METHOD=default.

But this can not be the final solution.

[halfmanbear]

I wonder why the bed meshing is now causing crashes. The adaptive bed mesh code is just running Klippers own implementation.

[ChrAdlerNorderstedt]

Problem exists also without ADAPTIVE=1 (-> full mesh), looks like the MCU problem occurse only if the mesh is in the flow of the PRINT_START... maybe the data processing of the scan within the workflow ?!

[ringnutz]

I have a cartographer but experience a similar issue either when trying a standalone mesh or using ADAPTIVE as part of the print start

MCU 'mcu' shutdown: Missed scheduling of next digital out event
This is generally indicative of an intermittent
communication failure between micro-controller and host.

[Synapticxyz]

I must confirm also, have this problem.

OpenNept4une: v0.1.7-1-gc8100e17
klipper: v0.13.0-419-g2e580237

After printer does adaptive scan get an error:
MCU 'mcu' shutdown: Missed scheduling of next digital out event
This is generally indicative of an intermittent
communication failure between micro-controller and host.

[ChrAdlerNorderstedt]

Want to share a new information:
Today I switched over to kalico (a fork of klipper) and now all MCU shutdown are gone.

So... the root cause of all problems within OpenNeptune are maybe the current klipper ?!

[ringnutz]

Want to share a new information: Today I switched over to kalico (a fork of klipper) and now all MCU shutdown are gone.

So... the root cause of all problems within OpenNeptune are maybe the current klipper ?!

I can confirm Kalico works as well, must be an issue with mainline Klipper

EDIT - I thought this was fixed but while it happens less, it still occurs

[ringnutz]

FWIW I think this issue for me is with the carto and not opennept4une/klipper

[jimmycr]

guys, I am on Kalico for several months now, but have Carto and my "MCU errors" started directly after November updates. Now I am back on my backup version and everything works like a charm... I just must remember to not update "Openneptune things" :( . Havent seen any new info from halfmanbear, I already attached my logs in another thread :(

[SaSue]

Maybe you can try to load the Klipper branch with this fix:
Klipper3d/klipper#7143 and recompile and update your MCU firmware.
From my pov this could be the solution

[ringnutz]

I did try that but the issue persists, updated firmware and no change @SaSue

[ChrAdlerNorderstedt]

Maybe you can try to load the Klipper branch with this fix: Klipper3d/klipper#7143 and recompile and update your MCU firmware. From my pov this could be the solution

Run two prints without any issue. But update klipper-sources before to v0.13.0-425 and implement the patch.