Help: Klipper crashes mid-print

General Discussion
1

Basic Information:

Printer Model: Custom Corexy (started life as a Hypercube Evolution)
MCU / Printerboard: Raspbery Pi 3b+, SKR mini 3
Host / SBC
klippy.log

klippy.log (6.5 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

…The last few larger prints I have tried have failed due to Klipper shutting down. It requires that it be powered off/on to get access to it via the local network (and ssh). The last time it happened I was watching it via webcam and the printer just stopped and connection to Klipper was lost.

This is a recent install of klipper & Mainsail OS on a raspberry pi 3b+. The printer is running on a Skr Mini 3.

I don’t see any issues in klippy.log or moonraker.log (but they are also filled with code and klippy.log lacks even timestamps to check for so I may simply be missing it).

The Raspberry PI is powered separately from the SKR Mini via a 5A wall “wart” power adapter.

Any ideas what to troubleshoot next? Or what logs to check?

RPi 3 locks up with SKR Mini E3 V3
2

I have looked at the klipper.log in the “klippylyzer” and “visualizer”. And the crash is right at the beginning of the log. Klipper crashes right in the middle of sending an status update. Then takes up again with “Staring klippy…”

Stats 10479.3: gcodein=0 mcu: mcu_awake=0.021 mcu_task_avg=0.000027 mcu_task_stddev=0.000034 bytes_write=11940167 bytes_read=3039047 bytes_retransmit=88 bytes_invalid=0 send_seq=258292 receive_seq=258292 retransmit_seq=217719 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=63997599 sd_pos=1781620 heater_bed: target=55 temp=55.1 pwm=0.049 sysload=0.36 cputime=461.756 memavail=574948 print_time=6863.036 buffer_time=2.022 print_stall=0 extruder: target=200 temp=200.0 pwm=0.612

Stats 10480.3: gcodein=0 mcu: mcu_awake=0.021 mcu_task_avg=0.000027 mcu_task_stddev=0.000034 bytes_write=11942986 bytes_read=3039564 bytes_retransmit=88 bytes_invalid=0 send_seq=258347 receive_seq=258347 retransmit_seq=217719 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=63997597 sd_pos=1782020 heater_bed: tStarting Klippy…

3

Hello @MichaelBrock !

Stats 13279.3: gcodein=0  mcu: mcu_awake=0.029 mcu_task_avg=0.000030 mcu_task_stddev=0.000037 bytes_write=25212946 bytes_read=6013767 bytes_retransmit=256 bytes_invalid=0 send_seq=533247 receive_seq=533247 retransmit_seq=532402 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=16 upcoming_bytes=0 freq=63997624 sd_pos=4802053 heater_bed: target=55 temp=55.0 pwm=0.000 sysload=0.04 cputime=699.115 memavail=573708 print_time=13255.835 buffer_time=2.974 print_stall=0 extruder: target=200 temp=200.1 pwm=0.505
Stats 13280.3: gcodein=0  mcu: mcu_awake=0.029 mcu_task_avg=0.000030 mcu_task_stddev=0.000037 bytes_write=25214511 bytes_read=6014194 bytes_retransmit=256 bytes_invalid=0 send_seq=533281 receive_seq=533281 retransmit_seq=532402 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=46 upcoming_bytes=Starting Klippy...
Args: ['/home/mike/klipper/klippy/klippy.py', '/home/mike/printer_data/config/printer.cfg', '-l', '/home/mike/printer_data/logs/klippy.log', '-I', '/home/mike/printer_data/comms/klippy.serial', '-a', '/home/mike/printer_data/comms/klippy.sock']

To me, this appears as a power failure of the SBC PSU.

4

Of the raspberry PI power supply? The issue also struck me as a power issue. I had added a tp-link power switch to the printer itself and I thought that might be the issue but I took it out of the equation and tried another print…same issue. Could this be the issue some people experience where power from the printer board is making things “weird” for a independently powered SBC? (the issue that people fix by taping over the USB cable’s power pin).

5

That’s possible.

How have you done the power and signal wiring in your printer?

Could you draw a diagram that we can take a look at?

6

I’m not sure that I would call it a power failure right from the start, but you are correct: It looks like the RPi is spontaneously crashing - for whatever reason.

You could use the information from Raspberry pi crashing during "make" command - #17 by Sineos for example to stress-test your unit, and maybe you can watch it crashing live and in color.
Generally @EddyMI3D is right: Power supplies are good usual suspects on RPis but I have yet to see that

solved anything. For me, this is a bit of a myth and the actual root causes were something different.

7

Overnight Klipper crashed again without a print in process. I’m going to test various scenarios of having the individual things plugged into the Pi. I already determined that it will still crash with the HDMI5 LCD disconnected. Testing now a completely disconnected host.

8

I installed an adapter that cut the power in the Host SBC to SKR printer, I tightened up all of the USB ports, checked all of the connections…and it happened again For the second time, it happened while I was watching, but this time in person (as opposed to via Webcam). No noise, nothing indicating that failure was imminent. The printer simply stopped, then Kilpper crashes. I bought a new power supply for the Raspberry Pi but didn’t notice any power cut when it failed. I might as well try it.

Attached is the latest copy of the klipper log. This failure looks very much like the last

one.

Is it possible that the printer board (SKR mini e3) is overheating? I do have a fan on it but the printer itself is in my 92F (33C) garage.

klippy_2025_08_01.log (4.4 MB)

9

What is the temperature measured by the MCU and the rPi?

33C isn’t that high - I just checked my printers and the rPis (CM4s actually) are running at around 43C with MCUs running from 37C to 45C.

I would still like to see a wiring diagram of your printer.

10

The MCU has no independent temperature measurement (SKR Mini e3). The rPi is averaging mid 60C. I just ran the stress test from sysbench and temperatures topped out at 85C on the rPi and the rPi did not crash. The file and memory test also had no issues.

The wiring diagram is I think not abnormal. The only thing that might be is that I am using a heat bed controller because my previous controller, (Ramps 1.4 on a 8bit Mega 256 arduino) couldn’t power the bed.

PXL_20250801_211118815.RAW-01.COVER
PXL_20250801_211118815.RAW-01.COVER1920×1442 168 KB

11

Sure it does, add the following statement to your printer.cfg:

[temperature_sensor mcu_temp]
sensor_type: temperature_mcu

Could you add the details of the “Bed Heater Controller”? I’m guessing it’s a solid state relay that is connected to your mains.

12

It is this one: Amazon.com A relay but not mains, just the 12v from the PSU.

I added the mcu_temp to my printer.config and it is showing in Mainsail. Google got that one wrong!

13

Seems you’ve covered EVERYTHING except an intermittent fault on the Host (Pi) or the SKR.

Have you got any other computers laying around? I’d sub in a different host computer. ANYTHING that will run Ubuntu server will work. I used to run klipper on a celeron laptop with a busted screen and half the keycaps missing. Not as simple as clicking a SD card into a Pi but if you have a keyboard and monitor (or TV) to use during the install you are golden. Once you get Ubuntu running unhook the peripherals and boot headless. Then SSH in and install KIAUH, just like your Pi.

14

Again, please provide a complete and accurate wiring diagram of the printer?

The MOSFET driver you’ve linked to will not just have two lines from the main controller board and two lines to the heated bed.

I’m asking to make sure you don’t have a ground loop or are overloading the power supply.

15

“The MOSFET driver you’ve linked to will not just have two lines from the main controller board and two lines to the heated bed.”

You are correct of course. It has two lines from the controller (skr). There aren’t any random wires connected to anything that shouldn’t have a wire connected to it. There are only 2 set of lines leaving the PSU, one to the SKR and one to the Heated Bed Controller. Updated diagram.

PXL_20250802_012904091.RAW-01.COVER
PXL_20250802_012904091.RAW-01.COVER1920×1442 156 KB

16

My next step is to redo all of the wiring from the skr to the hardware just in case. If that doesn’t help. I’m going to replace the pi. Then the power supply.

17

We’re getting there.

A couple of things:

  1. Could you please work at making the diagram easier to read? Get something like Libre Office Draw or use Google Slides. It takes about the same amount of time, much easier to read and you have a digital copy you can update.
  2. Is there anything connected to the USB where you’ve written what looks like “HDMI5”, “USB” & “HDMIE” in the top left corner in the rotated image below.
  3. Could you please provide the exact wiring in the yellow box below:

image
image1442×1330 110 KB

You have something that looks like a ground loop and I would like to understand exactly what are each of the eight lines are and where they’re connected on the different devices.

18

I took the bed heater controller out of the circuit entirely and the bed is now powered directly from the SKR Mini E3. Now the only lines from the PSU is to the SKR. Not a fix. I am seeing high re-transmit during the print. Is that indicative of a problem?

image
image2223×530 39.2 KB

19

According to your log:

  • Klipper seems to be spontaneously restarted, which likely points to an unstable SBC that might either be hard crashing or the Klipper service is crashing. Try journalctl -u klipper.service -n 50 --no-pager right after the event.
  • It contains a “Transition to shutdown state: Lost communication with MCU ‘mcu’”, which also points to hardware instabilities. See Timeout with MCU / Lost communication with MCU
20

The pi/SBC is unreachable after this happens. It still shows in the network but I can’t get to it via ssh or local web.