TFyre
Print queue feature request
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).
@colorado1876 / @mfgnerd
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
For the A1 mini, the swapmod exists, to automatically load end eject print plates: https://www.kickstarter.com/projects/daistes/swapmod-automated-multi-plate-system-for-a1-mini
The funding was succesfull and it was made by at least one person who also created the JoBox. It seems to work well based on YouTube reviews.
I would also greatly appreciate a queuing feature. As mentioned earlier, I’m automating my printing process using G-code that uses the toolhead to eject parts.
I think an easy way to implement this would be to have a setting per printer where you can enable automation mode. This way, printers that are set up for automation can automatically pull the next file from the queue once they’re idle.
This would allow all you to use the same system for a farm where some printers are automated and others are not. If the automation mode isn’t selected, someone would manually clear the print and notify the management software that the printer is ready for the next print to pull another item from the queue.
It would also be ideal to tag items in the queue so that they’re only available for certain printers. This is necessary because the gcode that the printers pull from the queue has automation movements in it. You only want printers setup for automation to pull automation jobs.
This is actually the biggest hinderance to me using this project... the one feature I need the most is the ability to queue to the printers. What is needed to push this to the finish line? I'd love to help out if I can.
Anyone is welcome to spec & contribute to the project 😄
A printing queue sounds "simple" but there is quite a lot involved.
- needs a database - manage jobs / printers / users
- needs "macros" - gcode snippets to run before/after a print
- needs storage - stores sliced models before printing
- needs printer management - tag / group printers
- needs some form of error detection??
- needs some form of notification system??
- needs to capture stats/history (printed hours / filament used / etc)
Most importantly, someone has to create a process flow diagram that would explain how all of this fits together.
I dont run a print shop, so I dont know what breaks or happens during a normal day.
- can you print continuously without waiting for models to cool down, does there have to be a timer?
- how do you know if the model was ejected successfully
- what to do when filament runs out?
Based on your previous comments, you mentioned it would be pretty easy, but this sounds like a full development effort. Is there a way to simplify this design? For example, you're mentioning sensors, etc., for error detections, filament runout, notifications, macros/gcode snippets. A lot of these can be eliminated... let's start off with an MVP, or minimum viable product.
Let me add your comments, and go through them one by one with my comment to see if we can trim down the requirements.
needs a database - manage jobs / printers / users - just need a storage method for the files... let's stick to the SD card here needs "macros" - gcode snippets to run before/after a print - this doesn't need to be handled, as it can be done in the slicer profile. needs storage - stores sliced models before printing - same as #1... use the SD for storage needs printer management - tag / group printers - use the system we have already? Breaking it up to a single queue per printer and not having the many to 1 option simplifies this greatly... we can even use the web client to "move" files from one printer to another. needs some form of error detection?? - printer already does this... so I assume your system does already as well... if it errors out, then the whole queue for that printer is paused until the issue is resolved... this should be identical to what it does today. needs some form of notification system?? Nothing more than what is already there. needs to capture stats/history (printed hours / filament used / etc) Nothing more than what is already there can you print continuously without waiting for models to cool down, does there have to be a timer? G4 commands embedded in the End GCode give us all the timing we need... it can delay for as long as needed (before the print ends.) how do you know if the model was ejected successfully - this is dependent on the design. An MVP can simply ignore this. what to do when filament runs out? The same thing that happens today... the printer will pause.
Ok... so with those... that just leaves us a method of uploading the files to the SD card (and optionally downloading them), adding a unique identifier to each file (like a sequence number) and then just holding state on the current sequence number to start with.
We can even require that all files be uploaded to the queue ahead of time to make that even easier.
What else would we need for an MVP?
Bill
As an add on... the state can actually be stored on the SD card as well... we have upload/download/delete capabilities... so it's easy to push the state to the printer. Even do logging to it.
For that matter, we can create a folder with all the queued items in it... as long as there is a file in the queue, it should keep printing them.
Bill
Based on your previous comments, you mentioned it would be pretty easy,
Please dont confuse easy with effort ;)
What we are talking about here is still easy, but requires a lot of effort.
Ok... so with those... that just leaves us a method of uploading the files to the SD card (and optionally downloading them), adding a unique identifier to each file (like a sequence number) and then just holding state on the current sequence number to start with.
As an add on... the state can actually be stored on the SD card as well... we have upload/download/delete capabilities... so it's easy to push the state to the printer. Even do logging to it.
The interface to the SD card is FTP.... This is far from ideal to log things or track state.
For that matter, we can create a folder with all the queued items in it... as long as there is a file in the queue, it should keep printing them.
Who deletes the files? otherwise it would continuously print the first file...
how do you know if the model was ejected successfully - this is dependent on the design. An MVP can simply ignore this.
Automation is a "funny" thing... When things break, it breaks bad... imagine something goes wrong and it just keeps trying to print the next and the next and the next. This is why database/storage/history becomes a requirement. If someone queries why the printer keeps banging its head, atleast I should be able to query the database to figure out what commands has been sent... Right now all commands are user driven.
what to do when filament runs out? The same thing that happens today... the printer will pause.
My goal here is to ask a leading question... Like should it automatically try to continue printing with the next filament if its similar...
Im really not trying to be difficult here, but this is exactly why a feature like automation requires proper specs & design.
It would also be ideal to tag items in the queue so that they’re only available for certain printers.
Unless im reading this wrong, the goal is to have multiple queues and batches of printers... Which ever comes free, takes the next job
I dont run a print shop, so I dont know what breaks or happens during a normal day.
can you print continuously without waiting for models to cool down, does there have to be a timer? how do you know if the model was ejected successfully what to do when filament runs out?
For what it's worth I can explain how my print farm currently works (would allow for a 'simple' MVP/PoC I think):
- Every printer (BBL P1S+AMS) has file.3mf in the SD card root
- A script runs on a server for every printer that starts printing file.3mf using MQTT whenever printer N's status is finished
Within file.3mf, there is a custom end gcode piece that:
- Waits for the bed to cool down
- Starts an ejection movement (litteraly just a couple of g1 movements and a wait for temp command)
- Ends the print
So in practice this results in the printer reaching finished state only after cooling down the plate and clearing the build plate. If the print fails, the printer pauses and thus is not started again by the script. The same happens when all filament slots runs out. We've been using this successfully for over 6 months, printing 24/7 with 8 printers.
MVPs could be (ordered on easyness):
- Queue per printer (auto repeat): Upload the queue files over FTP to the SD card, have a small script wait for finish status and start the next file (or repeat N times). Don't forget to slice with custom end eject gcode. (This would already work for me)
- Queue per printer (trigger repeat): Same as above, but make a button or api trigger or something that needs to be pressed/activated to start the next print. This allows for other eject systems, like build plate changers. (Sounds already useful for OP)
- General Queue: store files on the server and only upload to SD after reaching finished state. To prevent clogged queues, only send to auto repeat printers or a select set of printers using the same material etc.
- General Queue Plus: Make it as complex as you want, adding all features in this thread.
So coming back to this:
A printing queue sounds "simple" but there is quite a lot involved.
needs a database - manage jobs / printers / users needs "macros" - gcode snippets to run before/after a print needs storage - stores sliced models before printing needs printer management - tag / group printers needs some form of error detection?? needs some form of notification system?? needs to capture stats/history (printed hours / filament used / etc)
I think most of those things are handled by BBL themselves and thus not required for an MVP that runs on BBL printers. Step 1 does not have any of the issues above, step 2 only a few.
Hope my essay is clear, feel free to ask if you need more info! Happy to help.
