Belt Balancer

[LabelFive]

Here i made a belt balancer. I was boring to see one side of my belts being used because of side priority of the inserters. So there is my system :



With this system, if you take only the red or blue side of the belt in your inventory (or taken by an inserter), the yellow input will be balancing. It will take equally the two side of the belt. Try it, i'm really bad in english and i don't know how to explain it in a better way! I like to put this system at the end of my furnace for example, very good balancing!

Edit : A little bit compact.

[XKnight]

Look at this thread: https://forums.factorio.com/forum/vie ... =5&t=15366

This version is a little bit smaller and saves 4 belts:

[Zeblote]

This should be a 1x1 entity, a splitter for a single belt. Not a huge contraption...

[LabelFive]

Ok i feel stupid now, this system work perfectly! But i find mine when i was thinking "this side will be priotary, so i have to split there... etc!" so i'm still proud of me

[vanatteveldt]

Doesn't the good old fashioned single splitter to "3-way merge" work just as well?

Code: Select all

    ┌┐
───╫┘├───
   ╫─┘

[ratchetfreak]

Doesn't the good old fashioned single splitter to "3-way merge" work just as well?

Code: Select all

    ┌┐
───╫┘├───
   ╫─┘

That provides a good output but if one lane doesn't get used then the opposite input lane backs up.

[LabelFive]

Doesn't the good old fashioned single splitter to "3-way merge" work just as well?

Code: Select all

    ┌┐
───╫┘├───
   ╫─┘

AS he says, that doesn't work for the input. It will be not balancing. Try to take only one side of the belt in the output, you will understand.

[vanatteveldt]

A right, I was thinking of balancing input lanes, not output lanes. Sorry for the noise

(on the plus side, I did have some fun drawing with ascii lines charcters like it's 1985 again!)

[grabulis]

merged from Gameplay Help
-- daniel34

Currently playing my first game of factorio and using main bus concept for my factory. Soon I noticed that one lane of the belt is favored over other as asymmetry arise in production building placement around main bus (most of the buildings were at the bottom). This caused resource shortages for production buildings which relied on resources from favorite lane and shutdown of half of the resource production buildings (smelters, circuit producers etc.) as one lane was full and those buildings were not able to dispose of their products. I tried to fix lanes using rebalancers which used spliter and put half of the items from full lane to empty lane. This was temporary fix as after adding extra production building asymmetry was back and balancing was not dynamic enough to adapt for changing "favorite" lane of belt.

I come up with balancer which guarantees that items will be distributed evenly on belt not only after balancer but will be picked up evenly before balancer. In cases when one lane after the balancer is full items from both lanes of belt will be put on free (favorite) lane.

I found it useful to place balancer after resource production buildings (smelters) which eliminated issues with shutdown of half of production buildings in cases when one lane of the belt were full. Using balancer for belt merging after mines helps to mine deposits more evenly.

Operation principle for balancer is that one belt is split in two belts and lanes of one of the result belts are flipped and then resulting belts are merged by spliter.

Notice how in example only one of output lanes is used but both of input lanes of belt are consumed.



Balancer works well for following belt configurations (1 to 1; 1 to 2; 2 to 1; 2 to 2). Basically all unused/empty splitter slots can be connected to belt and balancer still will work as described.

[grabulis]

Great. I was facing same issue and come up with my solution to problem. Even posted design(on a wrong board it seems ). Now I feel silly. For a game being around for so long time it seems there is no problem which is not solved by someone else already .

[XKnight]

Great. I was facing same issue and come up with my solution to problem. Even posted design(on a wrong board it seems ). Now I feel silly. For a game being around for so long time it seems there is no problem which is not solved by someone else already .

a little bit simplified:

1.png (122.16 KiB) Viewed 24003 times

[RoseArtemis]

Would this not be the most compact 1-1 belt balancer possible? I don't know how it acts if there is uneven usage on either side of the output but this is what I'm using and I have no problem with it

[orzelek]

Would this not be the most compact 1-1 belt balancer possible? I don't know how it acts if there is uneven usage on either side of the output but this is what I'm using and I have no problem with it

It won't handle full belt throughput. It should work quite well if you don't need to use full belt of materials.

[RoseArtemis]

It won't handle full belt throughput. It should work quite well if you don't need to use full belt of materials.

Ah ok, thanks. I don't have enough copper in that particular copper mining setup for it to fill the belt so this works as well as it needs to for me then!

[daniel34]

Would this not be the most compact 1-1 belt balancer possible? I don't know how it acts if there is uneven usage on either side of the output but this is what I'm using and I have no problem with it

I always use this one:

Takes the same space and provides (almost, like 95% I think) full compression by sideloading after the splitting instead of before. And provides completely even output for both sides.
In case one output side is full it puts all the incoming ore on the other side.

[ElTorres]

This is wath i got from it...

[ElTorres]

Would this not be the most compact 1-1 belt balancer possible? I don't know how it acts if there is uneven usage on either side of the output but this is what I'm using and I have no problem with it

I always use this one:

Takes the same space and provides (almost, like 95% I think) full compression by sideloading after the splitting instead of before. And provides completely even output for both sides.
In case one output side is full it puts all the incoming ore on the other side.

This design won't balance input, if 1 side of the belt is used, and the other backs up, the side-loading will only use 1 side of the belt.

[Mehve]

The second design (by Daniel34) works fine. Because of the splitter, both lanes of the input belt can be sideloaded onto either lane of the output belt as space allows. Try feeding it a single lane and watch it balance things out.

On the other hand, that example by Rose there will be capped at a single lane of throughput because everything has to go through the first sideloading process.

[hansinator]

The second design (by Daniel34) works fine. Because of the splitter, both lanes of the input belt can be sideloaded onto either lane of the output belt as space allows. Try feeding it a single lane and watch it balance things out.

On the other hand, that example by Rose there will be capped at a single lane of throughput because everything has to go through the first sideloading process.

No it doesn't work fine. If you block one side of the output it will only pull from one side on the input. There are other designs in this thread that draw equally from each side, but they are big. This one is the most compact with the least parts:


I found it here: https://imgur.com/a/sgAsj

[Mehve]

The second design (by Daniel34) works fine. Because of the splitter, both lanes of the input belt can be sideloaded onto either lane of the output belt as space allows. Try feeding it a single lane and watch it balance things out.

On the other hand, that example by Rose there will be capped at a single lane of throughput because everything has to go through the first sideloading process.

No it doesn't work fine. If you block one side of the output it will only pull from one side on the input. There are other designs in this thread that draw equally from each side, but they are big. This one is the most compact with the least parts:


I found it here: https://imgur.com/a/sgAsj

*facepalm* I had to stare at that for a little, before I finally realized that I'd been thinking of a non-compressed input situation. And you're right, the splitter wouldn't hold up at that point.