Why are combinator balancers not used more?
-
- Burner Inserter
- Posts: 5
- Joined: Sun May 22, 2022 11:33 pm
- Contact:
Why are combinator balancers not used more?
I recently had to use an 11 to 7 balancer, and instead of finding a blueprint or creating my own, I made this:
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
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.
-
- Smart Inserter
- Posts: 2530
- Joined: Tue Apr 25, 2017 2:01 pm
- Contact:
Re: Why are combinator balancers not used more?
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.
My Mods: Classic Factorio Basic Oil Processing | Sulfur Production from Oils | Wood to Oil Processing | Infinite Resources - Normal Yield | Tree Saplings (Redux) | Alien Biomes Tweaked | Restrictions on Artificial Tiles
Re: Why are combinator balancers not used more?
Your links must BE an image, not a webpage that contains one.
-
- Burner Inserter
- Posts: 5
- Joined: Sun May 22, 2022 11:33 pm
- Contact:
Re: Why are combinator balancers not used more?
Makes sense, Most pages just support Imgur. But here you go, uploaded inline image
Re: Why are combinator balancers not used more?
I could see such a thing being “start-stop” under certain flow conditions. I’d rather have “always on, smooth flow”.
-
- Burner Inserter
- Posts: 5
- Joined: Sun May 22, 2022 11:33 pm
- Contact:
Re: Why are combinator balancers not used more?
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
If there are enough items on the belt it's still smooth though. So probably just depends on your use case
Re: Why are combinator balancers not used more?
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.albertsune wrote: ↑Mon May 23, 2022 12:01 amI 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.
I think that's one part why we don't see those often. One doesn't really have to use a 11=>7 !
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.
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.
-
- Smart Inserter
- Posts: 2530
- Joined: Tue Apr 25, 2017 2:01 pm
- Contact:
Re: Why are combinator balancers not used more?
That... is a crap load of splitters.
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 ) 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.
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 ) 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.
My Mods: Classic Factorio Basic Oil Processing | Sulfur Production from Oils | Wood to Oil Processing | Infinite Resources - Normal Yield | Tree Saplings (Redux) | Alien Biomes Tweaked | Restrictions on Artificial Tiles
-
- Burner Inserter
- Posts: 5
- Joined: Sun May 22, 2022 11:33 pm
- Contact:
Re: Why are combinator balancers not used more?
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
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
-
- Burner Inserter
- Posts: 5
- Joined: Sun May 22, 2022 11:33 pm
- Contact:
Re: Why are combinator balancers not used more?
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 solutionFuryoftheStars wrote: ↑Mon May 23, 2022 1:41 pmThat... is a crap load of splitters.
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 ) 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.
Re: Why are combinator balancers not used more?
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.albertsune wrote: ↑Mon May 23, 2022 1:42 pmMy 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.
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 .
Re: Why are combinator balancers not used more?
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.mmmPI wrote: ↑Mon May 23, 2022 3:42 pmAbout 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.
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.
Re: Why are combinator balancers not used more?
I ran into the same thing . I don't know what made me think 7 cargo wagons are ideal but when I realized my mistake my base was already huge...albertsune wrote: ↑Mon May 23, 2022 1:42 pmAnd 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
It took me many hours of denial until I made myself redesigning everything to 8 wagons. It's a long and painful process.
Re: Why are combinator balancers not used more?
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.
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 worseNidan wrote: ↑Mon May 23, 2022 5:39 pmA 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.
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 ).
Re: Why are combinator balancers not used more?
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.
I knew my splitter arrangement is flawed, that's the main reason for the footnote
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.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 ).