OctoKraken - Multi printer/multi gantry project

Development
1

Hi all,

I am working on a multi gantry project (multiple print heads that move/print individually on the same model),that I would like to implement and would like to get some community feedback on my thoughts. The title already indicates that the project kind of spans across 2 areas, using OctoPrint with multiple printers and also using OctoPrint to manage a multi gantry printer. Sorry if this post gets a bit long, but I hope it explains the concept well enough.

I have come across project Escher from Autodesk to manage a multi gantry printer but the licence of Netfabb comes at a steep price... so I would like to create a fully open source project which uses the normal software that we all already use (Modeling, splicing, firmware). While delving into the topic of multi gantry printers, I have come to the conclusion that OctoPrint could offer the basic needs when combined with plugins and a "conductor" (Autodesk definition of a communication link between each print gantry). The conductor would be the "OctoKraken" that manages each OctoPrint instance (Kraken being the mythological far bigger relative of an Octopus).From a function perspective, a multi gantry printer has a lot of similarities with running multiple printers, thus I believe the OctoKraken project could be ideal for that too.

Ill try to explain the basic idea of the project, starting with 2 "diagrams" of the 2 scenarios, multiple Printers and multi gantry printers. I will then go into more detail after the basic diagrams.

1) Basic printer/software setup

1.1) Multiple Printers
This is a familiar setup where multiple instances of OctoPrint are installed on 1 device e.g. raspberry pi. Currently one needs to setup each instance via the Terminal and manage the plug-ins and connections in each instance separately. OktoKraken would be used to centrally install each instance of OctoPrint and offers links to the webinterface of each OctoPrint without the need of remembering all those port numbers.

Network
+
+-OctoKraken 1 (eg RaspberryPI 1)
+  +
+  +- OctoPrint 1 -> Printer 1
+  +- OctoPrint 2 -> Printer 2
+  +- Octoprint 3 -> Printer 3
+
+-OctoKraken 2 (eg RaspberryPI 2)
   +
   +- OctoPrint 1 -> Printer 4
   +- OctoPrint 2 -> Printer 5

1.2) Multi gantry Printer
In a multi gantry printer the print bed is stationary while each gantry individually moves on the XYZ axis. Each gantry is setup with its own hardware & firmware (Marlin) just like a normal printer would be. Just as in the multiple Printer scenario in 1.1 each gantry is managed by its own OctoPrint but they communicate via OctoKraken with each other. OctoKraken also manages the gcode files and splits them up for each gantry via plugins.

A multi gantry printer is a bit more complex compared to normal printer setup (shared heated print bed, filament management, tool changers etc.), but with appropriate OktoKraken plugins one could solve this in a way that the entire concept of OctoKraken can be used for multiple Printers and multi gantry printer.

A multi gantry printer will probably also be printing far larger objects with huge gcode file sizes. It would be good if OctoKraken can also asign OctoPrint to specific CPU cores if installed on a server.

Network
+
+-OctoKraken 1 (Server of multi gantry printer 1)
+  +
+  +- OctoPrint 1 -> Gantry 1a
+  +- OctoPrint 2 -> Gantry 2a
+  +- Octoprint 3 -> Gantry 3a
+
+-OctoKraken 2(Server of multi gantry printer 2)
   +
   +- OctoPrint 1 -> Gantry 1b
   +- OctoPrint 2 -> Gantry 2b

2) Software

OctoKraken is basically a stripped out version of OctoPrint with added functions. On initial installation of OktoKraken one can specify how many OctoPrints will be installed and OctoKraken will do the installation for you. There will be plugins which are specific to Octokraken or OctoPrint and others could be used both on OctoPrint and OctoKraken. The following functions would be built into OctoKraken.

  • Setup wizard to manage multiple OctoPrint (installation of multiple OctoPrints instances)
  • Central communication handler to OctoPrint

2.1) OctoKraken specific plugins
plugins which only OctoKraken would use

  1. Central OctoPrint plugin manager - with this plugin one could install any OctoPrint plugin on all the OctoPrint instances managed by OctoKraken.
  2. Print status plugin - a plugin that shows all connected OctaPrint statuses & printer head positions.

2.2) General plugins for both OctoPrint & OctoKraken
These plugins can be used 1:1 in both OctoPrint and OctoKraken without code change

  1. Central file management - Uploading & removing files can be managed centrally via OctoKraken and/or OctoPrint using a central file management system. This allows the files to be accessible to any OctoPrint. instance
  2. Gcode post script editing plugin - This plugin can load various plugins that edit the uploaded gcode. Post script editing could be used to add a purge tower on tool changes, split gcode for a multi gantry setup, add printer specific start & end code...
  3. Database framework - Due to the complexity of some post editing scripts and further centralization of multiple OctoKraken networks a database system would be useful. Gcode and printer setup can be saved in a database and could be edited from there on. In a multi gantry system there is no need to save multiple gcode files as one could easily communicate which parts of the database get printed by which gantry. OctoPrint, OctoKraken and plugins should share the same database commands independently from what database preferences the end-user has, thus framework(MySQL, sqlite, PostgreSQL ...)
  4. Conductor plugin- The conductor plugin is used on multi gantry printers and keeps track of gantry movements and send commands to each OctoPrint and manages common hardware e.g. heated print bed etc.

2.3) OctoPrint specific plugins
plugins which only OctoPrint requires in a setup with OctoKraken

  1. Communication handler for OctoKraken - plugin to enable OctoKraken to communicate commands to OctoPrint. This could be anything from start printing file to getting print status, print head position etc.

I think a project like this could add value to anyone connecting multiple Printers to OctoPrint. I have tested splitting gcode into multiple parts as a PoC for a multi gantry printer and it can be done with a post script editing process. I like the idea of combining that with OctoPrint to make it an even more powerful tool, especially considering all the plugin options that already exist

Any thoughts? Questions?

Thanks

3 Likes
2

This is a very cool project. Honestly, it also strikes me as having a high entry point from the standpoint of cost so initially, you would likely be the only person developing this for some time.

  • Personally, I would dedicate one Raspberry Pi 3B per gantry and per OctoPrint instance. I would consider then adding an additional master Raspberry Pi 3B which then orchestrates everything.
  • I would split the heating of the common print bed into slices which reasonably match the corresponding gantry's extent.
  • I would write the gating/control mechanism which I described here in this thread last year
  • I would consider the use of remote GPIO so that the master can control individual things on an individual gantry like lights, perhaps
  • Take a look at the collection of Markdown documents in my own e-mc2 project for installation strategies for multiple-Raspi setups
  • I think I would dedicate a small Ethernet switch for inter-Raspberry communications
  • I would probably have one webcam per gantry
  • Something possibly needs to split paths which extend past the gantry boundaries. You could either do this in realtime, during the slicing phase or even before that. Another way to think about all this is gantry=color. Just like a multi-head printer might need to identify different colors and then to direct them to different tool ordinals in a single printer, you might be able to slice this into an n-tool print job. Then at the moment of truth, the master node will redirect tool n to gantry n instead. So it sounds like it would be great if your slicer could simply mark gantry region by color as an initial step and then allocate tools zero through Nmax from left to right.
  • It would be great to re-use all this equipment to print a hundred small parts at once, simply tiling the gantry zero's print job to all other gantries, say.