Shedulet print starts immediately after non sheduled print is completed

[LupusTheCanine]

I have had at least two instances of Print Scheduler starting another print right after non-scheduled print completed.

Steps to reproduce.

1. Use "M80" G-code action to turn on the printer (it fails for whatever reason)
2. Manually start a print
3. Manually started print completes and the scheduled print is started leading to a crash.

[jneilliii]

1. Use "M80" G-code action to turn on the printer (it fails for whatever reason)

If your printer isn't powered on and connected to OctoPrint then this is actually expected because there is no connection to send the M80 command to the printer over USB. There is nothing I can do about that.

3. Manually started print completes and the scheduled print is started leading to a crash.

Was it a print that was scheduled to happen between the time you powered on the printer and the manually started print completed? That would be expected in this case, because the plugin has no checks for bed clearing, etc.

[LupusTheCanine]

Was it a print that was scheduled to happen between the time you powered on the printer and the manually started print completed? That would be expected in this case, because the plugin has no checks for bed clearing, etc

No, print was scheduled to start at 8:00, at around 8:20 I noticed that it didn't start and manually powered up the printer and started the print. After the print was finished, another print started and crashed the printhead into the prints.

[jneilliii]

Have you confirmed the timezone/date and time settings are correct on your pi? What you describe is kind of what I would expect for a missed scheduled print. The plugin checks every minute on a loop and will start any that are earlier than when it checks and is not printing. To troubleshoot further it would benefit having debug logging enabled for the plugin in OctoPrint's logging settings and that will save some additional information to octoprint.log to diagnose.

Like I mentioned before, the plugin doesn't have any way of knowing if the bed is clear or not and ready to go. If you have a camera you could utilize my Bed Ready plugin and add an additional line to your slicer's start gcode to check the bed prior to starting.

[LupusTheCanine]

1. I don't use RPi
2. My clock appears to be set up correctly, at least when looking at PrintJob History.

[jneilliii]

1. I don't use RPi

The underlying OS doesn't really matter, what matters is local time is correct. If you are running any linux variant, this may be helpful in verifying. https://linuxize.com/post/how-to-set-or-change-timezone-in-linux/

[LupusTheCanine]

1. I don't use RPi

The underlying OS doesn't really matter, what matters is local time is correct. If you are running any linux variant, this may be helpful in verifying. https://linuxize.com/post/how-to-set-or-change-timezone-in-linux/

Time, date and timezone are set correctly

[jneilliii]

Yeah, so the plugin is working as expected. It's even called out in the warnings on the plugin listing and the readme here that this is something to look out for.

WARNINGS:

• This plugin currently only has knowledge of your printer’s state. If your printer is showing operational in OctoPrint, the next scheduled print job will run even if something is on the bed. Take caution when adding multiple prints to the scheduler for this reason.

Using something like Bed Ready or Bed Check AI plugins to avoid this is the only thing currently available. I could potentially add a pre-print confirmation prompt on the OctoPrint UI side, but that ends up defeating the purpose of scheduling prints if it requires user interaction.

[LupusTheCanine]

Yeah, so the plugin is working as expected. It's even called out in the warnings on the plugin listing and the readme here that this is something to look out for.

WARNINGS:

• This plugin currently only has knowledge of your printer’s state. If your printer is showing operational in OctoPrint, the next scheduled print job will run even if something is on the bed. Take caution when adding multiple prints to the scheduler for this reason.

Using something like Bed Ready or Bed Check AI plugins to avoid this is the only thing currently available. I could potentially add a pre-print confirmation prompt on the OctoPrint UI side, but that ends up defeating the purpose of scheduling prints if it requires user interaction.

The warning states that next print job will happen, not that any previously scheduled job that wasn't already started will be started. This is different. I wouldn't have an issue if I started a print manually at 5:00, it completed at 7:00 and PJS crashed my printer at 8:00 when the print was scheduled to start. The issue is that any not yet started job will be started.

If job fails to start, maybe within 5 minutes, the task should be considered failed and a message displayed to the user.

[jneilliii]

The warning states that next print job will happen, not that any previously scheduled job that wasn't already started will be started.

Fair point, your interpretation of next scheduled print job is probably more accurate than what I meant, which was next job in the list that is in the past.

You're idea of a timeout is something I'd consider to integrate, thanks for the suggestion.