Slicers are missing this ONE feature, so i built it

[@stephen_hawes]

go listen to the OHM Podcast where Lucian and i bully each other and talk about robots: podcast.opulo.io

[@KeithOlson]

FWIW, there are multiple WIFI-SD cards that pull from a folder somewhere on the network By just keeping that folder updated, every machine can always have the current version of every file. You can also look up 'esp sd card emulator' for a few projects with firmware you can hack. Cheers!

[@21LOLxPRO]

Prusa connect have this feture in prusa for massive farm production

[@nathanmelanson]

For the Kanban levels, I would recommend the 2 bin system. Basically 2 bins, one is used for working inventory, and the 2nd has safety inventory. You put both bins on the shelf with the working bin in front, safety in the back. You pull items from the front bin till it is empty. Then you take the empty bin off the shelf, and pull the safety bin forward, making it the working bin. The now empty bin is the kanban bord to reorder. Once the defined amount to stock is put into the bin, you put it back on the shelf in the back, which makes it the new safety stock bin. Since you revision items, this makes sure all the old part versions are used before the new ones.

[@valent_t]

Nice Kanban skills! Do you share more Kanban tips and tricks somewhere?

[@theJonnymac]

can also use a Card in the bin vs a seperate bin. Cards go into a bin "parts to make", then when you make enough. you put the card back in the parts bin.

[@Skwisgar2322]

This is cool, but I feel like a better solution would be getting printer manufacturers to add the ability to pull files from a central file server. That way, you just keep the files on the server up to date and the printer prints from there. Have each printer have its own "active" folder it pulls from and an archive folder for past revisions.

[@stephen_hawes]

oh that would be rad! a feature like that is the dream

[@berlinberlin4246]

With a printer running Klipper and Linux or something, its just a cronjob away 😊

[@kzalesak4]

Does such a tool really not exist? I am happy to build such a system

[@oddstr13]

@@stephen_hawes With Octoprint, you could likely just mount a network server (cifs, nfs, sshfs)

[@Ximit81]

Exacly the comment I was just writing ^^

[@valeriyproklov2868]

I talked to the CEO of Bambu Lab Europe in Barcelona during their tour and he said an API is scheduled for this summer. So something to look forward to.

[@kyleisah]

Suppose it’s a two-part problem. One being the slicer not being able to send files to multiple machines, second would be the firmware running on the printers themselves. With Klipper, you can control multiple machines from a single pi, and define in each printer’s config file where it’s “virtual SD card” directory is. So you can have multiple machines running from a single pi, all sharing the same directory where gcode is stored, and the start print and end print gcode can be localized to each machine with macros so you don’t have to worry much about customizing gcode in your slicer for each machine. With all that said though, I’m always happy to see progress being made in 3D printing from the community. Well done!

[@jessicav2031]

With Klipper printers, use Syncthing. All printers of the same type share a folder containing those files with your control PC. Everything is automatic, just manage the files locally as a normal folder ☺

[@clementclarisseclemen3d708]

... except that works ONLY if you got SAME printers, his stuff works with HETEROGENOUS fleet of printers, that's what make it great...

[@SarahKchannel]

Yep same on OctoPrint

[@jessicav2031]

@@clementclarisseclemen3d708 You can just have a different shared folder per printer type. The same issue applies to any solution.

[@SarahKchannel]

@@clementclarisseclemen3d708 that is highly theoretical and not very practical. Small edge case example is, if a part is 250 x 250mm in size, you cant print it on a 200 x 200mm printer in the first place. Even if all the parts are small, but you require to print many in one set, the layout of those parts still needs to be constraint to the printer dimension. Hence one Gcode file will not be working on any printer of diverse size. Some limitations are a given.

[@paulgupta2454]

​@@clementclarisseclemen3d708 That's not really a bad thing. You can upload ThinipartMK1_PrusaMini_Platter.gcode to every single printer running klipper, then only start that gcode on the appropriate printers, even if it's ALSO got ThinipartMK1_PrusaMk3_Platter.gcode? You're running a full OS, that's got plenty of space for pre sliced code for multiple printers to be mirrored. This works well.

[@Barbatronic]

Hi! At our French lab, we have a multi-3D printer farm and we use Repetier Server to manage them all. There are some very cool features, like the "project" feature, which allows you to store all your gcode and send one gcode file to all the printers you want. So, when we need to build a lot of parts for a project, we use that, and it's very convenient! :) Oh, also: I love your videos and your work! Thank you for sharing all your knowledge and experience on building and producing machines!

[@valent_t]

Do you use Bambu Lab machines in your farm? Are they supported by Repetier?

[@Barbatronic]

@@valent_t Hi ! Didn't test that for the moment. I Ordered a Bambu last week but didn't received it yet (it need to be validated by our financial services as we are in a school). As soon as it arrive, I will check that. For the moment we have just a bunch of printers with marlin and some with klipper. Works very well. But with bambu, I know that it will be sightly different. But with the large distribution of Bambu on the market, I hope that the team behind Repetier Server will update their soft :)

[@valent_t]

@@Barbatronic without support for Bambu they will shrink to zero.

[@sq3rjick]

The Bambu printers have MQTT and you can get a lot of info from there. The HoneAssistant community has it mostly documented already. The P1 series has a limit of 3 connections at a time (1 cloud, 1 camera, and 1 other, so if you use the panda touch screen you’re at your limit already). The X1 runs Linux so it supports more connections (beefier mcu). I’m currently hacking around with the MQTT to control a chamber filter and chamber heater for my X1 depending on which type of filament I’m printing.

[@esalexander5807]

Since you asked for alternatives, if you get some scales/load cells you can talk to with a computer you should be able to just track the weight of each bin (with measurements at reasonable low frequency). A few config variables per bin (bin weight, part per weight, hysteresis low and high thresholds) and you'd be able to automatically have digital stock level tracking, which you could feed to a screen at/near the print farm (and eventually use to automatically trigger additional prints). Definitely more expensive than the neat paper card system, but takes the variability out of the level tracking :-)

[@stephen_hawes]

oh that would be super cool! making a cheap, easily deployed bin system that can keep track of how many parts are there automatically is pretty rad!

[@BloodyMobile]

​@@stephen_hawes if you wanna go extra fancy, you could include RFID tags into the bins that hold the config for said weights and thresholds. In that case you could put them into any free compatible load cell space. Although that would only be worth it if you guys relocate bins often. But it would still make it easy to not accidentally "run" a bin with the wrong config.

[@robertadsett5273]

@@stephen_hawesor just a simple two bin Kanban where the bin is the signal. You pick from one bin and when it’s empty the empty bin goes to a central location and the full bin behind is used. Besides being cheap and simple it ensures that the parts are used in a FIFO manner and no part sits for ages

[@alexanderal-bahrani249]

In between would be a bin label with barcode. Low bin state and high bin state could them be scanned and would be shown on a kiosk screen by the print farm. Extension would be automatic job queueing based on that.

[@SchwachsinnProduzent]

@@stephen_hawes You could use something like ESPHome with HomeAssistant as a starting point. A single cheap ESP32 should be able to handle multiple sensor inputs and you can just upload new yml files to each ESP32 via WLAN, if you want a change. And the device's state can then be used to trigger a multitude of automations. If the costs of scales doesn't scale that well (pun intended), you could even use a very low tech solution: use a pulley to let the weight of the full bin raise a counter weight above a micro switch. When the bin gets too empty, the counter weight triggers the switch.

[@qrcline]

Defintely would be a good idea to add a “All” button to the printer file uploader

[@Blamm83]

if you use Klipper printers, you could map the gcode folder to a network drive over NFS. And print from those

[@Panningen]

Yes, I was thinking exactly the same thing. I assume most of these printers run Debian, you can just use Autofs to automatically mount the relevant NFS share. No tools needed.

[@ScottHess]

I wouldn’t put NFS in the critical path for printing. Fully syncing the file to local storage is better.

[@TheOfficialOriginalChad]

Mapping a network drive has nothing to do with klipper… If you have root on ANYTHING you can mount NFS.

[@ScottHess]

@@TheOfficialOriginalChad I/O to a network drive fundamentally breaks certain low-level POSIX assumptions. For instance, normal POSIX file I/O is always blocking (as opposed to socket I/O which can be done non-blocking), which means that when reading from a file, it blocks the process until the data is available or a hard error can be delivered. If a network drive has a 10s hiccup, the reading process will simply hard block for 10s. If Klipper is reading gcode from a network mount and it blocks for 10s, things are likely not going to work out well for your print. Or if the NFS server spends 40 seconds rebooting, or goes down entirely, anyone reading from that mount is just going to hang for that time. My point has nothing to do with what the system will allow you to do, my point is that network mounts don't work the same as local mounts, and some of those differences are very inappropriate to introduce into a real-time system. There are ways to work around these issues. Most of those ways are pretty annoying and intrusive to implement, so I'd be VERY surprised if Klipper has done that implementation.

[@Blamm83]

Marlin machines for example (like Prusa) don't run a real operating system where you can do that though. They only run on the microcontroller. That's why I named Klipper as an example, that runs on a RPi

[@FilamentFriday]

Does the transfer notify you if the file already exists and offers a rewrite? Or do you make every file a different version number? Seems like the SD could end up loaded with multiple versions thus in time you end up scrolling through too many files to find the latest.

[@stephen_hawes]

right now, it just rewrites over any file with the same filename. this is actually great for our usecase, so there's only ever one file to print for a given part, for a given version of the machine. when we send an updated gcode file, we keep the name the same and it just kills the old version!

[@BinaryCounter]

The Kanban system is awesome. You could probably automate this further with some weight sensors (or a push button really) and an online Kanban like Trello. That would save the person taking the part the trip to the print farm. You could even print out the part queue with a receipt printer if you want to.

[@joey12495]

Weight sensor was probably the first thing I thought of when I saw how they were handling this. Given they know the dimensions/filament type/theoretical weight of each piece it would be an easy way to tell exactly how many parts there are without manually counting. Weight gets below the threshold, system could automatically start printing

[@VastCNC]

Wonder how much the BOM would be for that system, and the worthiness of the additional system complexity and upkeep though.

[@BinaryCounter]

@@VastCNC For a push-button system... Honestly, a ESP8266 board, some push buttons, an io extender and some wires... We're talking like 10-15 bucks for a system with dozens of buttons. Then you just setup a webhook with Trello, connect the thing to Wifi, and that's pretty much the whole project, hardware and software. Weight sensors are a bit more complex and costly, but not too much so. They would probably need to design and print adapters for the sensors and their trays though.

[@ashreid20]

@@BinaryCounter keep it simple stupid. .. as they say

[@charetjc]

This is an example of solving a problem with a complex solution over a simple solution. Someone has to install all the switches, label the switches for humans, then program the switches to match the labels, lest the empty box of widget A triggers a call for more parts that instead asks the farm for more of widget B. This kanban idea requires very little for setup (formalize operating procedure once, make cards as needed), and the only cost is the exercise of using the system. Oppose that to some electronic solution that requires complex setup, but is reduced to the simple exercise of pushing a button to use. Will work fine until someone has to repair or upgrade the system, and then needs to remember all the parts to update to do so.

[@Bertrp]

So I remember using something similar with the kanban system but we used barcodes to a central database and that allowed us to not only reload items but also for generating purchase orders to suppliers. Having that Central database also was very helpful for us with revisions because we weren't relying on a card being kept up today we had somebody keeping our database up-to-date with the material specs

[@dragoncracker]

its funny that you made this piece of software. a year ago I tossed around the idea of starting a print farm, but stopped dead in my tracks when I realized this wasn't a thing yet. I had considered learning some programming to address the issue, but other priorities needed my attention. I'm glad to know at least someone has a solution of sorts so if I goto back to the idea of a print farm, at least there is a starting point. Thank you for your time and efforts!

[@thabestsniper]

Farm upload looks like a nice feature. Sure, it might not be something a lot of people use but it looks simple enough to implement. The ftp servers might not be the best thing to use and/or to leave open though.

[@stephen_hawes]

they're password protected, so you still need to get the code from the printer's screen to connect! me saying "open" is probably not the most accurate phrase, i just meant that they allow a connection at all.

[@maddi04]

why would a open ftp server be a problem, as the ftp server is in lan and not exposed to the internet?

[@thabestsniper]

@@maddi04 Because it's not good practice from a security standpoint. It's not a concern by itself on a 3d printer that's not internet capable but I like things to be done well

[@FixDaily]

There are wireless SD cards that allow you to connect throw wi-fi or bluetooth.

[@ausgeknipst]

So i tried it just now and it also seems to work with our A1 and P1S. Thats the tool we were searching for quite a while now, because a whole printfarm program would be overkill. Thanks a lot! Now we just have to wait for Bambu to implement folder support... Right now it impossible to use it with 300+ Files and no real file sorting on the printer screen. Maybe we can implement to upload whole folder structures with subfolders when the support is here..

[@martin_l_frederiksen]

It would be pretty cool to automate that with GitHub actions, so when the files are updated, they'll automatically get sliced and uploaded to the printers

[@hengrv]

I've just opened a pr for that :)

[@thenarcotk]

Would you really trust printing something sliced automatically that you've not visually explored beforehand?

[@martin_l_frederiksen]

@thenarcotk I would trust that you would validate it before committing to the main branch

[@firewolf34]

This is basically just a print spooler, which we already have had for normal printers since the 70's. I'm surprised nobody has produced a standard print protocol for 3D printers. How long before you can just Ctrl-P to Print in Windows 14 or whatever, and send an STL to your 3D printer using the built-in OS print spooler? How long until slicing is done entirely automatically (and turns out decent for most cases) within the printer itself? These are the barriers for 1st-class 3D print integration in OS itself - which will need to occur soon, I'd bet, if spatial generative AI starts churning out STL's in the next couple years. Edit: and I'm aware of Octoprint and etc. But we need the spooling at OS level, not in a 3rd-party app that not all printers support.

[@TheOfficialOriginalChad]

Slicing has to be done manually, at least for a while. The orientation, quality, speed, etc are all specific to the use case of the part and/or user preference. Even with AI, it can’t know what YOU want.

[@efreak1996]

Something I've done in the past is store all my 3d parts (the "source objects" as well as the sliced gcode) on a NAS and configure OctoPrint to pull the files from there. This way I can totally skip uploading manually as the files will just appear in the OctoPrint UI. Obviously this doesn't work directly with the printer though but the workflow felt quite nice.

[@darkshadowsx5949]

i believe you can do that with klipper firmware and mainsail web interface and there's no limit to how many is in the farm.

[@robonator2945]

This is really one of those problems that just shouldn't be a problem IMO. If printers just used a standard stripped down linux installation you could then do something like an SSH/SCP transfer or just use something like syncthing, or really any number of other pre-existing solutions. One thing that I wish people stressed when it came to open-source is that the user can just sorta, do stuff. Since there is so much 'fragmentation' solutions tend to be way more agnostic from the get go, and since it's all openly visible anything that isn't already transparent can be learned and adapted fairly quickly. There just aren't barriers that even get in the way in the first place so you can just do what you want to with absurdly minimal work. (at least not 99% of the time) I appreciate this as a solution, but it's a solution to a problem that just shouldn't exist in the first place IMO. Something like syncthing could do this obscenely well, yet because standard practice is locked down interfaces people need to reinvent the wheel and do stuff like this. When it comes to farm-scale printing, if printers could just be daisy chained with cheap ethernet cables then SSH-ed into, loaded with something like syncthing, etc. people wouldn't need to invent workarounds to do stuff like this. Again, I fully appreciate that this *_is_* a solution to a real problem, but it's just annoying that it's a problem that exists in the first place. One of those silent benefits of more open-solutions is that you don't need to reinvent solutions to problems like this and I wish more people mentioned it. Granted, in this case there just being an open FTP server is pretty clean as a solution anyway, but it's still not ideal. (plus, the fact that it had to be discovered on forums rather than being an advertised feature means it might have been an oversight that will be 'corrected' in the future)

[@chrisclifford8958]

This is a great use case for syncthing. Set your workstation as send-only and all your printers as receive-only if you're worried about conflicts.

[@mateusraitz1803]

Since Klipper firmware runs on Linux , you can 100% do that. Scp your files to the print files directory, or use syncthing

[@robonator2945]

​ @mateusraitz1803 I know some things do it but my point is more about what's standard. This is a really invisible benefit that not many people think about, so it just doesn't get the market pressure that it should. For instance on linux one of my favourite features is literally just symlinks. They're so simple and ignorable yet they let you do all sorts of wild shit, like splitting an application across several drives so that different parts of it that need to work fast can, whereas others that can be slower are kept on a larger medium. More open solutions are just naturally going to lend themselves to more agnostic and "it just works" interoperable design principles, but it's one of those things that most people don't really think about. People don't think about problems being easily solvable or non-existent, they think about problems that are stubborn and DO exist, so it's something that not a lot of people talk about, even though it actually makes a dramatic different in quality of life. In other words there is generally a greater focus on solving problems rather than avoiding them. That's not intrinsically an issue but more people really should start asking why these trivial problems even *_are_* problems in the first place.

[@berlinberlin4246]

With Klipper and Linux or something its just a cronjob away 😊

[@davidpodeszwa7010]

Using linux everywhere is not really possible. Not all printers have a SoC capable of doing so as that adds to the cost of the printer. I would say FTP is the closest we can get to a "standard" without creating some complicated API

[@Diatorker]

Sounds a lot like what prusa is doing with Prusa Connect, a cloud tool based on what they in their own print farm. Even though it's only working for their printers, it allows you to handle print queue, sending files to printers requiring them, and minimal operations on the printer themselves. A really cool project, hope it will be expended for more features, and maybe more printers ? (really not sure for that though...)

[@RolandKnall]

This is where it would come in handy, if those printers were just plain open-source. Write an ansible script and auto-upload all the files to Klippers code folder is a quite easy thing. Would also allow to include checks, where you could see if checksums match or the newest ones are already there. And would let you archive the files easily using git or something similar. All of that would be easily doable if BambuLabs were default open-source. fyi .- I did exactly that with my Voron printers. Took me all of 10 minutes to implement.

[@harrisonvandort9268]

Love this! Have been following along for a fair while now. Would be interested in seeing some more of your process like your version of the Kanban system.

[@ResaloliPT]

What about repetier? you can use a server and then network all printers

[@Aimsucks_]

Needs a "select all" button for the printer list!

[@consig1iere294]

I don't have a Bambu printer or I run multiple printers at once, however, I am somewhat confident that you can manage multiple printers with Mainsail or OctoPrint. I don't know if the printer themselves can detect the files but with one device (laptop or smartphone) you can start/stop prints and do other stuff as well. As for Kanban part, just use load cells (as someone suggested in the comments) with ESP32s and send it to Homeassistant in order to print stuff.

[@marc_frank]

can you send "print this file" commands to the printers? you could attach a load cell to the part bins and send print commands to free printers once the tray weighs less than safety stock.

[@OddlyIncredible]

Klipper support should be easy as hell to add since it supports SFTP over SSH natively.

[@SETHHIKARU]

You could use a HW BOM lookup table to subtract parts from your inventory count. Every time you scan a QR code that contains the build counts for a specific item, it subtracts from inventory. At a specific number, you could trigger it to send out a macro to Octoprint to print that many pieces. You can still use the Kanban method, but also digitally now.

[@SarahKchannel]

I have all of that with my OctoPrint setup. All OctoPrint instances are connected to a NAS where all the files are hosted. That works easy, as long all the printers have the physical properties. You can then log into each octoprint and select the file. Granted you need a Raspberry Pi with OctoPrint per machine.

[@realElectronicMe]

I love the inventory guy 😂

[@easymac79]

Flashforge/Voxelab have multi-machine control from their slicer. It works great. There is an occasional transmission failure, but I blame the WiFi modem/router.

[@DiThi]

If you add support for octoprint, you would be also adding support for klipper printers as well. I think it's just a simple http post request.

[@edude03]

(I don't run a print farm but from my own experience with ~3 printers) I'm not convinced this is actually what you want though? Feels like you'd really want a central thing that has a queue of jobs and sends jobs to a printer once it becomes "available" again (you'd probably have to have a human press a button on the printer to signal it's ready to print again but anyway) then the more complex version being the central thing knows the capability of each printer and sends jobs based on the requirements (for example, sending color jobs to a printer with the color(s) you needed loaded)

[@TheAleksanderB]

Bambu have the X1E which is supposed to work behind firewall, load balancer or VPN connection and it is intended to be used in farms. Even it can operate in 'offline' mode, not connected to the cloud. I presume that there is an Enterprise version of the slicer, that might support some very niche features that enable full capabilities of X1E. Back to the topic of the view, a huge time saver will be if you can make the transfer asynchronous. Other things that I can think of would be a button to select or deselect all printers and a way to upload or generate a map of the farm. The last one would be a great visual representation and easy to navigate between the printers.

[@AaronEiche]

I believe the all of the Bambu printers can be set not connect to the cloud, though I don't recall off the top of my head if they have internal support for Wifi copying files over

[@mbibanaan]

With the x1e It’s just sending files over lan to the sd card

[@franzekan4953]

A cool idea for easily managing 3D printed parts in Aligni could be just having RFID stickers on the "kanban cards" and when you add parts you just tap it on your phone / inventory computer in that room and add more stock 🤔

[@TechyGuy17]

Klipper and mainsail can have multiple printers, and you can sync between the gcode folders

[@noxin75]

The panda touch system from BTT can interface and run up to 10 printers in groups. Pretty sure you can copy the gcode to the panda touch via usb and then send the jobs to the printers from there. Not sure if you can upload over the network to the Panda Touch yet, but that would be a neat feature as well. And it would work across all the Bambu product line. The reason the P1 uploads are so slow is because they have a very under powered Processor and it just can't handle any real load, especially while printing.

[@Dot2TheLock]

Couldn't you use a weight sensor for the bins or even a cam to look for the red line just to automate it I guess the weight sensor set up might take more space.

[@AaronEiche]

The Kanban management for printed parts was very interesting - I'm curious about the quantity-in-stock "low-tide" line. It feels like the stacking of components in the bin could present multiple interpretations of the present quantity. I'm probably over-analyzing it, but is there a given practice for how parts should be placed in the bin, or is the flexibility of "low" broad enough that it's not really an issue if it happens at qty 20 remaining or qty 10 remaining?

[@stephen_hawes]

no, i totally agree. i wrote a bit about this in the description, it feels too ambiguous. still want to find a better solution for making the kanban trigger at an objective threshold.

[@AaronEiche]

​@@stephen_hawes The nerd-sniping solution is probably something along the line of load-cells under each bin. When the threshold hits, it sends a message. It could even trigger an idle printer to start printing that part. That would be way fun :) I don't have all the data you have, but I think the actual solution would just be to have the Kanban card trigger an inventory check - then you use that data to compare against the projections you made for how many parts you should print. Otherwise, isn't the Kanban card just a "whoops, we're running out of parts"? It's reactive instead of predictive.

[@Jehty_]

​@@stephen_hawesisn't all of that more complicated and time consuming than just keeping track of your inventory with the inventory software you already use? If I understood you correctly you already have the outgoing stock figured out. So all that's left is to have a quick way to enter new 3d printed stock. And that would be as simple as have a computer with the right website opened next to the QC-station. And if finding the right part in the software is too time consuming then you could use bar-codes to speed that up.

[@acbthr3840]

@@stephen_hawes The simple way to do this is to have two bins for each part. One with a grey/white color, and another sitting directly behind it with a bright yellow/red color. Parts at first get taken from the bin at the front, then when its empty, the front bin is taken off the shelf and the colored bin is pulled forward so parts can be taken from it, then the grey bin is set aside or moved behind the colored bin. The red bin acts as both your remaining buffer and the indication to staff that the refill threshold for that part has been met. The threshold is set by adjusting the size of the front bin relative to how many parts can fit

[@stefanejegod8644]

Does it make sense to run 3d printing this way? I mean I get why it would with tradionally manufacturing where you order x of part 1, x of part 2, etc. But all the products you print yourself, aren't they like... actual products with a specific set of items? Unless you have like multiple different colors or different filament type products, wouldn't it make more sense to just fill a bed with "product 1" and "product 2" instead of random parts that you THEN have to combine into different boxes?

[@GJToken]

I feel like Prusa would have a piece of software that would do what you're after since they have a large print farm themselves to print components for their 3D printers, maybe reach out and ask? Wasn't that what Octoprint did? (Don't operate a farm to know for certain)

[@klaudijusstankevicius3353]

Great work, after this you should consider how to push prints off the plate and start a new one to get continuously printing 😢

[@TheTsunamijuan]

I have often used Rsync (in linux) to do this,, since I can then make linked folders to the devices in question, and have it scripted from there. But i am only managing a few machines.

[@FLasH3r]

What about SD cards that have wifi in them? maybe they can be on the printer and mounted somehow to the file system? Eye-Fi were the first (i think) with this feature - maybe they or others exists today

[@Falney]

There is a way to manage a farm easily with klipper, but that requires you flash your printers to run klipper or buy klipper printers. You upload it to one printer then use the rsync command

[@TecSanento]

Four non Bamboo 3D printers there ist ein SD card with esp32 module on it that you can use to create ftp server for non Bamboo printers

[@UKsystems]

It would be very easy for printers without Wi-Fi to have a little board that can connect to the SD card slot with a cable and act as an FTP server that can be powered over POE. I have made a prototype but it’s kind of functional.

[@UKsystems]

Four when things need printing it would be possible to make a very easy and cheap system where you simply press a button indicating that it needs printing as you could use some esp 32 and have one as a receiver connected to a monitor displaying what parts are in need of printing

[@engineeredaf1920]

Content so good that I watch the sponsor ad at the end 🫡

[@adamarmfield1069]

it seems like there might be some parts it'd be worth getting injection moulded or whatever, I appreciate 3d printing gives you a lot of flexibility

[@adamarmfield1069]

bonus points if you can make one sprue with all the 3d printed parts on ;)

[@fischX]

Drawback of that strategy is that he loses fast iteration cycles.

[@jesperkped]

Would it not be easier to just use the SD card to wifi cards? (Basically a sd card that instead of having a lot of storage memory have a wifi to shared data adapter)

[@barrettdent405]

There’s an argument for Slicers to include some Farm Management capability. But I think what really needs to exist is support for Farm Management software in Slicers. You may have paved the way. The starting point for such change is someone creating a standard, specification or functional starting point. Which you’ve just done!

[@EraYaN]

This should still be a separate tool, but it should be a service. To keep printers up to date with new versions, handle prints etc. A little container you spin up somewhere to manage a fleet of octoprint/klipper or other firmwares.

[@Franfran722]

I have this capability inside Creality slicer for Creality printers Great process with kanban ! Sometime intelligence lays on knowing where to put technology and where you shouldn’t. Here is a great example.

[@alexbezdicek]

Doesn´t Octoprint do this already? You can have several printers connected by creating several Octoprint services. Then just connected them over USB

[@Sembazuru]

With your farm upload tool, does it also purge the old, now obsolete gcode from the printers? If not, how do you ensure that someone doesn't print a build plate or two of an old, unused revision?

[@jlegen]

That does not look like a missing *slicer* feature to, tbh - i guess you slice once, and then you send the ready sliced files over and over again when needed. So really more like a tool like you did…🙂

[@insanegammer109]

FYI Kanban is pronounced "Kahn-Bahn"/”Con-Bon" not "Can-Ban"

[@superbrain3848]

Ultimaker Digital Foundry would be something similar to that. but its limited to Ultimaker printer and require a license iirc

[@sral2482]

With Python you can implement concurrent jobs. This allows to upload to all printers simultaneously. This would make it much faster.

[@Tinker_Nerd]

Considering each print farm uses different printers, possibly a mix of printers, and is going to be managed differently depending on the owner's preferences, tools for uploading to multiple printers won't end up baked into the slicer programs. Maybe they could be implemented as plugins, but I don't think there will be anything terribly complex that comes as part of the software

[@sarreqteryx]

If you could get that to do parallel uploads (at least by printer, if not each file), that would be awesome

[@platin2148]

Btw. did you think about using the BLE labels that Shops currently use it’s quite nice.

[@MikesTropicalTech]

How do you handle when one print job ends and the next one needs to start? Do you have to manually scan the farm to see what's finished, remove the parts, clean the plate and then select the next job to print?

[@superbrain3848]

integration into RRF should be also rather easy, it exposes a API that can be interacted with, allowing to remote upload and start prints

[@__cooper__]

You could probably fully automate the bins to printing more of the paets when low with some fancy sensor shenanigans. Either machine vision or just weight sensors on bins. (Or diatance sensors, or radar or whatever). With weight, you'd also know exactly how many parts - and could send an email detailing which parts printed on which printers, for which bin. Or alerts if it can't print them and a way to retry for x time before emailing errors. you'd need some sensor to detect if the printer was going or not though

[@bonce]

Slicers shouldn't manage farms, sounds like the wrong place to put that concern. I know it's just a file shipping queue to the printers as endpoints, but even so, that's a file management problem so I'd expect to see it as a standalone machine service/daemon. I'm not even sure a slicer should be able to interface with that queue, it feels like a separate part of the tool chain. If it was a service daemon that was aware of the endpoints and their individual configuration, a relatively simplistic webfront end on a file uploader would do it, file picker so select the local files you want to send to printers and a list of checkboxes for which printers to send them to. I'm struggling to think of a parallel, best I can do is 'Photoshop doesn't need to know all the printers a image needs to be printed on when you save it'

[@BeefIngot]

@ 3:30, damn them some big ass spools. Seperate to that though, I could totally imagine a little cheapo esp32 powered wireless microsd card so you could have one central server for all of the files.

[@martinhuber6702]

You can do this with Repetier-Server Monitor

[@callen_grigori]

Couldn't you do multiple threads at the same time uploading to printers? If uploading speed on the printer side is the main bottleneck, your network could possibly manage multiple uploads at the same time speeding up the process.

[@mihailazar2487]

Place your bets, everyone, how long until Bamboo removes access to the FTP server in an update ?

[@TecSanento]

About time did you start injection molding those parts instead of printing them all the time

[@Ernzt8]

So smart and at the same time so simple...

[@ciaduck]

Don't most of these systems allow SSH/FTP/SFTP? Couldn't you just cron an rsync script and be done with it?

[@JeffDM]

Duet printer boards offer FTP functionality too.

[@BrianShipman-jd7bx]

Should read “The Goal” good if you’re trying to figure out what component of chain management is slowing you down

[@loko4psp]

Doesn't prusa connect already do this?

[@TheOfficialOriginalChad]

FYI: the tool Syncthings will solve all of the file management for you

[@SamiKankaristo]

There is OctoFarm, but the Git repo hasn't been updated for 2 years, so it might be dead. EDIT: Aaand you mention it in the video description. 😅

[@lucianchapar]

Octofarm is super cool and we ran it for a while, but development is completely dead 😢

[@noxin75]

Octofarm died :( There's an alternative called Monster or something, but I despise the interface. And with Bambu deciding to start mucking with the MQTT interface and starting to break third party integrations (like BL Led, Home Assistant, etc, etc), it's going to be hard to develop anything useful for long term until they stabilize their access methods.

[@gsxr1kmatt]

What's wrong with Octoprint and an NFS share?

[@KevinBrowder]

hmm, i guess with klipper and/or octoprint you can just mount your NAS to accomplish a similar sorta thing

[@yuxuanhuang3523]

I guess a software to monitor the status of all machines would be better. I would for example know the file name of the print and the progress on each printer. Also tracking material type inside printer would also be good. Then I could just have an alert when a few prints are done or has problems, and go to physically remove the parts and start a new print on the screen. batch upload when the printing is done would make much more sense, even better is having a function to just read the color and send it to all printers saying white

[@markmcgookin]

Hey Stephen, what’s the software package you used for the software? Looks like python, but what UI library did you use for the desktop app? How did you package it as a Mac app?

[@abc321meins]

As the bottleneck is the server speed, how about doing the uploads in parallel instead of sequentially? This way the total time to upload would be drastically decreased.

[@Eysvar]

There was a piece of text thrown on screen that said he parallelized it after filming

[@abc321meins]

@@Eysvar woops I did miss that

[@platin2148]

Hmm i don’t think the farming stuff will go much beyond what we currently have just talk with the guys at Slant and you will know that there isn’t much market currently. But if filament ever gets cheaper it might make sense. But for private people very unlikely that they need multi upload..

[@muayyadalsadi]

Maybe printers should support mDNS / Bonjour / Avahi. Or maybe usual DNS SRV records. Get me all ips of printers with x y z features and upload x to them.

[@simonebiuso3098]

Prusa have a tool to do bulk upload just use the interface cloud

[@Shenepoy]

tho the implementation wasn't amazing you still made it work and that all what matters👍 what I would recommended is having multi threaded application to send to all printers at the same time, better ui having printer addition and info modification, having more of sync feature rather than uploading files would be better for manufacturing when changing versions

[@mawu98]

Nice Video. I have an Idea, maybe it’s better if you put the 3d printing parts in your software aligni. But you don’t put the new stoke manually in the software, maybe a barcode scanner will work for each piece or you have scanned only once and an Interface ask how much new pieces came to stoke.

[@CVinhas]

In assembly lines is called "andon"

[@rickyh2896]

Sweet video! I'm all for keep it simple and this system is perfect but here's a stupid overkill idea. Put esp32s with weight sensors of some type under each bin and integrate that into some type of digital software so it throws a digital flag. Maybe once farm software gets better it can also auto queue the parts that need to be printed!

[@fenderrexfender]

Is octoprint not a thing anymore?

[@younjojny]

I was going to say. Octoprint with usb to network adapter plus a network storage device would work and allows for queuing of prints.

[@mawoodmain]

Octofarm?

[@xcruell]

You still used the sd card in 2024, while fluidd and mainsail are a thing? (or even octoprint lmao). Edit: yeah with that speed and printer-after-printer upload, mainsail would be way faster!

[@radovansemansky4618]

excelent job Stephen and your team !! ☝☝☝

[@alirezaabasi.]

I think it's better to make a esp32 and a sd card interface and make ftp with esp32.