Closed Grea5eMonkey closed 1 month ago
It immediately resumes printing un-commanded.
My guess would be something else is messing with the command (probably a racecondition). Good spot as it's undesired behaviour.
Do you have the KlipperScreen.log
from /var/log/
still available?
I think something is messing with pause state and calling the Klipper internal pause function rather then the PAUSE
Macro. That could mess with the state.
I did quite a lot of manual Pause, Filament Runout, M600 Filament change testing for the latest features that I added. Also pausing the print from KlipperScreen, I did not notice such issues. But we fixed/improved a couple of things that could help.
Does you Slicer use any M25 commands? Did you enable the pause_on_runout
for the sensor? These things are properly configured with the next release.
Klipper internal pause function
def print_pause(self, callback=None, *args): logging.debug("Sending printer.print.pause") return self._ws.send_method( "printer.print.pause", {}, callback, *args )
Looks like it. Is there a way to change the default pause behaviour in klipper?
Looks like it. Is there a way to change the default pause behaviour in klipper?
Is that what is called for the the KlipperScreen pause button? Seems to be part of the Moonraker API: https://moonraker.readthedocs.io/en/latest/web_api/#pause-a-print
I assume Moonraker internally sends the PAUSE
macro, not M25
. For testing you could edit the PAUSE macro in client.cfg and add `RESPOND TYPE=echo MSG="
KlipperScreen actually recommends adding a PAUSE macro, therefore I think it already uses it. https://klipperscreen.readthedocs.io/en/latest/macros/#pause
I think the pause state must have been broken through some other action. Either by the runout sensor or M25. But that's all fixed on master. Also see https://github.com/xblax/flashforge_adm5_klipper_mod/issues/82
It's moonraker of course not klipper :facepalm: . I find it very annoying they named the variable for the class klippy instead of moonraker while it uses the MoonrakerAPI class.
Update: This doesn't seem to be an issue anymore with v00.04 beta!
When I pause a print from the touchscreen, the head moves to the back-right corner and the bed moves down as expected, but does not stay there. It immediately resumes printing un-commanded. (Pausing via Mainsail doesn't do this.) Once the print resumes, it doesn't look like a resume command actually registered. Trying another pause command from the screen results a console message along the lines of "print already paused."
Side note in case it's related, I have added the E1 sensor in printer_base.cfg and enabled it and the filament runout sensor. It does do a normal pause when the runout sensor is triggered. I'll try disabling both for my next print just in case. Just thought I'd post this here in case anyone else noticed the same thing.