[BUG] Emergency Stop button periodically engaged on KlipperScreen

[cruiten]

What happened?

It appears that the Emergency Stop button is somehow pressed even though no one actually pressed the Emergency Stop on KlipperScreen because it is displaying the confirmation to proceed for the Emergency Stop. Luckily my configuration requires a confirmation for Emergency Stop, or else the printer would go through the full Emergency Stop process.

This happens quite frequently. It happens during printing and it happens when the printer is just sitting idle.
I am the only person in my home office and I know that I did not press Emergency Stop.

Nothing reflects an Emergency Stop in Mainsail UI.

What did you expect to happen instead?

KlipperScreen's Emergency Stop workflow should only start when the Emergency Stop button is pushed.

How to reproduce this bug?

Unable to trigger this problem by doing anything, it just happens sporadically.

Additional information:

Voron V2r4 with RPi 4b 8GB.
BTT TFT50 display screen.

Log output

uname -a output: Linux voron 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

moonraker (12).log
klippy (52).log

[alfrix]

most likely this is not a bug of klipperscreen, the estop button is only connected to the "clicked" event (a touch also counts), so the only way it will trigger is with a press of the button, the culprits could be various like a kid, a cat, the enclosure, i've seen enclosures that are made too tight that generate ghost presses, or even a defective screen or cable, if you are not convinced install a desktop variant of the operating system and do the same test of leaving it for a while, and i'm sure you will see the ghost touch again, you are barking at the wrong tree here.

[cruiten]

I built this printer back in July of 2022 and this behavior just started this year. I have not changed the screen enclosure.

No other humans or pets are in the room when this occurs, just me.

I suppose that this could be triggered by a defective cable, or the TFT50 going bad, so I will try to start by replacing the cable that connects the TFT50 to the RPi.

Incidentally, it just happened again as I am typing this on my other computer, and there was no one else or anything else in my office...

I hope that replacing the cabling will resolve this problem for me.

Thank you for getting back with me. I do appreciate it.

[alfrix]

maybe try an older version of the OS, or without base system updates

i'm suggesting that because i have a screen connected via GPIO (crap i know), and the update to the kernel 6.6 broke the touchscreen functionality, it did work but very unresponsive, the issue was that the driver was heavily changed and they broke it, i was able to assert that kernel 6.1 was working correctly and after some back and forth with the raspberry engineers they fixed it in the next minor release, so perhaps could be a software issue, you'll have to try the version of the OS that you did know it was working.

[cruiten]

Hmmm... Back in April I upgraded the OS from Buster to Bookworm and that is when this problem started to manifest itself...

However, if it is related to OS or kernel then I would expect more people to encounter my problem because I know that many people have been running on Bookworm for a while, right?

If I am the only person to report this problem then it makes sense to me that it might be something unique in my environment like a bad cable or TFT50 display.

I can build a new SD Card with Buster to see if I am able to reproduce the behavior that I am seeing on Bookworm. I will do that first because it will be faster than ordering a new display cable and waiting for it to be delivered...