Printer Model: Voron2
MCU / Printerboard: PrintSmartCoreH7x (Board with a STM32H723 MCU)
Host / SBC: Dell laptop with ubuntu 24.04, klipper installed with kiauh
klippy.log klippy.log.zip (42.4 KB)
I have two boards, and klipper running on a laptop. I have to have the klipper service stopped when I power on the printer with the two boards, otherwise I never can connect.
So, let’s imagine, I have the boards powered on, then I start the klipper service, and then everything works as expected. Then, I power down the printer with the two boards. Obviously, I will get an error.
From here on, no matter how many times I try restarting the firmware, or the klipper service, I cannot get it to work. I keep getting the same error message. I have to power off the printer, stop the service, then power on the printer, and then start the klipper service.
Is this expected behavior? Is there a solution to this? I mean apart from stopping the klipper service before powering on the printer?
P.S. I suspect it wouldn’t happen to a printer with a Raspberry Pi, as powering down the printer also means stopping klipper.
There is one single timeout in my log for each boards (there are two), and as I explained, that is expected, as I powered down the printer (the two boards). The problem starts afterwords, when I power up the printer, and communication cannot be established by neither restarting the firmware, nor klipper. I have to power down the printer, stop klipper, then power on the printer, and then start klipper. Then, communication is successfully established, and everything works as expected.
I don’t think there is any instablity on my end, there’s nothing in dmesg either. Unless I power down the printer, it’s rock solid.
It’s not like it’s the end of the world, I just have to pay attention to the right sequence of starting up everything. And my comment about the RPI is indeed relevant, because in most cases (when RPI is used), we wouldn’t have this situation, but I am running klipper on a laptop, that is never powered down.
On my printers I typically do not power down the SBC as well and just cut power to the boards. In any case it does not matter in which sequence I power on or off. Worst case is that a FIRMWARE_RESTART is needed.
OK, that’s good to know, it must be something on my end, then, indeed. Thank you for confirming, that it should work the way I do it. And it even sounds like you have a printer with more than one board, so that should work for me, too.
I’ll keep digging, but it will take some time to understand the klippy log. If anyone has some idea what goes wrong, I appreciate any suggestion.
Try adding restart_method: command to your [mcu] and [mcu z] configuration sections. It appears that your boards are using USB-TTL converters for communication between the host and mcu rather than the native USB peripheral. Klipper can’t autodetect the board reset method, so it falls back to the arduino method which fails.
Yes, yes, yes! Thank you so much for pointing me to the right direction!
Indeed, I am using external USB-serial adapters, and use UARTs on the boards. And the USB adapters are powered from the laptop. I was thinking, it will be more stable for ubuntu, not to mix up which USB port is which, if I keep the USB cables connected all the time, so there would be no change in the USB ID assignment.
I think even the arduino method should work, but I don’t have the DTR signal connected, only GND, RX, and TX. :-/
So, I changed the restart_method to command for both boards, and it now works perfectly!
Thank you so much for pointing me to the right direction!