Print Pause/Resume and Idle Timeout


I wanted to suggest a small tweak to the pause/resume print functionality to resolve an issue with idle time out kicking in if the pause period is longer than the idle time out period.

The issue is that if you pause a print for longer than the set idle time out period, you must first home the printer before you can resume printing. Homing in this situation is impossible however because the unfinished model is sitting on the bed and so the print can’t be resumed and has to be scrapped.

My suggestion is to tweak the core code so that pausing a print will temporarily disable idle timeout (with a notice for the user about this) so that printing can be resumed without the need to (re-)home the printer.

Then, when printing is resumed (or cancelled), idle timeout is set back to its original value.

1 Like
{% if printer.pause_resume.is_paused %}
	#whatever you want
	{% else %}
	{% endif %}
1 Like

Assuming I understand your proposal correctly @TGC , I think that:

  • essentially this is a workaround (or manual fix) for the current functionality which every user needs to implement manually and (a) many users are likely not to be aware of the issue until they run into it at which point it’s too late (I, for one, wasn’t aware of it and as a result the print was scrapped); and (b) many users will not know how to go about implementing the fix even if they are aware of the problem.

  • being a local conditional, another question becomes where/how to include it. The user needs to start thinking about various different use cases and where this local conditional is suitable or not as the case may be. The user will also need to know how to use gcode in macros and how to disable idle_time out temporarily and re-enable it to the previously set value (assuming they’re not using the default period). All this quickly becomes rather complicated for the average user I believe.

My thinking (and therefore original suggestion) is that this tweak be implemented at the core level of the Klipper code precisely to avoid these issues and potentially additional ones.

1 Like

It looks like devs do not want to add macro implementable features.
User still need to learn how to create macros at least for pause/resume/cancel functionality. Klipper default pause/resume do almost nothing besides saving/restoring position. Cancel don’t exist at all.

Code above goes directly to idle timeout gcode.
Alternatively you can add saving time and disabling timeout in pause and restore in resume/cancel.
I prefer first and just disable extruder heater when paused on timeout and reheat on resume.

Yeah, I know how to implement this the way I want manually. That’s not the point of my original suggestion, though. You can, of course, disagree with the idea and think doing it manually is the way to go, but I think it’d be good to keep the discussion in this thread focused on the suggestion itself, it’s potential merits and downsides and so on, rather than ways to do it manually which like I said isn’t the point here.

Well, I agree with @TGC here. You have 3 choices:

  • Convince a developer to spend his time (quite hard if there is a functional macro solution)
  • Do it yourself, remember, its open source
  • Live with the macro solution

Ha? I don’t have any desire to convince anyone or start any argument with anyone for that matter.

That said, and with all due respect, this isn’t about “my choices” at all. I was told this was the place to make suggestions. I made a suggestion. I think it has a solid logic behind it and it makes sense functionally. Plus, this isn’t a proposal for new feature, but a tweak of an existing one.

The purpose of the thread was to highlight the matter and see how useful (or not) other users/developers find it. If the people maintaining the core code wish to implement it, great. If not, that’s fine too. But please @Sineos spare me the attitude and lectures about what I can or cannot do. The fact that someone’s new here doesn’t mean anyone should feel entitled to ‘educate’ them in this manner.

And with the rant out of the way, if anyone has a substantive contribution to make regarding the actual suggestion please join in the conversation. Otherwise, feel free to skip it.

A post was merged into an existing topic: BTT Filament sensor