idle_timout and paused state

[Mimoja]

Many times (e.g. #1522) it has been brought up that the idle_timeout and filament runout induced pause have caused longterm prints to fail.

The expectation for all those cheap, switchbased runout sensors found on the 200-ish euro printers is for them to save your print not ruin them, so the question is for me: how to ensure a safe default behaviour which I personally dont see given here.

A short github search reveals that a significant amount of people just set the idle_timout to large amounts anyways on a pause:
https://github.com/search?q=SET_IDLE_TIMEOUT+extension%3Acfg&type=Code&ref=advsearch&l=&l=
Adding more and hard to test complexity to my printer.cfg does also not seem to be a solution with a low entry bar.

The workarounds with custom idle scripts works but also requires manual knowledge of the issue realistically implying at least one occurency of a failed print.

As this is currently not implemented one way or another it is a breaking change from the current behaviour

This request can be implemented similiar to #4847 by checking the printers state.

I would like to extend the idle_timeout.py to also respect a new pause_timeout parameter which will be applied if the printer is paused.
However this means that the default config of a printer would not show the behaviour requested.
I see therefore two options:

1. Choose the estimated (total?) time of the print + 20% as a default pause_timeout if none is provided (I personally find it reasonable to check on your print after some time)
2. Ignore the paused state alltogether interpreting it as "the printer is not idle, it is printing, just slowly"

The later case would also allow for easy and extended heatsoaking experiments at the beginning of prints where people often manually want to resume the print.

Case 2 would also respect all the {% if printer.pause_resume.is_paused %} .., {% else %} ... scripts which would just never evaluate to true anymore while at the same time introducing a potential safety risk if people were to rely on the idle_timeout for safety. I personally can not come up with such scenario, but I am also a multi-spool print kinda person so maybe I lack the calibration?

One way or another: If I were to implement and test it would it be merged?

[github-actions]

It looks like this ticket is a request for help (or similar). Many helpful people will not see your message here and you are unlikely to get a useful response. Instead, see the contact directions at: https://www.klipper3d.org/Contact.html

We use github to share the results of work done to improve Klipper. We don't use github for requests. (In particular, we don't use github for feature requests, to answer questions, nor to help diagnose problems with a printer.)

Please follow the directions at: https://www.klipper3d.org/Contact.html

This ticket will be automatically closed.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[nordurljosahvida]

Hi, allow me to join into this thread. I have a question for the entire team / community.
I'm new to klipper and either I'm missing something or I must be going completely insane.
In which parallel universe do we ever want a paused print to cool down and release steppers?
This is precisely what we make fun of chinese firmwares about and is the #1 reason we switched to klipper.
why does this poor guy need to ask how to not have his printer cool down during a print? shouldn't it be absolutely and universally true that a paused print must stay in a precisely controlled heatbed-on and motors-engaged state even were it for days on end?
That's exactly what our 12 Prusas do: they run out of filament, or hit a scheduled pause, or heck even collide with something and they just pause, cooling down the hotend but of course not the bed, and steppers stay engaged.
Is there even 1 recorded example in the history of FDM printing where one would want its printer to kill off a print during the print itself?
idle-timeout should only ever be used in one state: when the printer is actually idle.
I'm not sure if all the authors of posts about increasing idle timeout or implementing some complex workaround where the idle timeout during pause is somehow treated differently have a room temperature of 85 degrees C or if I've been doing it all wrong from the beginning.

Thanks for the absolutely amazing work and looking forward to figuring this out together, as they say these days.