This is a heads up that a rather bizarre issue has surfaced with some of the recent updates to KlipperScreen, see My post on Discord and the surrounding posts.
Two of my printers, both running Pi OS Buster started behaving erratically a few days ago - particularly when attempting FIRMWARE_RESTART. One printer is on Duet 3 Mini with Pi3B+ and the second one is also on Duet 3 Mini but with Pi4B. One was running buster based FluiddPI image with all components completely up to date and the second was on the latest MainsailOS, also completely up to date.
I was able to confirm with clean test installations that everything works perfectly again as long as KlipperScreen was not installed. Once KlipperScreen was installed, the same faults started occurring again. The logs show many occurrences of Got error -1 in read: (11)Resource temporarily unavailable. One printer would always hang on FIRMWARE_RESTART throwing the above faults and also TMC stepper_y failed to init: Timeout on wait for 'tmcuart_response' response and similar. The other printer (on Pi 4B) would actually restart most of the time but a few seconds later would crash with loss of communication with 'mcu'.
The even weirder part is that unistalling KlipperScreen would not eliminate the issue, so it has to be one of the many pre-requisite packages that are installed in the process. On the other hand, both printers work perfectly fine again on Bullseye even with the latest KlipperScreen installed. This highly unusual behaviour made me chase my tail for hours last night as I was first convinced that I had a hardware failure, until the second printer started behaving erratically as well.
I attached logs from both printers in case Kevin would be interested in looking at them.
In order to eliminate any unforeseen variables and potential bit rot or cruft, I did a totally clean manual install or Raspbian, starting with 2022-09-22-raspios-buster-armhf-lite.img, updating it to current with apt, installing KIAUH, then Klipper, Moonraker & Fluidd. All current versions. Following these steps the printer was working perfectly normal. I then installed the current version of KlipperScreen (v0.3.1-9-gb96adf5) and the printer immediately started exhibiting the same erratic behaviour during FIRMWARE_RESTART with Got error -1 in read: (11)Resource temporarily unavailable in the logs.
What type of displays are you attempting to connect to your rPi?
When I was setting up a 4" Miuzei HDMI (not DSI) I had some similar problems to what you’re seeing and it took a bit of searching and playing around to get it to work with the ultimate process I found to work was posted here: Hardware known to work with KlipperScreen - #31 by mykepredko
I don’t know if this will help, but if you’re using an HDMI port, this might help point you in the right direction. What I did find is that KlipperScreen can be fairly sensitive to where it is installed in the process.
When I replaced the display with a BTT PI TFT5.0 (a pretty standard DSI display) it worked without any playing around.
I cannot speak for any others experiencing this issue, but in my case both installations use the Waveshare 4.3" IPS DSI screens. My Creality installation has been working with this screen without any issues for about a year. Just like with your BTT DSI screen, these just work “plug an play” on Buster. But they do need some additional massaging in order to work on Bullseye - so much for “progress”.
It is worth to emphasize that once the latest KlipperScreen has been installed, uninstalling it and even physically disconnecting the screen does not restore Klipper functionality - it remains broken.
It is worth to emphasize that once the latest KlipperScreen has been installed, uninstalling it and even physically disconnecting the screen does not restore Klipper functionality - it remains broken .
I saw the same thing - you have to reimage the SD card and start over anytime I had a problem with KlipperScreen.
Where are you getting your rPi OS images? I stuck with the Raspberry Pi Imager and used the preconfigured “Mainsail OS” to minimize my work/provide a base that other people could work with.
The original two installations were based on FluiddPI image and MainsailOS image. The verification check I most recently did by performing a clean manual install was done with an official image pulled from rapberrypi.com.
BTW, my primary motivation for posting this in the first place was two fold:
Make others aware of the issue in case they are experiencing it
Have Kevin offer an opinion on this seemingly “impossible” interaction between KlipperScreen and Klipper, assuming he has time to do so
Alas, this isn’t something I’ll be able to look at.
FWIW, from your description, it sounds like a system package may have been installed which is messing with the serial ports. See the blurb on “ModemManager” at the end of Frequently Asked Questions - Klipper documentation for details.
Thanks Kevin, I figured you’d have no time considering the recent level of activity on GitHub. The reference to ModemManager is interesting - I have not seen it before as it’s “hidden” deep in the FAQ.
I will see if I have some time to experiment and perhaps at least narrow down the potential culprit. Struggling with free time here, and what I do have is taken up by finishing my Voron.
I can now confirm that it is KlipperScreen commit 9fa047e that breaks Klipper functionality on Buster. Not surprising, since the said commit causes installation of 191 (!!!) new packages.
0 upgraded, 191 newly installed, 0 to remove and 0 not upgraded.
Need to get 80.1 MB of archives.
After this operation, 288 MB of additional disk space will be used.
And, really, all it does is installing libmpv-dev…
Additional root cause investigation is above my pay grade.
Thanks for pointing this out. I just read the manpage and mask does make much more sense here as we are effectively wanting to permanently disable ModemManager. I will revise my post on GitHub as well.