Random MCU shutdowns during homing

Basic Information:

Printer Model: Flying Bear Ghost 5
MCU / Printerboard: Bigtreetech Manta M5P + CB1
moonraker.log (7.5 KB)
klippy.log (74.3 KB)

Hi everyone.
Recently I decided to move my printer from Marlin to Klipper. I’ve replaced an old motherboard with BTT Manta M5P + CB1 and installed Klipper. After a basic configuration, I started playing with movements, but my printer randomly shut down. It may happen during homing or when the printer does nothing a few minutes after homing. Logs are not very helpful. I don’t see any issues in there. I see a similar situation when someone hit the “Emergency Stop” button, but did not touch it. After clicking a “firmware restart” everything works fine for a short time, but then it shuts down again. I’ve already verified all wiring, but still no luck.

Can someone help me to identify what’s going on? I’m fighting with it for a week already. Any help will be much appreciated.

The log clearly shows that Klipper has received an emergency stop and acted accordingly. There is no other error or anomaly recorded.
I do not know any case, where an emergency stop has been recorded falsely, this means that something else went wrong and Klipper interpreted it as emer stop.

I know two different ways to initiate this:

  • M112 gcode
  • Emer stop via the Moonraker API

@Sineos thank you for your reply.
I also discovered the same you described. I cannot understand why it reacts like that and what is the root cause. Neither M112 nor Moonraker API was explicitly used. And this makes me crazy. Do you have any piece of advice on the next steps to investigate and troubleshoot the issue?
Thanks.

You could set Moonraker to verbose in order to get an idea out of which direction it is coming: Installation - Moonraker

This line in klippy.log means that the shutdown was received through moonraker 45.7s after the homing command:

Received 2047.193021: b'{"id": 281473637232544, "method": "gcode/script", "params": {"script": "G28"}}'
Received 2092.904840: b'{"id": 281473637305648, "method": "emergency_stop", "params": {}}'

Adding a -v on moonraker command line in moonraker.service will turn on its verbose mode, but the log messages don’t show the originating client:

[DEBUG:common.py:_log_request()] - Websocket Received::{"id": 52635, "method": "printer.emergency_stop", "jsonrpc": "2.0"}

One path forward could be stopping clients services (Crowsnest, KlipperScreen, moonraker-timelapse) and closing mainsail tabs. Then wait long enough to see if there is still emergency stop requests coming.

Guys, thank you for the help. Today few updates arrived in my system. After updates, everything seems to be fine. I’m playing with my printer for a few hours in a row already and nothing happens.

As for now, everything works as expected. I’ll see how it goes later and keep everyone posted in this thread.

Thanks again for the help.

I have not seen any issues now. Everything works as expected.

1 Like