I was googling for a 4to4 balancer that pulls equally from the 4 *input* lanes to keep my train station chests always equally full regardless of demand.
I was shocked that after all these years it would be so hard to find a good design. I found rayquist's collection, but it doesn't make it clear whether its balancer is input-balanced. And I found a couple other designs... with discussions that left me scratching my head. I even found some lane balancers. But no clear winner.
Is there a 4to4 input-balanced design that is recognized as the best, simplest and "standard"? Or better yet, a collection of input balancers?
Tried and tested *input* belt balancers
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Tried and tested *input* belt balancers
If there is an "L"in the name, the balancers are input balanced. (Rayquyst's book)
On Factorio discord this came up a few days ago, and this one is a 2 lane version input lane balancer. otherwise the rayquyst ones are pretty much the standard.
https://discord.com/channels/1396775903 ... 3212352522
https://imgur.com/a/6A6whT0
On Factorio discord this came up a few days ago, and this one is a 2 lane version input lane balancer. otherwise the rayquyst ones are pretty much the standard.
https://discord.com/channels/1396775903 ... 3212352522
https://imgur.com/a/6A6whT0
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Tried and tested *input* belt balancers
I think you misunderstood, I don't mean Lane balance, I mean balanced to pull from the 4 input chests equally, regardless of how the downstream demand might pull from one or more of the four belts.disentius wrote: ↑Tue Feb 21, 2023 10:12 amIf there is an "L"in the name, the balancers are input balanced. (Rayquyst's book)
On Factorio discord this came up a few days ago, and this one is a 2 lane version input lane balancer. otherwise the rayquyst ones are pretty much the standard.
https://discord.com/channels/1396775903 ... 3212352522
https://imgur.com/a/6A6whT0
I found some designs labeled Universl balancers, in the sense that theyare input, lane and output balancers at the same time, they will do the job but they are overkill for my need. What I am looking for is the simplest design that pulls equally from each of the belts/chests.
Re: Tried and tested *input* belt balancers
Input balanced is per definition input lane balanced, since the lanes can be independently consumed downstream, and you want to consume the input lanes evenly.
And I agree, TU is overkill in most situations.
And I agree, TU is overkill in most situations.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Tried and tested *input* belt balancers
Are you saying that all designs that are marked as "Lane" balanced are assumed to be "Input Belt" balanced in addition to being Lane balanced?
If so, that would simplify things a lot.
Re: Tried and tested *input* belt balancers
Just using a 4to4 lane balancer doesn't completely ensure chests are unloaded equally. It also depends on how items are pulled from the chests. If there is just one inserter pulling from one chest feeding one lane, all is fine. Put a lane balancer behind and everything is pulled equally.
But if you want to output fully compressed belts, it can happen you need to feed one lane from 2 chests, for example if you want to output a fully compressed blue belt. In this case, you need to make sure both inserters feeding one lane also work in a balanced way.
This is mind boggling. I spent multiple evenings to even find this as the cause of observed unequal unload where I already used a lane balancer and analyzing why this happens.
You find no discussion of this, because the issue suddenly disappears as soon as you overfill the station. On unloading, the first chests get full and the chests that are still not full get the rest of what's in the wagon. That's the missing balancing. It happens, if trains can deliver items faster than the factory can consume it. If that happens, you're fine and not even need lane balancing any more, only belt balancing to ensure all wagons are emptied equally.
The next text is what I found out what happens if you don't overfill a station, for example if you dynamically set station limits to explicitly avoid this.
A probably common unloading station setup for 4 wagons to 4 blue belts is this:
First 2 chests+insertes per lane merged, then a 4to4 lane balancer. Should be fine.
But actually no, not exactly. Isn't perfectly balanced in the long run. The right 2 chests of every wagon (group of 4 chests) are unloaded differently in comparison to the left 2 chests. This happens, because the long belt curves on the left act as small buffer, while the short curves on the right will not. So the 2 inserters on the right of group of 4 chests will stall more often, while the 2 inserters on the left operate longer, because their items flow into the gaps they leave when the inserters swings back, so the left 2 chests are emptied better and the right 2 chests are emptied less.
I made just a tiny adjustment:
I changed one section to a red belt. This way, every inserter will stall at the same time - when the 30/s limit of the red belt is reached. The overall throughput is still 45/s as fully compressed blue belt, since every group of 2 inserters are merged into a blue belt.
This is what I got as near as possible to a mechanical fully balanced unloading station. It's still not 100% balanced - after 10 hours or so you will again see unbalanced chests, even with 100% perfectly balanced output via loaders into infinity chests.
My last try at balancing was actively controlling inserters with circuit network. There are a few examples on the web. If done right, this works in general. However the result is not 100% compressed belts. Throughput is only 43-44/s, not full 45/s. That's because to ensure balancing, some inserters are deactivated until other inserters emptied their chests, and this is what creates tiny gaps that result in less throughput. Unavoidable for blue belts, since there is no buffering possible, because there are no faster belts than 45/s.
As I said, all this suddenly vanishes as soon as you provide enough train input that your chests will overflow when filled from the wagons.
But if you want to output fully compressed belts, it can happen you need to feed one lane from 2 chests, for example if you want to output a fully compressed blue belt. In this case, you need to make sure both inserters feeding one lane also work in a balanced way.
This is mind boggling. I spent multiple evenings to even find this as the cause of observed unequal unload where I already used a lane balancer and analyzing why this happens.
You find no discussion of this, because the issue suddenly disappears as soon as you overfill the station. On unloading, the first chests get full and the chests that are still not full get the rest of what's in the wagon. That's the missing balancing. It happens, if trains can deliver items faster than the factory can consume it. If that happens, you're fine and not even need lane balancing any more, only belt balancing to ensure all wagons are emptied equally.
The next text is what I found out what happens if you don't overfill a station, for example if you dynamically set station limits to explicitly avoid this.
A probably common unloading station setup for 4 wagons to 4 blue belts is this:
- Screenshot_20230221_140633.png (260.73 KiB) Viewed 2677 times
But actually no, not exactly. Isn't perfectly balanced in the long run. The right 2 chests of every wagon (group of 4 chests) are unloaded differently in comparison to the left 2 chests. This happens, because the long belt curves on the left act as small buffer, while the short curves on the right will not. So the 2 inserters on the right of group of 4 chests will stall more often, while the 2 inserters on the left operate longer, because their items flow into the gaps they leave when the inserters swings back, so the left 2 chests are emptied better and the right 2 chests are emptied less.
I made just a tiny adjustment:
- Screenshot_20230221_140518.png (259.54 KiB) Viewed 2677 times
This is what I got as near as possible to a mechanical fully balanced unloading station. It's still not 100% balanced - after 10 hours or so you will again see unbalanced chests, even with 100% perfectly balanced output via loaders into infinity chests.
My last try at balancing was actively controlling inserters with circuit network. There are a few examples on the web. If done right, this works in general. However the result is not 100% compressed belts. Throughput is only 43-44/s, not full 45/s. That's because to ensure balancing, some inserters are deactivated until other inserters emptied their chests, and this is what creates tiny gaps that result in less throughput. Unavoidable for blue belts, since there is no buffering possible, because there are no faster belts than 45/s.
As I said, all this suddenly vanishes as soon as you provide enough train input that your chests will overflow when filled from the wagons.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Tried and tested *input* belt balancers
Indeed Tertius, I experienced what you describe (happens even more with LTN because you never really get to the point of filling the receiving station). I once (years ago) found a solution but I am returning to the game after a long time and I am having to rediscover everything.
In the end the balancing gets annoying. I completely bypassed the loading/unloading clog of balancing "a wagon" by using the miniloader mod. A single miniloader loads/unloads a blue belt.
That is why the remaining piece was the input balancer for unloads. As of today I started using the L 4x4 balancer.
In the end the balancing gets annoying. I completely bypassed the loading/unloading clog of balancing "a wagon" by using the miniloader mod. A single miniloader loads/unloads a blue belt.
That is why the remaining piece was the input balancer for unloads. As of today I started using the L 4x4 balancer.
Re: Tried and tested *input* belt balancers
This is not what is going on, as far as I can tell. With your design, but emptying infinity chests (instead of steel chests) onto the belt/underground exits and consuming all output, I found the maximum difference in the total amounts moved by any pair of inserters did not increase over time (ie the unloading is even), with or without the fast belts.
Following hours of head-scratching after discovering the same problem, I realised that depending on wagon stacks, item stack size, inserters per wagon and inserter stack size, some inserters may pick up fewer or no items in the "last swing" as the wagon is emptied. Which inserters is unpredictable but consistent (presumably due to inserter update order), so even if the chests are emptied perfectly evenly the effect builds up over time, unless the chests completely empty/fill/reach their stack limit to reset the imbalance.
For example, for a wagon of 2000 ore and four stack inserters with stack size 12, after 31 swings, 32 ore will remain in the wagon, so two inserters will take 12 each, one inserter will take eight, and one will get none. The same inserters will do the same thing with the next train, and the next, ... This can be completely avoided by reducing the stack size to ten, obviously at the cost of increased unload time.
This can probably be resolved with a larger buffer (ie more belt) before merging belts from a wagon with a splitter, so items "delayed" by an inserter being disabled can "catch up" before both splitter inputs are empty. But in practice it often doesn't matter as you can just (or it may be natural to) design for slightly under 45/s.
Re: Tried and tested *input* belt balancers
This makes sense. This can explain my observation. Thanks for the insight!SoShootMe wrote: ↑Tue Feb 21, 2023 8:17 pmFor example, for a wagon of 2000 ore and four stack inserters with stack size 12, after 31 swings, 32 ore will remain in the wagon, so two inserters will take 12 each, one inserter will take eight, and one will get none. The same inserters will do the same thing with the next train, and the next, ... This can be completely avoided by reducing the stack size to ten, obviously at the cost of increased unload time.
So the wagon capacity must be a multiple of inserter stack size multiplied with amount of chests per wagon to avoid imbalance. I wonder which logistics in the real world has similar subtle issues and how these are resolved. It's fascinating how Factorio teaches with stuff like this that logistics is more than just ordering some trucks, trains or ships to pick up my goods and carry it away.
-
FuryoftheStars
- Smart Inserter
- Posts: 2542
- Joined: Tue Apr 25, 2017 2:01 pm
- Contact:
Re: Tried and tested *input* belt balancers
I have a feeling real world doesn't care about it as much.
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: Tried and tested *input* belt balancers
To be precise, a multiple of min(item_stack_size, inserter_stack_limit) * chests_per_wagon. As far as I know, the only practical alternatives are as you mentioned: to circuit control inserters to limit imbalance, or to allow the chests to completely fill/reach their stack limit.
Re: Tried and tested *input* belt balancers
Finally, I came up with the ultimate solution of an active balancing. Very simple, strange it always slipped my mind. To balance unloading as a whole, don't balance the part that's emptying the chests. That's what we all tried to do in vain with belt balancers or with circuit controlled chest unloading.SoShootMe wrote: ↑Tue Feb 21, 2023 8:17 pmFor example, for a wagon of 2000 ore and four stack inserters with stack size 12, after 31 swings, 32 ore will remain in the wagon, so two inserters will take 12 each, one inserter will take eight, and one will get none. The same inserters will do the same thing with the next train, and the next, ... This can be completely avoided by reducing the stack size to ten, obviously at the cost of increased unload time.
Instead, balance filling the chests. If one chest gets unevenly filled, because the wagon doesn't have an equal share for all inserters as you explained, do fill it first the next time a full train arrives. In general: balance with the well known circuit concept that computes the average chest item count and activate only the inserters in front of a chest that has less than the average.
Nice side effect: remedy for uneven lanes is included implicitly. It's not really lane balancing, but we don't need to take care of lane balancing any more.
What is still required is balancing the wagons. It's still useful to make sure every wagon as a whole is unloaded equally compared to the other wagons. Otherwise the train waits for unloading the last wagon while the buffer chests of the other wagons get empty again.
Example:
- Screenshot 2023-04-03 005511.png (1.11 MiB) Viewed 2369 times
Blueprint includes a complete test loop to see how chest fill state stays balanced even after hours of runtime. I added uneven item consuming including lane unbalance to prove it's actually working as intended. The 4:4 belt balancer is for balancing between the wagons.
To compute the train limit, the values in the constant combinators are station capacity divided by amount of chests per wagon (here: 38400 / 4 = 9600 iron ore) and train capacity divided by amount of chests per wagon (here: 8000 / 4 = 2000). The division by 4 is the consequence of computing the average - unfortunately, it's not possible to directly connect all chests to count the total, because the 2 wires are already used up per chest and per wagon.
Re: Tried and tested *input* belt balancers
One reason I'm aware of leading to the conventional technique of controlling the belt-loading inserters rather than wagon-unloading inserters is that any time wagon-unloading inserters are disabled means increased unload time. In contrast, four belt-loading inserters are more than able to support full belt throughput, so if some are disabled briefly every so often (in order to balance the chests), throughput isn't affected, given sufficient buffer before merging the belts of a single wagon (as I described before).
If the chests are emptied evenly, the increase in unload time should be small and inherently limited, but with your layout (where each inserter contributes to only one side of the output belts) that requires lane balancing. Put another way, the "nice side effect" is actually a benefit of not needing lane balancing at a cost of increased unload time.
Re: Tried and tested *input* belt balancers
If you remove circuits from one of the wagons, you will see the increased unload time with circuits is one or two additional inserter swings. Not very much. In contrast to this, I always got tiny gaps at the output if controlling the belt-loading inserters. I just didn't want to create huge buffer zones. An increased size of 2-3 additional belt pieces for buffering is not enough, if the output is a blue belt.
Overall, it's an improvement over not actively balancing (neither circuit nor balancer) at all, where the balancing is implicitly achieved by overfilling the chests. By overfilling, full chests are not filled any more and the not yet full chests get the rest, so the overall fill state is evened out. This increases unloading time definitely more than using the circuit at the wagon-unloading inserters.
If you replace the 4:4 balancer with the slightly bigger 4:4 lane balancer from the screenshot a few posts above, the circuit has to only balance out the uneven unloading of the last few pieces, however this could probably be considered overengineering.
Overall, it's an improvement over not actively balancing (neither circuit nor balancer) at all, where the balancing is implicitly achieved by overfilling the chests. By overfilling, full chests are not filled any more and the not yet full chests get the rest, so the overall fill state is evened out. This increases unloading time definitely more than using the circuit at the wagon-unloading inserters.
If you replace the 4:4 balancer with the slightly bigger 4:4 lane balancer from the screenshot a few posts above, the circuit has to only balance out the uneven unloading of the last few pieces, however this could probably be considered overengineering.
Re: Tried and tested *input* belt balancers
Putin's chest (factorio reddit) has made a simple solution lane balance first, then belt balance later.
Works for all belt types.
thoughts?
Works for all belt types.
thoughts?
- balanced unloader.jpg (284.68 KiB) Viewed 2303 times
Re: Tried and tested *input* belt balancers
Does chest-to-belt balancing perfectly, also does perfect lane balancing, however it suffers the same wagon-to-chest imbalance we talked about. If a wagon is about to get empty, the last stack contains 32 items, so with the last swing two inserters get 12 items, one inserter gets 8, and the last gets nothing. If you observe the unloading process, you will notice it's always the same inserters, so one chest gets always 4 items less and one gets always 12 items less than the other 2 for every unload circle. This adds up to a severe imbalance between chests that's only stopped as soon as the two fullest chest get completely full and the remaining still get filled, which increases overall unloading time.
Because of this, I offered that circuit controlled balancing of the wagon-to-chest inserters above. It solves this uneven wagon unloading.
Difficult to tell, if the reddit unloader has a bigger UPS impact than the one above with the 4:4 balancer replaced with the 4:4 lane balancer:
This one has 57 blue belts, 28 underground pieces, 12 splitters, 12 sideloads.
The reddit one has 71 blue belts, 16 underground pieces, 18 splitters, 8 sideloads.
For UPS, difference is 6 splitters less but 4 sideloads more against 6 splitters more but 4 sideloads less. Dunno what is better. The advantage of the 4:4 lane balancer at the end is that you can leave it out completely in case you don't need it due to the item demand of the production line you're feeding. (It seems I sound like a used car seller)
Because of this, I offered that circuit controlled balancing of the wagon-to-chest inserters above. It solves this uneven wagon unloading.
Difficult to tell, if the reddit unloader has a bigger UPS impact than the one above with the 4:4 balancer replaced with the 4:4 lane balancer:
- Screenshot 2023-04-03 170949.png (346.66 KiB) Viewed 2281 times
The reddit one has 71 blue belts, 16 underground pieces, 18 splitters, 8 sideloads.
For UPS, difference is 6 splitters less but 4 sideloads more against 6 splitters more but 4 sideloads less. Dunno what is better. The advantage of the 4:4 lane balancer at the end is that you can leave it out completely in case you don't need it due to the item demand of the production line you're feeding. (It seems I sound like a used car seller)
Re: Tried and tested *input* belt balancers
You are correct, the "last grab inbalance" is not solved by this system.
hm. would setting max stacksize 10 om the inserters not solve that?
hm. would setting max stacksize 10 om the inserters not solve that?
Re: Tried and tested *input* belt balancers
Yes, however that will increase unloading time by about 20%, since you transfer only 83% items per swing.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Tried and tested *input* belt balancers
If you are open to using mods, I found that the combination of LTN (to deliver full trains but never fully fill the unload chests), Bulk Loaders (for a single unload chest), and Miniloaders (unloads a full fully balanced belt) plus a full balancer like Rainquist's 4x4L or the one a couple posts up... results in reliable unloads.
I now even add a splitter with the filter set to the expected item to deal with human error when I cut/paste stations and receive the wrong kind of train... that way any pollution stops at the unload. Or even better... a trivial conditional combinator that sends the "disable" signal to the Bulk Unloader when the desired item is not on the train. Yep, pretty paranoid, but it's saved me from many mistakes I made.
I now even add a splitter with the filter set to the expected item to deal with human error when I cut/paste stations and receive the wrong kind of train... that way any pollution stops at the unload. Or even better... a trivial conditional combinator that sends the "disable" signal to the Bulk Unloader when the desired item is not on the train. Yep, pretty paranoid, but it's saved me from many mistakes I made.