Printer Model: Biqu B1 modified with linear rails, dual Z axis, Meanwell 350-24 V PSU, Biqu H2 V2S Extruder and BTT Pi V1.2 (directly connected to PSU via 12/24 V port)
MCU / Printerboard: BTT SKR 1.4
klippy.log klippy.log (2.2 MB)
Describe your issue:
Greeting,
recently, I installed Klipper on my machine using a BTT Pi V1.2 (no issues so far) and last weekend I performed some maintenance and worked on the motion system. To be precise, I exchanged some of the old cables running to the printhead, cleaned up wiring, added a 5 V Led strip (wired via Buck converter directly to PSU) and installed linear rails on the x and y axis. After closing everything back up, I wanted to test out the system but got random mcu connection losses. I started searching the web for any hints on where this issue would come from and began to do some troubleshooting:
switching USB cables (the one I used before is the blue, shielded one that came with the printer and was working well for years) to one with higher gauge, shielding and ferrite chokes
mounting the USB B cable in its socket on the printer board with tape
switch USB sockets on the BTT Pi (please also note that I have a Webcam connected via USB as well)
I also read that interference with one of the motor wires could cause these random connection losses. Even though the cables are now routed slightly different from before, I always had everything packed up quite tightly in the casing and did not care much about keeping them physically away from each other nor had problems so far. Is it a plausible thing that these connection losses could, however, be really caused by electrical interference?
Two other thing to mention (of which I am not sure that they are relevant to the problem but still want to include them):
After replacing the extruder some while ago, I accidentally fried the fan0 mosfet as the cables from the part cooling fan became lose and shortened out after I assembled the new extruder; as there are two PWM controllable fan sockets on the 1.4, I simply switched the plug to the other pin and had no issues since (hence the pin belonging to the fried mosfet is not defined in any way in my config)
I modded the PSU by printing a custom top piece that let me connect a much quieter 12 V fan prior to starting using klipper; I have had the BTT Pi running without an issue before the aforementioned maintenance and motion system upgrade (I am mentioning this because I read a lot about potential voltage drops when using bad PSUs with an original RPI)
As I wasn´t able to find any clear information on this problem when using a BTT Pi I wanted to ask for help and your opinion on the points raised by me. Any feedback on how to troubleshoot further or how to prioritize the search for the culprit is highly appreciated! Thank you in advance!
Thank you and good morning.
A short update on my side: to exclude any influences from the USB cable/ports I switched the connection to UART going through the TFT port of the SKR1.4. Seemed to be working well at first but when I started homing and heating the bed and nozzle in parallel, I got the MCU ‘’mcu’ spontaneous restart error. This also randomly appeared later when I tried building a mesh. I think this is rather pointing in the direction of a power supply issue or any kind of faulty cable connection. I hadn’t had the time yesterday to do it but I’ll plan on doing the following:
Disconnect the BTT Pi from my PSU and power it externally via the USB-C port and a potent power brick
Disconnecting the webcam from the USB ports of the BTT Pi
Apart from that, is the above described phenomenon implying something different that I have not been thinking about yet? And how could I proceed if the two things above also do not work? I figured that I’ll probably would disconne each and every connector from the SKR1.4 to see if any wrong/loose connection is causing the mcu to disconnect, right? If all this is not helping I luckily have another BTT Pi and a new SKR Mini 3 v3 (I’ve been still sticking to the 1.4 as it allows me to have individual Z axis steppers for z-tilt correction) laying around so if all goes down the drain I could still swap out either or both components. Obviously, I would anyway rather like to keep everything as it is if possible.
Any thoughts to that is highly appreciated. I’ll update this thread once I have new insight.
TL;DR I am a stupid idiot and compiled the firmware for the wrong cpu (mixed up Turbo and non-Turbo model)
After checking each and every wire, completely dismantling the PSU to check voltages, powering the Pi via different power sources, testing USB cable over USB cable, switching to serial connection via UART, I finally had a flash of thought: It could have been a wrong setting in the menuconfig. After checking the last parameters I found the culprit: I unfortunately chose the LCP1769 processor and not the LCP1768 (I don’t have the Turbo variant of the board). Interestingly, the system did work in this configuration to some extend but it totally makes sense, that I got random mcu timeouts regardless of movement, heating etc. due to the wrong frequency of the cpu.
Even thought this definitely is a stupid user error, I still wanted to share my experience to make everyone aware to check for the right processor mode when compiling firmware.