Nearly every print the printer gets stuck mid print and the raspberry pi 4 seems to reboot. Sometimes this happens on the first layer, sometimes 2 hours into a print.
The printer is new (2 days old) and the Octoprint install is fresh (1.8.1). The raspberry, power supply and sd card are not new but worked in another project for about 2 years without problem .
Because the printer is located at my workplace it is only printing when somebody is there and it is never connected to the internal network or internet. I gave it its own wifi router so I can remotely control it via octoprint. The long term plan is to incorporate it into our network (this will be done by our IT system admin) - when this issue is fixed of course.
What did you already try to solve it?
I tried
actively cooling the pi (no change)
try 30W USB PD power supply (did not work, the Pi seems to have no USB Power Delivery implementation)
try using a USB2.0 port to connect to the printer instead of the USB3.0 port of the pi (no change)
run in safe mode (no change)
Have you tried running in safe mode?
yes, the print also halted
Did running in safe mode solve the problem?
no, unfortunately not
Systeminfo Bundle
I activated serial logging. This is the bundle I extracted shortly after the last crash a few minutes ago (don't trust the date/time, my pi is not connected to the internet and does not the correct time) octoprint-systeminfo-20220629201844.zip (1.8 MB)
First: Please only tun on the DEBUG mode when a dev asks for it.
From the 30557 line of the octoprint.log, only 755 are of use.
Keep in mind, that DEBUG logging takes quite some resources.
To your problem:
There are frequent hard boots/power cycles of the pi, but no throttle warnings.
Maybe the 5V wiring is not sufficient enough, the PSU collapses at some point, your mains is unstable or there is a fault in the mains plugs.
BTW:
How do you usually turn off the pi?
There is a huge time gap at some point:
2022-07-01 06:05:09,136 - octoprint.util.comm - INFO - Telling the printer to set the busy interval to our "communicationBusy" timeout - 1s = 2s
2022-06-29 19:20:48,782 - octoprint.startup - INFO - ******************************************************************************
2022-06-29 19:20:48,784 - octoprint.startup - INFO - Starting OctoPrint 1.8.1
2022-06-29 19:20:48,785 - octoprint.startup - INFO - ******************************************************************************
I will disable DEBUG, I just wanted to provide as much information as possible.
I power down the printer and raspberry by switching off the power strip. This might not be the best practice but I only have done it two or three times with this raspberry (in my home setup I power the raspberry 3 from the same supply as the 3D printer. so when I flip the switch both turn on/off at the same time).
I am pretty sure the time jump is caused (or a side effect of) by me setting the correct timezone and time in the raspberry OS via SSH. Of course I realized quickly that this is of no use without a battery backup so I haven't done it again.
For my next experiment I try printing with a big lab power supply and a 4700 µF cap in parallel. This should deal with any power problem.
It seems the reason was the most obvious one: the power supply.
Even though the Raspberry worked for 2 years without problem with a 2.5A supply it may had the same instability without us noticing. It was used to automatically compile some code and operate a test bench. However these tasks were very infrequent.
The raspberry now works without interruption for about 5 hours and counting thanks to the lab bench power supply. I set the voltage to 5.1V.
I ordered a 5.1V 3A USB-C power supply for a more permanent solution. I will also dispose of the previous 5V 2.5A supply - It obviously can't deliver what it promises.
For the future I will probably design a proper USB-C header or simple adapter board with actual Power Delivery implementation so that I can use one of my 30W USB power supplies. I should have most components and code lying around for that. The reason is that the current solution with 5.1V and 3A somewhat feels like a hack and is well outside the USB-specification when I am not mistaken. Additionally I can implement some EMC measures, large capacitors and maybe a shutdown button.