Milestone: Single-step LAN printing from 3D model

[smartin015]

Is your feature request related to a problem? Please describe.

Slicing is still quite manual - slicing for LAN queue printing especially so (maximally requiring one gcode file per type of printer registered in the queue). It would be great to not have to do a bunch of manual work just to get the file into the automated queue.

Describe the solution you'd like

From a 3D modeling program it should be possible to perform a single action which:

1. Exports an STL file version of the model (implemented pretty much everywhere already)
2. Submits the STL as a job directly to the LAN queue
3. Lands the STL-based job on a printer on the network
4. Auto-orients the model in a way which prints reasonably well (per printer in the LAN queue)
5. Slices the STL into a .gcode file compatible with the assigned printer, when it's assigned.

The printer then prints the generated gcode. This is conceptually the same as submitting a job to a compute cluster (e.g. Kubernetes) - you tell it a bit about how to run the job, and the cluster figures out what host machine is a good choice to run it with minimal user specification.

While I want this for my own setup (Jupyter-CADQuery modeling, sliced by Kiri:Moto CLI and uploaded via python script), each step in the process should be minimally coupled so that the solution can be adapted to other slicers / environments.

Describe alternatives you've considered

For most users, hooking into the drag-drop upload process is probably best.

1. User drags in STL file, it ends up in the file list as *.stl, with auto-add behavior operating as configured.
2. When it's time to print, the printer orients+slices it.
   • Same process for LAN - the printer that's about to do the work does the slicing.

For users that want even more control, the "add job" API should allow for specific queue assignment. In this case, auto-add behavior should be turned off and the API used directly instead.

Additional context

User journeys:

• User wants to set up a cluster of printers
• User wants to specify a specific way to slice things for a particular printer
• User wants to get an STL printed ASAP
• User wants an STL printed, with restrictions on color / other attributes

Auto-orientation can be done with Tweaker-3, but it currently lacks support for belt printers - this is a huge gap when it comes to continuous printing. I opened https://github.com/ChristophSchranz/Tweaker-3/issues/24 to add support for this.

Slicing can already be done via Kiri:Moto CLI for a bunch of printers. I'll likely follow that route.

See #80 for gcode profile inference - this is the qualifier on step 4 above.

Expected implementation flow:

• [ ] Complete #80 to prevent misprints on the wrong printer
• [ ] Extend Tweaker to support belt printers
• [x] Write a simple script to calculate orientation for a single STL file and printer profile
• [x] Extend the script to also slice the STL at that orientation, with a slicer profile
• [x] Report subprocess state via the progress bar in the main UI as the STL slices
• [x] Write a directory-watcher script that ingests STL files from specific dirs, runs the orientation/slicing script, and ships the output gcode files off to the continuous print (local) queue.
• [ ] Extend CPQ to enable gcode submission to specific queues, then update the directory-watcher to submit straight to the LAN queue.
• ~Convert to a nested drop-down to select custom slicer profiles. Users can upload slicer files through the settings page ("upload slicer file" button/flow) and they get synced to all networked printers.~

[smartin015]

Status update:

• Tweaker belt support is requested at https://github.com/ChristophSchranz/Tweaker-3/issues/24
• Automatic STL slicing is now released in https://github.com/smartin015/continuousprint/releases/tag/2.4.0, no added scripting required. Slicing profiles are set up per-printer.
• OctoPrint has a file watcher built in; #107 tracks queue auto-add support for this. That may require a CPQ behavioral setting to pick the queue the watcher uploads to.
• Profile inference is almost at a "good" state, just need to get an update from Cura folks so I can implement printer profiles in their header.
• Still need to change the API to support submission to specific queues. I broke this out into #215 to track implementation.