I am very happy with Octoprint and OctoPi efforts, but now that I have 4 active printers connected with OctoPi, all with NFS Share to the GCode store, all with a Timelapse NFS Store, MQTT to monitor the printers and to start prints. This is all great!
But there are some architectural limitations I am running into with the current structure of Octoprint.
Plugin data is not share-able: It takes a while for a large GCode repo to be scanned by each Pi3, it's results are then saved locally.
EG Slicer Thumbnails, it allows me to show the part printing on the OctoPi 's Dashboard and since I like to glance at each printer display, it would be nice to see it there on the Dashboard.
Resource Management:
Again with shared resources, the RaspPi is not the best tool for GCode Analysis or Timelaspse renders, I have Docker Containers that I can process that offline.
I propose the following changes to OctoPrint's structure:
Folder Paths UI to support Base Path for all other sub Paths, with override check box to allow special paths to be set.
Introduction of 'Shared Plugin Data' path setting for Folders that would support the share of things like the Slicer Thumbnails
Inconsistency correction : When folders are changed, the OctoPi needs to restart for the change to be recognized, this should be a soft event in the event management structure to refreshed. Or for the time being, put a warning on the Folder Dialog that changes are not shown until restart.
Ennoblement or disablement of background tasks: GCode Analysis sucks the life out of a older pi, this would be great if we can do a Pub/Sub management of this process
Timelapse Rendering: again this is a processor, IO and Memory intensive task for a Raspberry Pi, options for generating events for render start and complete over the Pub/Sub would be greatly appreciated for advanced users.
Timelapse TMP Folders on NFS: For the life of me, I have not got the frame captures to be stored on NFS, the folder setting does not seem to work for me.
Python is not my best forte, but I have hacked a few AI scripts out of it, but my best skill is that in Architecture and Integration, and this is why I am trying to sell more PUB/SUB into OctoPrint task management where it becomes the Edge Compute module to feed and interface the printers where we establish a command and control system that in my farm, I can knock out a multi part build from my 'Control Room'
Oh and I've been coding a Swagger 2.0 for the Rest API, it would be nice to farm this out and collaborate on it as it too simplifies the integration of good tool.
Any thoughts? Is there a architectural design considerations for core Octoprint that need to be done?
Depends on how you are linking your NFS. It;s probably not recommended but you can symlink OctoPrint's basedir folder and then all printers would share all the same stuff.
Also, now that you have multiple printers you may want to check out OctoFarm. It is being actively developed and is designed specifically for your use case, managing multiple printers.
Definitely not recommended and as it stands I doubt it will ever be implemented. It's better to keep each machine independent so that if there is an issue only one machine is affected rather than every machine. If you ran a farm of lets say 10 printers doing a 20 hour job and one glitched and caused all 10 printers to also fail you just lost a days pay and are now backlogged. If keeping machines consistent in config is a requirement (which makes sense to me) I would invest some time in automation tooling. OctoFarm may do this already but I'm not sure.
Not necessarily config, but shareable resources. Again, Slicer Thumbnail is a object that is stored in the Config/Data path, but it is a shareable resource that is exposed as a HTTP source, like GCode Analysis and other time consuming tasks, these items could be in a shared resource area and shared with Like systems. Other config items, should not of course, I wouldn't want all of the printers named the same (But a pattern named system yes)
And trust me, having to do things only once is wonderful, dropping GCode in a share is a lot better than (Did I upload that file to that Instance)
I am using OctoFarm now thank-you, it's useful in managing sets of printers, but again I am avoiding filling up SLOW SD cards in favor of NFS Mounts. Even when the Server restarts it pauses the printer for a minute, the joys of using a Linux System and maturity over CIFS
OctoPrint streams the gcode from the file, rather than reading it all at once, so ideally you would keep a local copy of the file for reliability over using the network for every file read (which I imagine would also be slower than an SD card). With OctoFarm, I think there is a lot of work going on for more centralized file management where the file is automatically sent out to the printers when needed.