Limiting Factor for Printer Count

edited August 5 in Questions & Answers
Hey,
I know that it has been asked a couple of time: How many printers can my system run. Of course it's depending of the hardware. I am interested in what the limiting factor will be most likely.
I have turned off everything that we don't need (webcams, logging) and outsourced renderings to an external PC. The average load of our Pi 4 B (4 GB RAM) on the cpu was between 0.4 and 0.5 running 10 printers simultaniously. So can I expect to run, lets say, ~6 more printers without a problem (or even many many more, because repetier utalizes all cores?) or could the usb chip of the PI handling all the data transmission also become a problem? I mean, usually the total transfer speed is nothing for USB 3, but maybe the chip will sometimes not be able send out the data as quickly as needed? Buffer size of the printers is 127 Bytes.

Thank you for the input.

Comments

  • With regular prints you will not block the cpu, we are way too fast for that.
    Limiting factor is more
    - sd speed
    - usb bandwidth used
    - electric noise and power consumption disturbing pi
    - webcams (increase usb/network traffic a lot)

    If you compare log with print size you get around 3.5MB/hour communication over serial. You need to read 50% of that for input. So you see just from that you will hardly hit any limits on bandwidth.

    For a pi I think the main problem when you have prints only is stability of the electronic system. So when all printers use only own power and usb is terminated correctly, not much noise on cables 10 printers might be possible. If it is wise is another question.
  • SD Speed? Are the GCODES not stored into RAM when a print is started?
    We have used 10 printers at the same time for a week now and so far no issue at all.

    I am asking because for us maintaining fewer PI's with more printers each is way simpler to handle than more PI's with less printers. Guess we will simply test out the limits of the system, sounds like the biggest issue that could come up would be noise. Let's see if we run into issues one day, but good to know that hardware limitations with our setup are unlikely (except noise).

  • No gcode is never stored completely in ram. This allows it to print also big gcodes with small hardware.But we read 5000 lines ahead in a separate read thread to always have enough data available. So under normal instances there is no issue with having enough data available. Only if linux would block reads for a longer time we get in trouble, but with recent sd cards which are fast enough that is no real issue.
  • Cool, thanks for your input!
Sign In or Register to comment.