F/R: Print queue mode once a gcode is uploaded to OctoPrint

[6ffm70]

Background
The printer is used by multiple users "the uploaders" who upload gcodes to OctoPrint via VPN as they are not physically near the printer. The person in possession of the printer "the attendant" then initiates the print locally.

Problem
The attendant needs to know

1. which spool to use
2. how to plan prints in case he wants to have an eye on the printer while printing
3. how to prioritize prints if there are more than one waiting in the queue
4. what he will actually print
5. who uploaded the gcode/whom to hand over the printed parts
6. when a new job has been uploaded to the queue

Possible Solution
Every gcode uploaded to OctoPrint is automatically listed in the PrintJobHistory, albeit with a label ("queue" or "unprinted" for example) to distinguish it from finished jobs.

1. the spool may be entered during upload or parsed from the gcode comment (see Populate Spool... fields from PrusaSlicer gcode comments #58)
2. the calculated duration of the print from the slicer could be shown here
3. a comment from the uploader could be recorded here in case they have a priority; like desired completion time
4. the screenshot from the PrusaSlicer files could be shown here
5. OctoPrint user name here

Bonus Solution

6. Screenshot and queue number could be sent by Signal text here, just like with https://github.com/aerickson/OctoPrint_Signal-Notifier, but with a separate receiver

[6ffm70]

One addition to the problem: the tool, ie. nozzle diameter is relevant as well

and one on solution 3.): we send the gcode from the PrusaSlicer interface; ie. a browser popup would not be shown, as the OctoPrint UI does not have to be open. One could either comment in the latter, or add comments in PrusaSlicer to #PrintSettings #Notes which could then be parsed from the gcode:

The comment function could also work for ; filament_vendor mentioned in #58; though then commented in the filament notes, as these would be saved permanently with the filament settings.

[OllisGit]

Wow!!!
Sounds more like a "Preparation-Plugin" instead of a "History-Plugin".
Really nice ideas and the "focus-group" is more a make-space instead of a single "hobby-user" .

Sorry, but for that reasons I am not implementing such features.

Maybe you have more luck, if you get in contact with the [continuousprint] plugin author (https://plugins.octoprint.org/plugins/continuousprint/).

[stale]

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

[6ffm70]

Hello Olli, thank you for feedback! I would not think that the purpose of your plugin is compromised by that addition; the history of a print job merely starts a little earlier:

• by recognising a print job by a file being uploaded
• by adding a third status -queued- to the job besides success and failed

The rest of the (sub-)features would be optional.

[OllisGit]

hmmm...if you use the "delete after print plugin", then every other existing printjob in the filemananger is in status "queued" ;-)

From implementation side it shouldn't be a big deal to listen on the "file added" event and then create a History Entry.
But from user experience there needs to be more to implement, e.g. (re)print out the Job-Dialog and I am not yet convinced that many will use this queuing function ("implementation effort vs. business value").

[6ffm70]

Haven't thought about it that way. We just leave the printed files on the Raspi-SD; and the only ones that get reprinted are the heat towers. Though, I understand that there are as many different workflows as there are users.

Looking at the original F/R, from a functional point of view, the main use would be the ability to comment on a print before the print was started. This may also be useful to other users who upload a bunch of files, and want to comment on them to find the right file later; ie. a series of tests to find good print/design parameters. In that case, the pre-print-comments would be useful history content as well.

That wouldn't be a complete queue feature, but already very usable and universal. Prints could be started from the Octoprint file list as usual.

I'd love to contribute the code myself, but I'm hopeless combining the functions of two existing arduino sketches already..

[OllisGit]

Suggestion: As a first step I will look how much effort it takes to create a "file add" listener to create a history entry.
This feature could be enabled/disabled (default: disabled).
Next step is to create the "reprint" feature out of the edit-dialog.

[OllisGit]

fyi: the add feature is implemented and the "reprint-feature" is scheduled in the project board (long-term):

https://github.com/OllisGit/OctoPrint-PrintJobHistory/projects/1#card-45793778