Why are combinator balancers not used more?

Don't know how to use a machine? Looking for efficient setups? Stuck in a mission?
Post Reply
albertsune
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sun May 22, 2022 11:33 pm
Contact:

Why are combinator balancers not used more?

Post by albertsune »

I recently had to use an 11 to 7 balancer, and instead of finding a blueprint or creating my own, I made this:
combinator balancer.png
combinator balancer.png (140.92 KiB) Viewed 509 times
Simply, if there are enough items to make sure all belts have one, let them move forward.

So question is, why is this not used more? Are there any cases where this would not work? It seems to work perfectly well and makes weird ratio balancers extraordinarily easy.


A few notes:

I need to wire two rows of belts, as no items will be let onto a disabled belt at all. This would have made it way easier.

I cannot just activate if input=mod 7, I assume because it sometimes lets multiple items onto the belt at the same time, thus skipping the correct number. But as it only activates for one tick, this should not be a problem. Except:

I say "if there are enough items to make sure all belts have one, let them move forward". This is not entirely true, as it limits the throughput a bit to do this, not exactly sure why. So at the moment, I have my combinator check for 34, even though I in theory should check for 50. If anything causes it to be unbalanced, this would be it. Although it seems to work fine.


Here is the blueprint to check it out yourself:


Edit: If you wanted I suppose you could check each and every belt to make sure it has items. This would most likely make the balancing 100% accurate. I might try that later
Last edited by albertsune on Mon May 23, 2022 1:08 am, edited 2 times in total.

FuryoftheStars
Smart Inserter
Smart Inserter
Posts: 1198
Joined: Tue Apr 25, 2017 2:01 pm
Contact:

Re: Why are combinator balancers not used more?

Post by FuryoftheStars »

You can upload images and attach, and even place them inline with the text directly here on the forums. I mention this because whatever site or method you used for yours doesn’t load for me, so I can’t see what you’re talking about.

Loewchen
Global Moderator
Global Moderator
Posts: 7452
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Why are combinator balancers not used more?

Post by Loewchen »

Your links must BE an image, not a webpage that contains one.

albertsune
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sun May 22, 2022 11:33 pm
Contact:

Re: Why are combinator balancers not used more?

Post by albertsune »

Makes sense, Most pages just support Imgur. But here you go, uploaded inline image

astroshak
Filter Inserter
Filter Inserter
Posts: 514
Joined: Thu May 10, 2018 9:59 am
Contact:

Re: Why are combinator balancers not used more?

Post by astroshak »

I could see such a thing being “start-stop” under certain flow conditions. I’d rather have “always on, smooth flow”.

albertsune
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sun May 22, 2022 11:33 pm
Contact:

Re: Why are combinator balancers not used more?

Post by albertsune »

True, that is a good point. I'm just using it to load 7 train wagons though, smooth flow is not much of a concern.

If there are enough items on the belt it's still smooth though. So probably just depends on your use case

mmmPI
Smart Inserter
Smart Inserter
Posts: 1600
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: Why are combinator balancers not used more?

Post by mmmPI »

albertsune wrote:
Mon May 23, 2022 12:01 am
I recently had to use an 11 to 7 balancer, and instead of finding a blueprint or creating my own, I made this:

So question is, why is this not used more? Are there any cases where this would not work? It seems to work perfectly well and makes weird ratio balancers extraordinarily easy.
That's an interesting approach :), It is pretty uncommon to try and make a 11 to 7 balancer, those are quite large (prime) numbers, and at this point one could be tempted to instead make a 12=>8 which is more appealing numbers or 2x 6=>4 or even 4x 3=>2 balancers.

I think that's one part why we don't see those often. One doesn't really have to use a 11=>7 ! :lol:

Another one would be that nowadays with splitter priority being introduced for some time, it allows for different method than relying on balancer more easily, which makes some player design their factory a little differently to be able to use those. On a 11 lane bus going into a 7 lane bus (with same orientation as your picture ) one could decide to have the left most lane being the highest priority for the 11 lane bus, this you can do with just 10 splitters, all pushing the material on the left with priority.
Weirdbalancer.jpg
Weirdbalancer.jpg (464.94 KiB) Viewed 437 times

The 20 30 or 40 splitters version allows for more through put if by lack of luck the input only comes from the opposite side of the priority for most belts in the 11 inputs lanes but that shouldn't happen if you use the 10 splitter version or similar pattern of priority splitter along the bus. Using less splitters cost less ressources in game to expand, and also uses less ressoources from one's computer.

The thing i posted doesn't work as a balancer, if the input only comes from the priority lane, some other lane receive some material when things are backed up, some just don't.

This is not exactly about balancing evenly with 100% accuracy, but rather making things predictible, whenever a player chooses this method, there is no requirement for balancer, (be them with combinators or not). And combinators are not very popular (because of their complexity?) , part of the players don't use them, or the least possible.

Your method of balancing with the "34" threshold could be problematic if the input only comes from one side of each belts. ( 11 input belt with material only on the left side of each belts ). Because each belt can only have 4 item on each lane, so that would make only 28 items total in the connected belts. This can also be caused when the consumer of material is picking up more from one side of the belt. This could cause a stop that require manual intervention.

Maybe given how is built your factory the situation cannot happen in your case which makes your solution perfectly fine. You don't need the same things when you do ore=>trains or Green circuits=>many many things or enriched uranium or barrels. Your method is more the kind of things i would use for the later but not at this scale. I would use such large balancer for ore=>train when the shape of the ore patch doesnt allow to gauge easily for several separate balancer that are embedded with the train station depending on the number of wagon, for which i'm not going to choose 7 first in the list of probabilities more like 1 2 4 8.

FuryoftheStars
Smart Inserter
Smart Inserter
Posts: 1198
Joined: Tue Apr 25, 2017 2:01 pm
Contact:

Re: Why are combinator balancers not used more?

Post by FuryoftheStars »

That... is a crap load of splitters. :shock:

But yeah, as others have mentioned, I can see it not giving good flow in some situations.

Personally, I'd probably use an 11-11 or 12-12 balancer (which ever was easier to find :P) and just use the output splitter's filter feature to close off the unneeded output belts, our I'd pre-combine some of the belts to bring it down from 11 to 7 before feeding through a 7-7 balancer (or 8-8 with one of the output belts closed down. Again, whichever was easier to find).

But if your solution works for you, then have it. There's no 1 right answer to everything.

albertsune
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sun May 22, 2022 11:33 pm
Contact:

Re: Why are combinator balancers not used more?

Post by albertsune »

Thanks for your in-depth answer, I learned quite a bit from that. I only just recently returned from the game after a multiple year hiatus, so I'm a bit rusty.

But I totally agree, this is not very practical, especially at this scale. But after I got the idea, I just had to give it a try. Otherwise I would've just gone for the 12:8 balancer.

You could pretty easily get around the problem of items piling up on one side of the lanes by simply having a lane balancer on the inputs.

My biggest problem with it is exactly that it kinda doesn't just balance, just makes sure there are items on the belts, and if so, moves them forwards. As described, I tried activating it when the belts had mod 7 amount of items, but it always got stuck. Which is weird to me, since if nothing else, it should let it pass when all belts are filled.

Oh well, I'll probably keep fiddling with it, it seems like something noone has tried before, and I feel it might have some use cases.


And I probably should have went with 8 long trains yes, but I'm too lazy for a large redesign of my base. What one knows with hindsight has no bounds

albertsune
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sun May 22, 2022 11:33 pm
Contact:

Re: Why are combinator balancers not used more?

Post by albertsune »

FuryoftheStars wrote:
Mon May 23, 2022 1:41 pm
That... is a crap load of splitters. :shock:

But yeah, as others have mentioned, I can see it not giving good flow in some situations.

Personally, I'd probably use an 11-11 or 12-12 balancer (which ever was easier to find :P) and just use the output splitter's filter feature to close off the unneeded output belts, our I'd pre-combine some of the belts to bring it down from 11 to 7 before feeding through a 7-7 balancer (or 8-8 with one of the output belts closed down. Again, whichever was easier to find).

But if your solution works for you, then have it. There's no 1 right answer to everything.
Yes definitely, your solution is the "traditional" approach, and I would've done something similar if I didn't get this idea. I'll fiddle with it a bit to see if I can figure out the flow. What I think I'm close to, is just a simple n to m balancer for all n and m, a one size fits all solution

mmmPI
Smart Inserter
Smart Inserter
Posts: 1600
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: Why are combinator balancers not used more?

Post by mmmPI »

albertsune wrote:
Mon May 23, 2022 1:42 pm
My biggest problem with it is exactly that it kinda doesn't just balance, just makes sure there are items on the belts, and if so, moves them forwards. As described, I tried activating it when the belts had mod 7 amount of items, but it always got stuck. Which is weird to me, since if nothing else, it should let it pass when all belts are filled.

Oh well, I'll probably keep fiddling with it, it seems like something noone has tried before, and I feel it might have some use cases.
About the getting stuck i think it can happen when items are positionned on 2 belts when a belt is disabled. The item will count on 1 belt, but part of it will be on another one, which will prevent this previous belt from having 8 items when things backs up. I can't remember the exact figures but if an item need 16 ticks to go trough 1 piece of belt, if you stop the belt after 13 ticks, the item freeze but the 2 lane will not necessarily have the item aligned, if you have little gaps because the belts are not full, it makes it where you can have all sort of non modulo 7 result.

With the priority splitters pushing all material on one side, you can adapt your contraption to only check 1 belt, the one with the lowest priority, when it has 6 or more items, it means the others will be backed up with 6+ too. ( 7 or 8 ). That would mean the 1 row of wired belt used for counting input is replaced by only 1 belt, and 34 becomes 6. ( and diagonal pattern of splitter).

The balancing being done by little stutter the throughput is impacted a little you do not get a full belt of output but it looks cool when belts are not filled.

In this case as belts goes on/off/on/off there is still the risk of a little variation over time because sometimes a belt will be on, but the material will be backed up, and some more material will go onto another belt on at the same time, but with a longer buffer to reach the wagon for example. It is not a "count perfect" balancer as you mention, nor it is a "troughput unlimited"/'"maxed" but it's rare when those are strictly required, if loading trains, not being count perfect by 1 or 5 when belts are full is not a problem :).

Nidan
Long Handed Inserter
Long Handed Inserter
Posts: 96
Joined: Sat Nov 21, 2015 1:40 am
Contact:

Re: Why are combinator balancers not used more?

Post by Nidan »

mmmPI wrote:
Mon May 23, 2022 3:42 pm
About the getting stuck i think it can happen when items are positionned on 2 belts when a belt is disabled. The item will count on 1 belt, but part of it will be on another one, which will prevent this previous belt from having 8 items when things backs up. I can't remember the exact figures but if an item need 16 ticks to go trough 1 piece of belt, if you stop the belt after 13 ticks, the item freeze but the 2 lane will not necessarily have the item aligned, if you have little gaps because the belts are not full, it makes it where you can have all sort of non modulo 7 result.
This used to be the case, but since 0.17 one lane of a straight piece of belt holds 4 items exactly, regardless of positioning.

A count perfect, full throughput(*), circuit based(**) balancer is possible:

The blueprint includes some combinators to test whether the output is count perfect. If the lamps turn, there was an imbalance. Turning on the R constant combinator resets the detection logic.


*) If the splitters in front allows for it; the circuit logic doesn't create a bottleneck.
**) No combinators needed.

User avatar
Nosferatu
Fast Inserter
Fast Inserter
Posts: 157
Joined: Fri Jan 20, 2017 4:48 pm
Contact:

Re: Why are combinator balancers not used more?

Post by Nosferatu »

albertsune wrote:
Mon May 23, 2022 1:42 pm
And I probably should have went with 8 long trains yes, but I'm too lazy for a large redesign of my base. What one knows with hindsight has no bounds
I ran into the same thing :D . I don't know what made me think 7 cargo wagons are ideal but when I realized my mistake my base was already huge...
It took me many hours of denial until I made myself redesigning everything to 8 wagons. It's a long and painful process.

mmmPI
Smart Inserter
Smart Inserter
Posts: 1600
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: Why are combinator balancers not used more?

Post by mmmPI »

Nidan wrote:
Mon May 23, 2022 5:39 pm
This used to be the case, but since 0.17 one lane of a straight piece of belt holds 4 items exactly, regardless of positioning.
I was already going to trust you on that, and when toying a bit with the blueprint i had the occasion to verify it, no matter the offset and or gaps between items on the belt that is circuit-stopped, the previous one will have 8.

My other thought then is that maybe the ore patch was containing mixed ore, or some pieces of stone or coal that if present on the belt would prevent further contamination at the cost of sudden stop. the mod 7 like using 56 both impacted similarly.



Nidan wrote:
Mon May 23, 2022 5:39 pm
A count perfect, full throughput(*), circuit based(**) balancer is possible:
The blueprint includes some combinators to test whether the output is count perfect. If the lamps turn, there was an imbalance. Turning on the R constant combinator resets the detection logic.

*) If the splitters in front allows for it; the circuit logic doesn't create a bottleneck.
Ah yes the combinator contraption function well, much better looking than just checking 1 low priority belt. Though the splitter matrix in front of it doesn't guarantee full throughput in certain case purposedly choosen to be the expected worse :D
throughputcap.jpg
throughputcap.jpg (427.59 KiB) Viewed 358 times
It's not much but in plays a role if your ore patch deplete from left to right, or rather all line at a time. One wishing to be very precise would ask if it is count perfect on the ouput AND input ;) none of the design shown here can achieve that i've tested them :p, with priorities following the red lines, it doesn't stutter anymore on this particular configuration, but perform much worse when the input is coming from the other side ( things that shouldn't happen in regular mining operation ).

Nidan
Long Handed Inserter
Long Handed Inserter
Posts: 96
Joined: Sat Nov 21, 2015 1:40 am
Contact:

Re: Why are combinator balancers not used more?

Post by Nidan »

mmmPI wrote:
Mon May 23, 2022 7:47 pm
My other thought then is that maybe the ore patch was containing mixed ore, or some pieces of stone or coal that if present on the belt would prevent further contamination at the cost of sudden stop. the mod 7 like using 56 both impacted similarly.
Balancing each lane or individual items is impossible since we can only stop whole belts. Ignoring the item type works if we reintroduce OPs combinator to sum them up (each + 0 -> signal other than each). Personally I prefer to sort out other items early, one splitter per lane isn't that expensive nor space consuming.
mmmPI wrote:
Mon May 23, 2022 7:47 pm
Nidan wrote:
Mon May 23, 2022 5:39 pm
*) If the splitters in front allows for it; the circuit logic doesn't create a bottleneck.
Ah yes the combinator contraption function well, much better looking than just checking 1 low priority belt. Though the splitter matrix in front of it doesn't guarantee full throughput in certain case purposedly choosen to be the expected worse :D
I knew my splitter arrangement is flawed, that's the main reason for the footnote ;)
It's not much but in plays a role if your ore patch deplete from left to right, or rather all line at a time. One wishing to be very precise would ask if it is count perfect on the ouput AND input ;) none of the design shown here can achieve that i've tested them :p, with priorities following the red lines, it doesn't stutter anymore on this particular configuration, but perform much worse when the input is coming from the other side ( things that shouldn't happen in regular mining operation ).
The splitter arrangement you need for count perfect input is a balancer itself so the circuitry becomes superfluous... For doing count perfect input in combinators, here's a rough untested idea: Same arrangement of measuring and stopping belts as for the output. If measured input is smaller than output capacity (=56) let all belts move. Once it's greater belts only run 7 out of 11 ticks. However this falls apart if the input is too uneven or an output is blocked.

Post Reply

Return to “Gameplay Help”