Given your need for managing large farm of different printers and also presented having Kanban system in place, I can't help but recommend taking a step back and looking at a bigger picture, where between physical Kanban tabs/cards in printed parts inventory and automatable printer farm you could see that this setup discrepancy might be improved with a bit more of automation.
What I propose for future of this part of this project may seem convoluted and elaborate, as it involves splitting what farm-upload is right now into "printing clients" for computers either locally managing or feeding G-code to a local group of the same make/model/setup ("type") of printers, and "server(s)" for keeping track of print files, queues and statuses.
While currently it may seem excessive, it would allow for more flexible research and development in several areas:
With each type of printer handled by a different client, it would be more resource-efficient to handle downtimes, queues for each print, and print order deployments, where keeping track of all the G-code files for each printer setup for each part is a responsibility of the server, while overseeing print jobs and per-printer queue/status signaling is a job of each client.
Upon such demarcation of responsibilities, and associated clearly defined server-clients communication protocol, preferably with formally written specification, changes for client that would be needed to support a previously unsupported printer (e.g. due to its limitations or additional features in control signalling or networking) would not need to be propagated to other clients to keep them up do date when working with their printers, reducing CI/CD costs (including unnecessary downtime) and enabling forks dedicated to support more capricious printers, transparently to server or other clients. To drive this point to its extreme conclusion, I would not be surprised if in a few years past first stable release of this protocol a printer company decided to released a model featuring built-in client for this "Opulo Link™", allowing for farm-scale operations in a smaller overall footprint.
What started this idea in the first place after watching associated video on this subproject, is that implementation of Kanban currently used by you might as well be displaced by system where low item count in printed parts bin could be directly signaled to inventory/printing system to automatically prepare and manage priority in queue based on e.g. usage history and pre-applied weights of priority for each part. If not for general inventory management system, this task could be taken by this subproject as well, with a piece of software to turn barcodes printed underneath each parts bin and scanned upon low count into weighted orders that could be called "inventory client", of which each manufacturing group or station could have a setup for themselves for even more scale-out scalability.
Moreover, with server keeping track of ordering, printed inventory, and printer's metrics, this common source of real-time telemetry information from throughout the cycle could be further processed to adjust priority weights and derive knowledge for further manufacturing processes optimization.
Who says this "Link™" should only be for managing 3DP in manufacturing? The deeper I think about implications of what I'm posting about, the more a question/idea of writing a demonstrative client(s) for OpenPnP and whatnot to accompany a demo server come into place, even if "just" for demonstrating the flow of having a dashboard to watch a single Lumen's realtime status from a dashboard, that is also counting boards and is expandable to potentially thousands of machines, where each switching of PnP jobs is as easy as having a higher priority job on server, parts ready to feed and signaling a blank board selection change to that Lumen's operator between jobs, which can be fool-proofed with blank board recognition.
I hope that this is not too much, and that we could have a fruitful discussion on this undeniably ambitious proposal.
Given your need for managing large farm of different printers and also presented having Kanban system in place, I can't help but recommend taking a step back and looking at a bigger picture, where between physical Kanban tabs/cards in printed parts inventory and automatable printer farm you could see that this setup discrepancy might be improved with a bit more of automation.
What I propose for future of this part of this project may seem convoluted and elaborate, as it involves splitting what
farm-uploadis right now into "printing clients" for computers either locally managing or feeding G-code to a local group of the same make/model/setup ("type") of printers, and "server(s)" for keeping track of print files, queues and statuses.While currently it may seem excessive, it would allow for more flexible research and development in several areas:
With each type of printer handled by a different client, it would be more resource-efficient to handle downtimes, queues for each print, and print order deployments, where keeping track of all the G-code files for each printer setup for each part is a responsibility of the server, while overseeing print jobs and per-printer queue/status signaling is a job of each client.
Upon such demarcation of responsibilities, and associated clearly defined server-clients communication protocol, preferably with formally written specification, changes for client that would be needed to support a previously unsupported printer (e.g. due to its limitations or additional features in control signalling or networking) would not need to be propagated to other clients to keep them up do date when working with their printers, reducing CI/CD costs (including unnecessary downtime) and enabling forks dedicated to support more capricious printers, transparently to server or other clients. To drive this point to its extreme conclusion, I would not be surprised if in a few years past first stable release of this protocol a printer company decided to released a model featuring built-in client for this "Opulo Link™", allowing for farm-scale operations in a smaller overall footprint.
What started this idea in the first place after watching associated video on this subproject, is that implementation of Kanban currently used by you might as well be displaced by system where low item count in printed parts bin could be directly signaled to inventory/printing system to automatically prepare and manage priority in queue based on e.g. usage history and pre-applied weights of priority for each part. If not for general inventory management system, this task could be taken by this subproject as well, with a piece of software to turn barcodes printed underneath each parts bin and scanned upon low count into weighted orders that could be called "inventory client", of which each manufacturing group or station could have a setup for themselves for even more scale-out scalability.
Moreover, with server keeping track of ordering, printed inventory, and printer's metrics, this common source of real-time telemetry information from throughout the cycle could be further processed to adjust priority weights and derive knowledge for further manufacturing processes optimization.
Who says this "Link™" should only be for managing 3DP in manufacturing? The deeper I think about implications of what I'm posting about, the more a question/idea of writing a demonstrative client(s) for OpenPnP and whatnot to accompany a demo server come into place, even if "just" for demonstrating the flow of having a dashboard to watch a single Lumen's realtime status from a dashboard, that is also counting boards and is expandable to potentially thousands of machines, where each switching of PnP jobs is as easy as having a higher priority job on server, parts ready to feed and signaling a blank board selection change to that Lumen's operator between jobs, which can be fool-proofed with blank board recognition.
I hope that this is not too much, and that we could have a fruitful discussion on this undeniably ambitious proposal.