I have been using a Raspberry Pi 4 for sometime with my printer. But lately, the Pi has started rebooting during printing for some reason. The first files it was reboot from was a large flat block with lots of small opening (like a screen). I was thinking it might have been because the file was too large/complex so I tried printing a simpler file and it worked fine. Tried the large one again and got the reboot. I just tried another file that is fairly simple, but the Pi rebooted again. The reboot seems to always occur between the first and second layer.
When I try looking at the klipper log file, it only show what has happened since the reboot. On the Pi, dmesg also only shows after the reboot. I tried running a stress test to check for under voltage, but didn’t see any.
I’m not an expert on the Pi OS so not sure what else I can check. This seems to have started after I did an update to klipper because I had printed several of the large screen type files before the update (don’t remember which update it was). I’m not sure if this is a Pi, Klipper, or a combo of both, problem.
Any suggestions on what to do to debug this problem? As it is, the printer is unusable.
The controller board is a BIGTREETECH SKR Pro v1.2.
Except for a hardware problem with the RPi (cables, power, SD card etc.), I cannot imagine Klipper forcing the RPi into a reboot.
RPi 4 is known to be very susceptible when it comes to power supply and memory cards.
Thanks. Those have been my thoughts too. I have another printer running klipper that doesn’t give me a problem (Heavily modified Ender 3 V2). This printer is a RatRig V-Core 3 500x500. It doesn’t get as much print time, but it had been working great up until a bit ago. I have another RPi 4 that I will try swapping in. If that doesn’t work, I don’t know what to do other than put (shudder) Marlin on it.
Oh, as for klipper forcing the pi into a reboot, since klipper is running on the pi, if the code causes some sort of kernel panic, that can cause it to reboot. And the reboot is always occurring at the same place in the print. A bit too consistent for faulty hardware I think.
I have been developing embedded systems for 30+ years (HP LaserJet, Lexmark printers). I have seen some strange things that caused system reboots that you think wouldn’t. But I do agree with you, since it is running in python, it would be less likely.
So I decided to start from scratch. I created a new image following the klipper documentation by starting with OctoPrint. I got it running now and have gotten further that I ever have. Job still has about 4 hours to go. Printing it without filament. Once I see this works, I will start adding back the other items like Fluidd, Moonraker, and KlipperScreen.
I don’t really have enough information to make an educated guess. If the reboot only occurs when Fluidd is served from the system there are two possibilities:
Fluidd is inadvertently calling the reboot API. This seems unlikely as it should be reproducible regardless of platform.
nginx is the source of the kernel panic
This isn’t something I can reproduce on any of my Pi 3s, so if we are indeed dealing with a kernel panic then its a bug in the Kernel and the RPi Foundation needs to address it.
FWIW, Cadriel is has stepped down from Fluidd for the time being. There are some people that plan to continue to maintain it, but to my knowledge they haven’t started yet.
I’ve been doing more testing and it doesn’t seem to be any one thing that is causing this. I was able to build a system with kiauh and printed the model. But after making some changes to the cmdline.txt and config.txt for my touchscreen to install KlipperScreen and the problem came back. Tried removing the changes and then the system wouldn’t boot!
Trying to create another system to try. This is just so frustrating. I have another system that everything works perfectly with. Why is this one giving me such trouble?
