Printer Model: Voron v0.1
MCU / Printerboard:
Primary MCU: SKR E3 v2.0
Secondary MCU (display): based on STM32F042 klippy.log
Describe your issue:
I have a secondary MCU (you can find it described as “mcu display” klippy 2.log.zip (1.1 MB)
). This works great on fresh powerup. however, if I issue a FIRMWARE_RESTART, I believe it is failing the “COMMAND” restart and becomes unresponsive until I pull the USB cable (power provided this way as well) for the display and plug it back in - now, a FIRMWARE_RESTART works as intended
I have the same problem. Using a restart_method of “rpi_usb” (Raspberry Pi 3B+) has the same problem as “command”. It’s also not 100% consistent for me; sometimes it resets just fine.
As a workaround, I’m going to try using uhubctl to power cycle the display external to klipper next time this happens.
I have never heard of the “uhubctl” project, but I am definitely interested. Thanks for letting me know. I wish I could submit a proper bug report on klipper github, but we can’t do that anymore…
UPDATE Unfortunately, this technique does not work for raspberry pi zero.
As a follow-up to this, uhubctl did work when I got in this situation again. I does let you power-cycle a USB port, which is basically a nicer version of the same workaround. The tool only works with some models of Raspberry Pi, and some “smart” USB hubs.
I’ve also now had this happen to a Klipper Expander secondary MCU as well, so I don’t think it’s just a thing with that particular display. Next time it happens, if I have time, I will try to get more diagnostic info because the device does seem to be in some sort of wedged state. It only seems to happen when I don’t want it to.
I’m glad that it worked for you! Unfortunately, this doesn’t work on the pi zero (no actually hub on this device). I might have to buy one of the hubs from that project, but also wish we could hear from klipper on why the restart_method: command doesn’t work
HI, same situation.
It happens almost every time. In this situation only helps reboot.
It can be reproduced when i edit config and then save and restart.
This voron displays are crap. have two of them and same bahavior.
looks like serious problem, but none has idea how to solve this. Still facing problems with voron 0 display.
worst thing that designed for it case. But plan throw to trash this trash.
Just wasted all day trying to get my head round this as well. What I have discovered is that when you need to reboot the RasPi, it loses comms with all the rest of the printer hardware. No amount of [Restart Firmware] will get it working again because the device tree entries for the hardware is lost during the reboot. You can prove this by re-running ls /dev/serial/by-id
Without the hardware identifying itself with its serial number, klipper cannot find your mcus.
Running uhubctl twice (with -a 0 to switch the USB ports off and again several seconds later with -a 1 to switch back on) works for some hardware but not all. eg the v0display and BTT SKR-pico both restart on a power cycle and reappear in the device tree, However if you have an LDO Picobilical this doesn’t, simply because the mcu is permanently powered by a 24V to 3.3V convertor while the previous 2 are powered from the USB.
There is a further problem in klipper in that unless ALL mcus listed in your cfg files have been found it won’t talk to any.
I found that if you use uhubctl to restart USB powered mcus, then press the restart button on the picobilical, this makes all boards re-register their serial number and then you can do a [Restart Firmware] satisfactorily.
Being a total noob, I don’t know how any of the comms work but I believe it to be some sort of token passing. I wouldn’t dare to suggest that the most logical solution would be for the authors of klipper to run a watchdog on each board so that if they have had no comms for say 5 secs, they restart and offer their ID to the host again. If the host has no commands to send, it should send a dummy keep-alive to prevent the watchdog from triggering.
FWIW, I think uhubctl -l 1-1 -p 2 -a 2 would probably work to restart USB powered mcus if I knew how the -d option worked but the default cycle delay is too short to reliably force a restart on v0display and BTT SKR.