Basic Information:
Printer Model: Ender 3 S1
MCU / Printerboard: STM32F401
Host / SBC: Raspberry Pi Zero 2 W
klippy.log klippy(6).log (2.6 MB)
Occasionally in the middle of a print, an MCU shutdown happens.
Also, this was happening after running shaper calculate commands.
While there is a webcam normally attached, none was attached during calculations. The camera only would increase CPU usage by a few percent. Power supply is a buck regulator on the 24v supply, and the output is stable at around 5.05v. I’ve considered the potential of noise or interference and thoroughly shielded the serial connection between the board and Pi. I can only really think it to be the SD card being either slow or possibly faulty, it is an older Class 4 card, but I would like a second opinion on the matter before going out to get one.
Also probably related, but sometimes the web interface momentarily hangs and sometimes even drops connection, it was doing this a lot during the shaping calculations, but it’s also happened usually alongside a shutdown. These shutdowns seem to happen more often on longer prints. Shorter ones seem less problematic.
TLDR, I think my SD card is possibly causing issues, be it’s lower speed or older age, would like to know if that diagnosis even remotely comes close.
Yeah, i’ve been on that page a few times before even registering. I feel like i’ve eliminated MOST things on there, minus replacing the card.
I still opted to ask here anyways because I’m not completely sure, and I don’t currently have another card on hand to try. Also thought maybe someone could share insight on the matter.
It can cause that type of issue, but nobody here can say it actually does it for sure.
Often logs and stuff give indication what it might be and you then can rule those out step by step.
Here you could perform a surface check of the SD card or just get a new and faster one and reinstall Klipper and Co.
This is faster than waiting for an answer here that won’t be much helpful.
Are you using any usb hubs? or multiple usb ports on your pi?
This sounds quite similar to an issue i was working though.
Im running a multi mcu setup (6 mcu’s all via usb) and as part of this, i have found that some usb hubs (known as STT or single transaction translator) can exhibit blocking behaviors with the strict timing requirements of klipper.
Ensuring that the USB hubs are MTT (Multiple transaction translator) resolved my issues.
What ive found is that some RPI designs include an internal usb Hub, of which on some of them (and it seems hard to find out exactly which ones) the internal hub is the STT type. You can work around this by only using a single USB port on the RPI connected to a known good MTT type usb hub
Unfortunately, finding MTT type usb hubs seems to be a black art as they dont advertise them as such.
Nope, no usb hubs. I think my issue was what I thought it was though, I went to make an image of my SD card and about 25% in, I got hit with an I/O error. Went out and got another, just copied over configs, and it already seems more stable from what it did earlier.
Though I will also keep that in mind about usb hubs, though I’ve done what I can to avoid using them in the first place heh
Home partition and compression is overkill, but making the system mostly readonly, should make it more stable.
Like move logs to tmpfs if there are >1GB of free RAM.
Sometimes, I think Klippy logs are a little too verbose and the same time too scarce.
Either way, reducing write stress on SD cards can be a good things.
As a bonus, there should be less IO blocks if they even happens.
My bad, for Raspberry Pi Zero 2 W, it will be more tricky and not so clear win.
Like swap + compression, but I’m not sure if it still make a difference.