Circumvent "Save" button and auto start Managing

[TereiATmatch]

Hello,

I am trying to set up a fluent process of 3D-printing with our recently purchased Prusa MK3S+ at our institute.
The continuousprint plugin looks like the most promising solution for managing queues.

Unfortunately, there are two issues that overcomplicate the workflow:

It seems like the "Save" button always has to be pressed in the Octoprint interface to add a print to the queue after uploading a file from prusaslicer to octoprint. Is there a possibility to circumvent this behaviour, so that my colleagues and our students can send print jobs from the slicer directly to octoprint without entering the web interface?

There might be an easy solution to this. Maybe branching the plugin and modifying some parts of the code can solve this. I scrolled through the code but I could not find out where to make the changes.

I want to ensure that the queue is always managed by continousprint. In case of a cancelled print I would prefer the queue to proceed directly after the bed clearing was confirmed.

A possibility could be to use the action command (queuego) in combination with g-code. Unfortunately, the prusa framework does not support the M118 command. I could try to add the command to the prusa framework. Besides that, an easier solution would be to enable the managing by a system command. Is that possible? I am also open for other suggestions.

I would be very happy about your support and suggestions for solutions.

Thanks and kind regards
Niklas

[smartin015]

Hey @TereiATmatch - glad to hear CPQ is a candidate for your use case!

Is there a possibility to circumvent this behaviour, so that my colleagues and our students can send print jobs from the slicer directly to octoprint without entering the web interface?

This is already possible, by changing the "Upload Action" setting under the Behavior tab of the Continuous Print Queue settings. If you set it to "Add to queue as an immediately printable job", files that are uploaded will be added to the queue as an already saved job, meaning the printer will start printing immediately as long as the queue is being managed:

I want to ensure that the queue is always managed by continousprint. In case of a cancelled print I would prefer the queue to proceed directly after the bed clearing was confirmed.

In most use cases, "cancel" is typically triggered by a user that's about to stick their hands into the print area - for this reason, CPQ stops managing the queue to reduce the chance of an unexpected movement causing a crash into a part (or a limb). The one exception is cancellation on behalf of Obico, i.e. spaghetti was detected on the print. In this case, CPQ re-attempts that print after running the clearing script.

Could you share more about what events would cause you to cancel a print? Is this something automated, or is it something you can disable for anyone except an admin so that queue management state isn't normally affected?

There is an API option for starting the queue - you can read up on it here. There's currently some trickiness with the parameter to pass (see #135) but you should be able to use that if it helps keep the queue active in your use case.