Print queue feature request
Opened this issue · 15 comments
Not an issue but a request. It would be ideal for remote management to be able to add a print job to a queue. Once an available printer is finished printing (and auto-ejects part), the software would route the next job in the queue to that printer.
At some point likely sooner than later, it seems Bambu will release its expansion board which will make implementing auto-ejection at the end of a print much easier. Even if Bambu kills the expansion board, it is not difficult to add an auto-ejection system.
While it may possible to have the software manage aspects of auto-ejection, I don't think it is necessary. Simply adding a print file to a queue then routing the file to the next available printer would be a great enhancement.
What would be the trigger? I cant use printer idle as the trigger because that happens roght after finished print...
I'm not sure I understand. Are you referring to a trigger to start the print job or a trigger to auto-eject the part after the print is finished? If is it the latter, that can be accomplished numerous ways, such as have a limit/contact switch/sensor at the extreme end of the Z-axis travel. The G-code would be modified so that after the print is finished, the bed moves to the of the Z-axis travel, triggering the switch/sensor, and initiating an auto-ejection sequence (e.g., controlled by an Arduino/Pi).
If you are referring to trigger the start of the print, perhaps this must be accomplished via a Bambi API (not yet available).
Im referring to starting the 2nd print...
Starting the 1st print is easy (bambu-farm already does this), knowing when the print is done is also easy (bambu-farm already sends a notification)... Knowing when to start the 2nd print is not clear.
So my question is, how do i know the printer is ready to start a new job? How would I know of the ejection system / if the plate has been cleaned & re-installed?
user queues 2 jobs -> printer starts job1 -> printer ends job1 -> SOME STUFF -> printer starts job2
what is SOME STUFF?
OK, thank-you for explaining. I understand the dilemma. My planned implementation may be different than others, but it would have G-code file that is already modified before sending it to the printer queue. So it would be along the lines of:
- Print 1: start printing and continue until finished printing desired object.
- Print 1 (same G-code file): move bed to trigger sensor.
- Print 1 (same G-code file): after sensor trigger, wait X seconds for bed to cool (G04).
- Print 1 (same G-code file): After bed cooling time delay, actuate part ejection routine. Wait X seconds (time it takes to complete ejection routine + safety factor, again using G04).
- Print 1 (same G-code): After ejecting part/time delay, return print head/print bed home. End of G-code file. Proceed to next print in printer queue.
- Print 2: Begin. Repeats steps 1-5 above.
In my application, the bed would not be cleaned between prints. Rather, there would be approximately 3-8 parts printed every 24 hours. The bed would be maintained at 12 or 24 hours intervals (once or twice per day). If this process does not actually work after real experimentation, then the ejection routine will become slightly more complex and use interchangeable printing beds (a supply stack of 3-8 beds) which will be changed after each print. Then the printed parts would be manually removing from each printing bed once or twice per day, the beds cleaned, then returned back to the supply stack.
Even if the latter, more complex ejection routine is required, it should be possible to have it all completed within one G-code file per part. Once the G-code is completed executed, the software assigns the next print. In other words, the application of a queue does not need to be any more complex than assigning the next available print job (first in, first out) to the next available printer. It can be up (and perhaps should!) up to the user to find a way to implement the necessary G-codes modifications, the trigger sensor/switche, programming the microprocessor to control the subroutine, etc.
I appreciate the concerns you raised. It seems that if the bed must be cleaned between prints, then the print farm would require someone onsite, at least more periodically. In such a situation, I would contend a print queue would have much less value as someone is already there (& being paid to work). In my application, there will only be someone onsite once or twice a day (me). IMHO, the value of the print queue is most applicable to more automated operations, such as mine.
Thx for the detailed explanation, this is exactly what i wanted... if you do it as suggested, my part is easy... as soon as printer says im idle, i can send the next print... since that include the ejection logic
Happy to explain it - its the least I can do. Glad your part is easy and I'm grateful for the work you already have done to make this available for others! There are other ways to manage an automated print farm, but I don't think your software should have to accomodate unique needs of each user. It should be up to each user to adapt their setup to work with a simple print queue.
I'm sure Bambu will add native software features for print farms eventually, but my guess is that they are probably focused on the next generation of printers.
Having an MQTT trigger or webhook to restart the following prints could be great for those of us that want to do janky custom automation.
Im working on a simple python script (Well rather ChatGPT is lol) to handle restarting the second print via MQTT direct to the printer, but using your farm interface would be a much cleaner solution.
Using machine vision to detect an empty build plate could be an interestion solution too, even if its just for an additional safety layer
Using machine vision to detect an empty build plate could be an interestion solution too, even if its just for an additional safety layer
That's a great idea!
One thing I recently realized is that although a print queue is great/needed for a print farm, it will also benefit those who just have one printer and want to remotely keep it printing (assuming the printer has an auto-ejection/plate change capability).
Can you please share your "auto-ejection / plate change" implementation details?
If I add this feature, I would atleast like to include details for someone to be able to use it 😄
Yes, but it will be sometime before that is possible as my first Bambu P1S just shipped today. Setting up a print farm with Bambus was my first choice (vs Prusa), but I didn't order one until I was confident I would have some remote capabilities. Your software, as is without the queue, was the tipping point to move forward with a Bambu print farm.
Once the P1S arrives, I will still have much experimentation regarding identifying specific materials, temp/flow rates, part ejection vs bed change (due to required bed prep - if any), part processing method, etc. Also, I'm hoping Bambu release the Expansion Board shortly (already released in beta ~7 months ago) as I would prefer to use that for automation control vs a custom Arduino setup since it should be much simpler and cleaner. Thus, it will be a little while (several months hopefully?) before I setup up a full production farm. However, it the meantime, here is one example of an existing Bambu automation solution:
https://www.youtube.com/watch?v=eZtmPcnxMGs&list=PLlQSQex4opJBbirJ0ooiI9vHU0mug3pKV&index=106
For inspiration, here are non-Bambu automation implementations:
https://www.youtube.com/watch?v=lq9lsUPn36o&list=PLlQSQex4opJBbirJ0ooiI9vHU0mug3pKV&index=101&t=179s
https://www.youtube.com/watch?v=8O9E9rcH6Us&list=PLlQSQex4opJBbirJ0ooiI9vHU0mug3pKV&index=95&t=5s
I'm hopeful to be able to simply auto-eject parts after printing as it would be much simpler to implement and require less space vs. a bed changer., but that is TBD. I made have to develop a bed changer to bed adhesion (or lack of).
I forgot about this other Bambu auto-ejector:https://www.youtube.com/watch?v=K5TBa0UkigA
I haven't looked into it too closely yet, but it may be possible to adapt the JobOx for a Bambu: https://jobox.tech
Given the popularity of Bambu printers, I imagine JobOx will develop a Bambu specific solution.
The best solution is to not even need any actuators to eject parts. One solution is to angle the entire printer and allow the part to slide off due to gravity once the bed cools. This obviously may not work for some filament types, but is available: https://shop.3dque.com/products/printer-automation-kit?variant=43872111722719
On another thread, I mentioned that a printing queue is not just beneficial for a 3D print farm. It is also useful for any with a single Bambu printer who wants to continuously print, but is remote (e.g., at day job).
Hopefully, anyone who operates a 3D printer(s) remotely takes appropriate safety precautions when the 3D printer(s) are left unattended. At minimum, I would at recommend a smoke detector/thermal sensor placed above the 3D printer which outputs a signal to an "intelligent" power supply which cuts power to the entire printer if smoke/excessive temperatures are detected.
@TFyre I will certainly post up some of my learnings and code once Its a bit more proven. I just ordered my first bambu (p1s) today so it will take a bit haha. Coming from other printers running klipper, but played around for a couple afternoons with the bambu at my local makerspace to make sure I could run automation before pulling the trigger.
All I've done so far was run G code via MQTT that cranked all the fans, drove the z to the correct height, and knocked parts out the manually opened front door, and restarted the print. I'm planning to start on the mechanical design for an automatic door opener once the printer shows up.
as @colorado1876 mentioned, this tool helped convince me that starting a small production line with bambu was feasible. So thanks for sharing your effort here!
Do you know of any communities for print farms / production printing that are focused on bambu? I couldn't find any so I put together a quick telegram group if any of you guys want to join.
https://t.me/bambuprintfarms
Do you know of any communities for print farms / production printing that are focused on bambu? I couldn't find any so I put together a quick telegram group if any of you guys want to join. https://t.me/bambuprintfarms
@mfgnerd Wow, you're ahead of me. Hopefully others will find this as well.
I'm not aware of any communities, but it would be great to have one as a central resource. I would join your Telegram group, but I'm leary opening the door for more spam (from the platform, not you). The Bambu forum seems to make sense, so I put a request in here for a dedicated print farm forum sub-topic: https://forum.bambulab.com/t/forum-section-request-dedicated-topic-for-bambu-print-farms/61028
Please check simplyprint.io website. What i would like to have is something like this but for bambu printers.
adding tags for printers like nozzle size, material colour on the printer. Then adding gcodes to queue and adding same tags. File could be send to queue and connected with maching tags of the printers. Or add files to single printer