Failure on toolswap without print running still issues a PAUSE

[spikeygg]

When testing tool swaps (issuing T0, for example) WITHOUT a print running, the software still issues a PAUSE command on failure. I don't think it should, when the printer becomes paused without a running print KlipperScreen goes into a weird state and cannot be recovered from its GUI (separate issue, that was brought to light by this one).

To recover the printer's state, I have to get to the console and issue ERCF_UNLOCK and RESUME.

[moggieuk]

Can you tell me more about the KlipperScreen state. I have never used one but on entering an ERCF_PAUSE, I do format the message as an error (prefixing "!!" as per klipper convention). You should be able to see this in the console output. I'd be interested to see how KlipperScreen handles this. Would love a picture if you have one.

On entering a pause state when not printing, that is an interesting idea. The problem is how to detect whether or not you are printing. It sounds simple but actually Klipper doesn't now the difference between a print job and just running some arbitrary gcode. it could be solved with explicit commands to ERCF to say "print start" and "print end" but that isn't ideal. Any ideas on how to reliably detect?

[spikeygg]

Actually, this may be a non-issue after your description. I figured that klipper would know if it's printing or not with a boolean state. I opened a similar ticket in the KlipperScreen github and it has been resolved with a modification one-liner. I've already pulled this change in and tested it out. It resolved the weird locked screen, otherwise I would get you a screenshot.

Maybe a PAUSE issued when the printer isn't printing isn't a problem. I did include a CLEAR_PAUSE in my PRINT_START a long time ago when I first started using the ERCF because the ERCF at that time would issue several PAUSEs and something would cause klipper to get confused and not actually PAUSE while also claiming that the printer was already paused. I found that the CLEAR_PAUSE command before starting the print usually cleared out that issue. The CLEAR_PAUSE at PRINT_START probably would keep any left-over PAUSE from causing issues.