Staggered start for power draw#151

Make a feature that staggers the start of printers so you can launch prints to them all at the same time but they will start up after X time one after another to limit power draw.

P1S printers draw 350w @ 110v during preheat but only ~60w when printing PLA. Staggered start would help to have more machines on the same circuit.

One way we could do this, is a client-side solution, where we simply set a timer in your browser, and it doesn’t execute the “Send print” command before that timer is up. It’s not the best solution, and it means it wouldn’t just natively work in the app, and you’d have to keep your browser open.

The best solution would be the timer running on our servers, but we don’t currently have a good solution to do this in an efficient way, so this solution would be further away.

I’d love to get the discussion going on this topic, though, as for the technical aspects;

• Should there be settings? Say you can define “Max [x] printers start at once”
• What should be the determining factor of when the next printer(s) should start? Is it after the previous bunch are done heating up?

Since I saw my very first 100+ printer farm with my own eyes, the question of power draw has been on my mind as well, and we have seen instances of SimplyPrint kind of being to “blame” for power draw issues, as many pre-SP “naturally fixed” this, by the sheer fact that it took a while to manually start 40+ printers with an SD card… Darn efficiency!! 😆

I think it would be crucial to have a new set of groups set up to control the power. You would have printer groups as they currently exist for sending prints and then a second group that would mark what printers are on the same circuit.

I think ideally then you have a set of controls for each “power group” that controls how many printers are allowed to be preheating at a time.

We have space for another ~20 printers (about 85) where we are right now with unoptimized power. I haven’t wanted to have to stress too much with only allowing X printers to preheat at a time so they are set up to allow each printer to be able to preheating at the same time.

One idea to manage this would be to be able to define “preheat current”or “warmup current” or similar in your SimplyPrint printer profile (a numeric entry field in watts perhaps).

Then, as Laramie suggests, you could be able to define printer group with max current limit (max allowable startup current). Then have simply 3d only start the first X number of printers where the sum of “preheat” current doesn’t exceed the limit definded in the printer group. As the first printer(s) are no longer in the “preheat” or “warming up” stage, then it can start the next printer as long as the sum of currents will continue to be below the max allowable.

this makes sense. i am looking for the same thing. what i would suggest is to have an option to just “send print”. like a little checkbox that you can check where you send the print, but need to authorize the start on the printer itself. could that be done?

as an addendum, the reason i would like to add a nuance to this, is that i want to be able to queue prints, but do a local approval before starting the print. this way i can queue all prints, then i can go to the printer, clean the bed, press okay and then the new print would start.
\

Korneelb currently confirming the print start on the printer screen would not be feasible. This is due to our limited control when it comes to starting prints outside our control, as we don’t have any solid ways to know for sure which file you start, and what to “map” that file to in SimplyPrint; is it from your filesystem? Is it from the print queue?

In theory, we could store a map in our software of the file location we stored the file to on your printer, and what/where the file is in SimplyPrint, but this’d need a cross-platform solution, for Bambu, Prusa, OctoPrint, Klipper, & soon more; which is why we often prefer when things can be fixed in our software/platform, as that’s where we really have control.

I’d also argue - though open to being proven wrong - that a lot of people use SimplyPrint to not have to go to the printer and start the print. Yes, having the right file selected or transfered in the first place probably solves a lot of the headaches. But I’m unsure how widely used this feature of starting prints on the printer itself would be, and if the main reasoning is to stagger print starting, I’d argue there are better, automated, ways to do so, via our software.

well, you have to go to the printer anyway. you need to go there, clear the bed and confirm everything is ready for the next print. at that point i want to be able to confirm that the next print can start.

Yeah, I can see that. I can also see others preferring to clear all, then start all, but depends on your way of production really.

Right now, you wouldn’t be able to send a file to a printer without marking the bed as “Clear” first too, so there’s that “hurdle” as well.

We’ve thought about various ways to do something like you suggest, though in slightly different ways.

For Bambu printers, we have thought about integrating with the Bambu Touch, adding a “Start next print” button on that, so it starts on-demand on the printer. Same for Prusa printers with our soon-to-be-released-custom-firmware, and same for the X1Plus custom firmware for the X1.

That’s a scenario where starting of the print is still in our control, and we’re not at the mercy of a printer we don’t really control to give us the information we need upon starting prints.

But let’s see if more people see the point in the way you propose, @Korneelb - afterall, we’re mere software devs here; you guys are the print farm experts 💪

is there any possibility to realize a delayed start for the auto farm?
in my case I have 16 A1 printers, each one consumes 1.1 kw/h when heated. I have 15 kw electricity in my apartment. When all printers start at the same time the fuses are blown.

I would like to divide the printers and not run more than 4 or 8 at a time
I realize it’s not a big deal, but I’ve had this problem several times

I imagined there would be a worker thread that woke up every X seconds, who started the available jobs in the queue, and you could either configure how many jobs it could start at once, how often it woke up to start 1 job, and potentially even allow printers to have a property identify its “circuit group” so that the thread could act on each group every iteration.