Auto shutdown not working as expected #53

Closed
opened 2017-07-22 07:47:46 +01:00 by DrWatson · 10 comments
DrWatson commented 2017-07-22 07:47:46 +01:00 (Migrated from github.com)

This plugin is great. I use it all the time and it's nice to know my printer will shut down after I have gone to bed! ;-)

I understand how auto shutdown works, but there is a pretty common scenario where it does something unexpected. Say, you have auto shutdown set for 500 seconds after print completes. These steps will cause a problem:

  1. Start a print
  2. Get a bad first layer
  3. Cancel print job
  4. Correct problem
  5. Restart print job
  6. Job is running fine until 500 seconds after the first cancel of print job in step 3

If you are using it to turn the PSU on and off (which is a fairly common set up), your second print job will fail because the shut down. You can manually start up the PSU again, but by that time the print has been messed up and things are out of sync.

Is it possible to cancel the outstanding shut down timers when a new job is started?

This plugin is great. I use it all the time and it's nice to know my printer will shut down after I have gone to bed! ;-) I understand how auto shutdown works, but there is a pretty common scenario where it does something unexpected. Say, you have auto shutdown set for 500 seconds after print completes. These steps will cause a problem: 1) Start a print 2) Get a bad first layer 3) Cancel print job 4) Correct problem 5) Restart print job 6) Job is running fine until 500 seconds after the first cancel of print job in step 3 If you are using it to turn the PSU on and off (which is a fairly common set up), your second print job will fail because the shut down. You can manually start up the PSU again, but by that time the print has been messed up and things are out of sync. Is it possible to cancel the outstanding shut down timers when a new job is started?
vitormhenrique commented 2017-08-07 19:25:51 +01:00 (Migrated from github.com)

I'll fix this issue on next release.

I'll fix this issue on next release.
elfhelmp commented 2017-08-16 15:09:53 +01:00 (Migrated from github.com)

This happens to me as well, I have the printer's PSU routed through a relay switch and RPI is powered from a separate PSU. Thanks for looking into it, please update this thread when you have updates. Props for the addon, it works fantastic otherwise!

This happens to me as well, I have the printer's PSU routed through a relay switch and RPI is powered from a separate PSU. Thanks for looking into it, please update this thread when you have updates. Props for the addon, it works fantastic otherwise!
Axel-Germany commented 2017-10-08 17:04:48 +01:00 (Migrated from github.com)

I love that plugin and I have the same problem. I use a Pi Zero and I have auto shutdown disabled

I love that plugin and I have the same problem. I use a Pi Zero and I have auto shutdown disabled
lewisd32 commented 2017-10-28 19:49:02 +01:00 (Migrated from github.com)

I have the same setup as @elfhelmp mentioned, and I've lost track of how many prints have been destroyed due to this. :( Other than that, I love the plugin!

One additional quirk I've found:
If I reconfigure the plugin not to shutdown after a print, if I do that after a print, it'll still shut down.
For example:

  1. Finish a print (the 500 second shutdown counter starts now)
  2. Reconfigure the plugin to not shutdown after a print.
  3. Start a new print job.
  4. 500 seconds after step 1 the printer shuts down.

I think disabling a shutdown timer in the config should cancel any that are pending.

I also wonder if starting a new print should cancel any pending scheduled things? Is there any scenario where that would be undesirable?

I have the same setup as @elfhelmp mentioned, and I've lost track of how many prints have been destroyed due to this. :( Other than that, I love the plugin! One additional quirk I've found: If I reconfigure the plugin _not_ to shutdown after a print, if I do that after a print, it'll still shut down. For example: 1. Finish a print (the 500 second shutdown counter starts now) 2. Reconfigure the plugin to _not_ shutdown after a print. 3. Start a new print job. 4. 500 seconds after step 1 the printer shuts down. I think disabling a shutdown timer in the config should cancel any that are pending. I also wonder if starting a new print should cancel any pending scheduled things? Is there any scenario where that would be undesirable?
lewisd32 commented 2017-10-28 21:09:35 +01:00 (Migrated from github.com)

I'm a software developer (though not in Python) so I thought I would look through the code and see if I could understand enough to submit a PR for this. I found a couple interesting things while I was doing that.

From the code, it looks like it already tries to cancel any scheduled job when a print starts?
https://github.com/vitormhenrique/OctoPrint-Enclosure/blob/master/octoprint_enclosure/init.py#L642-L643

        if event == Events.PRINT_STARTED:
            map(scheduler.cancel, scheduler.queue)

From reading the Python docs, I wonder if the reason this doesn't work could be because of the scheduler.run() in elif event in (Events.PRINT_DONE, Events.PRINT_FAILED, Events.PRINT_CANCELLED): ?

The docs (https://docs.python.org/2/library/sched.html#sched.scheduler.run) say:

Run all scheduled events. This function will wait (using the delayfunc() function passed to the constructor) for the next event, then execute it and so on until there are no more scheduled events.

I wonder if after a print finishes, the scheduler.run() sits there an runs, waiting the 500 seconds until the shutdown event, and because of that, the if event == Events.PRINT_STARTED: doesn't fire?

I'm a software developer (though not in Python) so I thought I would look through the code and see if I could understand enough to submit a PR for this. I found a couple interesting things while I was doing that. From the code, it looks like it already tries to cancel any scheduled job when a print starts? https://github.com/vitormhenrique/OctoPrint-Enclosure/blob/master/octoprint_enclosure/__init__.py#L642-L643 ``` if event == Events.PRINT_STARTED: map(scheduler.cancel, scheduler.queue) ``` From reading the Python docs, I wonder if the reason this doesn't work could be because of the `scheduler.run()` in ` elif event in (Events.PRINT_DONE, Events.PRINT_FAILED, Events.PRINT_CANCELLED):` ? The docs (https://docs.python.org/2/library/sched.html#sched.scheduler.run) say: > Run all scheduled events. This function will wait (using the delayfunc() function passed to the constructor) for the next event, then execute it and so on until there are no more scheduled events. I wonder if after a print finishes, the `scheduler.run()` sits there an runs, waiting the 500 seconds until the shutdown event, and because of that, the `if event == Events.PRINT_STARTED:` doesn't fire?
vitormhenrique commented 2018-01-22 03:07:07 +00:00 (Migrated from github.com)

I think I fixed this on the dev branch, if anyone can change branches and help me test I would appreciate.

I think I fixed this on the dev branch, if anyone can change branches and help me test I would appreciate.
DrWatson commented 2018-02-01 15:26:01 +00:00 (Migrated from github.com)

I can try and help, I just don't know how to do it. Can you provide instructions for how I can help test?

I can try and help, I just don't know how to do it. Can you provide instructions for how I can help test?
vitormhenrique commented 2018-02-01 17:12:41 +00:00 (Migrated from github.com)

I just changed the entire architecture of the plugin on the development branch, but still need to update the methods to comply with the new model.

I'm hopping by the weekend I'll have a test build ready.

I just changed the entire architecture of the plugin on the development branch, but still need to update the methods to comply with the new model. I'm hopping by the weekend I'll have a test build ready.
vitormhenrique commented 2018-03-01 05:38:56 +00:00 (Migrated from github.com)

I just finished re-writing most of the plugin and implemented this requested feature, tested 95% of the plugin.

If you want to test it out uninstall the current plugin, go to the plugin manager, select get more, and where it says "from URL" use the development branch:

https://github.com/vitormhenrique/OctoPrint-Enclosure/archive/dev.zip

More documentation here:
https://github.com/vitormhenrique/OctoPrint-Enclosure/tree/dev

I'll push this to production after more people test it out.

I just finished re-writing most of the plugin and **implemented this requested** feature, tested 95% of the plugin. If you want to test it out uninstall the current plugin, go to the plugin manager, select get more, and where it says "from URL" use the development branch: https://github.com/vitormhenrique/OctoPrint-Enclosure/archive/dev.zip More documentation here: https://github.com/vitormhenrique/OctoPrint-Enclosure/tree/dev I'll push this to production after more people test it out.
vitormhenrique commented 2018-03-07 16:43:53 +00:00 (Migrated from github.com)

Fixed on 4.0

Fixed on 4.0
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/OctoPrint-Enclosure#53