Balanced buffer

[Neotix]

It's easy setup to balance buffer. It can be also used in train station.
Smart inserters will take items to fill chest equally and also take from chest equally.
It can be expanded to any number of chests.

Diagram


Example in game

[MrElektro]

This is nice, exactly what i need for my train stations. Thank you!

[XKnight]

You will laugh, but I never even think about this problem...
This build definitely has the highest "benefit/complexity" value.
It even deserves to take place in my bookmarks (for one year on this forum your post is eighth one I added to bookmarks).

Great job!

P.S. minor improvements like using const comb instead of regular comb may be added.

[siggboy]

I love this for its simplicity and elegance. It's one of the very, very few examples of a useful combinator setup that does not require Black Magic.

Why would you need this for train stations, though? When you unload a wagon, the buffer chests will fill evenly. If you end up with uneven buffer chests then it's because you don't load the belt correctly, or the unloading belt is completely backed up, in which case it really doesn't matter if your buffer is evenly filled or not.

To be honest, I'm trying to think of a place right now where you really need this but nothing comes to mind.

Maybe it's good in any case if you have very uneven demand, lot's of spikes between very low and very high (also on the exit of smelting setups I guess).

[Neotix]

Unloading to buffer is evenly but unloading buffer on belt is not. You have to build belt spaghetti with splitters to achieve the same results. I'm using balancer and straight belt to unload items from buffer.

The same way with loading. Balancer fill buffer evenly and then inserters will load wagons. I don't have to worry that some buffer chest are full and others are empty, I know that when train arrive, wagons will be filled with he same amount.

Example:
Loading station with belt spaghetti
http://home.cogeco.ca/~glassdeviant/rai ... g_demo.jpg

My loading station
https://i.gyazo.com/683ce147ef8a1336ae8 ... 1e20ac.png

[siggboy]

Yes, you are right, it greatly simplifies the loading bay (from belt to train), there's no need for a splitter at each wagon and with multiple wagons you only need to split among the wagons (or use overpowered belts from Bob's Mods, like you do :). I realized it by myself since my last posting. I also remembered somebody posting his train station blueprints (it was user deemer here: 25326), and he used practically the same combinator logic.

Actually, his circuit is a tiny bit more elegant than yours, because he is adding the chest count ("X") directly from a combinator by combining the wire. Then you can divide by the same constant in the arithmetic combinator -- so you only need to set the chest count in one place, instead of two.

Interestingly he seemed to have forgotten about this fact, because in his blueprint he's not doing it that way.

Edit: Oh I just see in your screenshot that you use the constant + arithmetic setup as well. It's not in your diagram above.

[FMTK]

Way mor elegant than my solution. Nice

Edit: Oh I just see in your screenshot that you use the constant + arithmetic setup as well. It's not in your diagram above.

Ehm ... is it me that I don't see any const comb there?

[siggboy]

Ehm ... is it me that I don't see any const comb there?

My loading station
https://i.gyazo.com/683ce147ef8a1336ae8 ... 1e20ac.png

Yes, it is you . The setup to the left of the row of buffer chests consists of a constant combinator and an arithmetic combinator.

[siggboy]

Just saw that Madzuri found a way to implement the loading circuit (from belt to chest array) with only one combinator, by using the neat trick of dividing by the negative chest count and then adding the result on the wire directly.

Explanation/screenshot is here so I won't repeat it.

(I haven't thought about if the unloading (chests -> belt) can be simplified in the same fashion.)

[Neotix]

Wow, I didn't think to use negative values. It's great idea

[ssilk]

Also one which should be temporary sticky.

[kann_]

The 2 combinator solution can use the "each" condition and don't need any resource specific programming.
The 1 combinator solution need resource specific programming.

There is a third way that combines the benefits of both.
It is similar to the 2 combinator build with two changes:

• The last smart inserter is turned always on. (or replaced by fast inserter)
  The arithmic combinator with +1 (for loading) or the -1 (for unloading) can be removed.

Basically, the +1/-1 operation is there to destroy the balance if all chests have the same item count. In my version the last inserter has this job.
You don't have to worry that the last chest will have more items, because it is last in the line and resource starved anyway.

I use this build everywhere now.

[siggboy]

The 1 combinator solution need resource specific programming.

No, why? The 1-combinator build works fine with the each/every condition.

Mixed goods don't work correctly with either of the solutions (I think).

There is no 1-combinator solution for balanced unloading (from chest to belt), because you need to subtract 1 before you do the averaging, so the neat trick of combining division and subtraction in the 1-combinator build does not work there.
Edit: there is no count perfect balancer with 1 combinator. See below.

There is a third way that combines the benefits of both.
It is similar to the 2 combinator build with two changes:

• The last smart inserter is turned always on. (or replaced by fast inserter)
  The arithmic combinator with +1 (for loading) or the -1 (for unloading) can be removed.

Basically, the +1/-1 operation is there to destroy the balance if all chests have the same item count. In my version the last inserter has this job.
You don't have to worry that the last chest will have more items, because it is last in the line and resource starved anyway.

I use this build everywhere now.

I think this "hack" is nice for the 1-combinator solution only if you want to use it for unloading. Otherwise I don't see any reason to do this.

[dragontamer5788]

There is no 1-combinator solution for balanced unloading (from chest to belt), because you need to subtract 1 before you do the averaging, so the neat trick of combining division and subtraction in the 1-combinator build does not work there.

I disagree.

The pseudocode for the two conditions are:

1. IF my_box >= average THEN takeout (Unloading case)
2. IF my_box <= average THEN put-in (loading case)

Of course, >= and <= don't exist in Factorio, but we can deal with it later. Now, lets work with the math:

Unloading case:
my_box >= average

my_box - average >= average - average
my_box - average >= 0
my_box - average > -1

This is easily accomplished with a "divided by negative-boxes" (for example, EACH / -6 in the case of a single-side wagon unloader). Then check if >-1 for each inserter.

---------------

Now the Loading case. Load if...

my_box <= average

my_box - average <= average - average
my_box - average <= 0
my_box - average < 1

Each inserter checks if < 1.

QED. Both loading and unloading can easily be accomplished with a single combinator.

[siggboy]

my_box - average > -1
This is easily accomplished with a "divided by negative-boxes" (for example, EACH / -6 in the case of a single-side wagon unloader). Then check if >-1 for each inserter.

Yes, in practice that works fine. It avoids the problem that the unloader would lock up when all chests have the same item count.

Only theoretically, such an unloader is not perfect because averaging in combinators always rounds down (fractions are dropped). So there are situations where the circuit will continue to unload chests even though they're already below the average.

Simple example: two chests, with 1 and 2 items in them, respectively. The average item count is "1.5" (only the chest with 2 items is equal to or above the average, and should be unloaded first), but the combinator will output "1" (both chests will be unloaded).

That can keep the buffers slightly unbalanced; probably not an issue unless count perfect balancing is required for some reason.

[dragontamer5788]

Here's sorta the problem: without 2-to-1 splitters, this balanced output (or loading) buffer is still limited to the belt's throughput as far as output. In fact, this design basically works by slowing down all of the inserters down to the speed of the slowest inserter. (on the Buffer->Belt side).

Maximizing the speed of buffer->belt just requires splitters. No way around that. (Or tons of fully upgraded logistic bots)

On the other hand, if the buffer->belt is getting clogged for any reason (or indeed: gets clogged by design. IE: Backpressure), this balanced buffer unloader is extremely useful at ensuring maximum train-performance. But if back-pressure is slowing down the belt-performance and Buffer->Belt performance, then why would you be concerned about train->buffer performance?

I guess if a train has a mixed-bag of goods and a schedule to pick other things up. (ex: Oil AND Copper train), you'll want the train to unload as much copper as possible before it goes on its Oil run. That sort of complicated design was how I designed my first train system (before fully understanding signals / deadlock / whatever), and might still be a useful strategy in speed runs (where you only need to manage maybe... 3 or 4 expansions tops before the rocket is launched).

-------------

EDIT: On the other hand, we can create unbalanced 2:1 splitters and the whole contraption will work pretty well. IIRC, 6-maxed out stack inserters (or was it 12?) feed 3.7 blue belts. So 4-blue belts would have some extra throughput capacity for the inefficiency. A perfect set of balanced splitters 12-to-4 takes up a lot of space (because of the multiple of 3).

But instead, an unbalanced set of 12-to-4 splitters, followed by a 4:to:4 rebalance splitter might be ideal? Any thoughts?

[siggboy]

I personally think that the unloader is not very useful at train stations. Especially in 0.13, high performance balanced unloaders are so easy to make that you don't really need a combinator-balancer (doesn't require splitters by the way, you can unload from 12 chests onto 3 belts without a single splitter at almost 100% belt compression).

The loader is a different story, it's great because it just makes the belt layout so much simpler (trivial, even, if you only have enough material for one ore two belts).

I think when Neotix posted his setup, his main application was actually a buffer of chests that you inline somewhere in your factory and that will have balanced contents in the chests. That also is the reason why the loaders and unloaders are all in the same wire diagram.

(Not a fan of that sort of thing either, inserting buffers into the production loops is quite some monkey business in my eyes.)

[dragontamer5788]

I think when Neotix posted his setup, his main application was actually a buffer of chests that you inline somewhere in your factory and that will have balanced contents in the chests. That also is the reason why the loaders and unloaders are all in the same wire diagram.

(Not a fan of that sort of thing either, inserting buffers into the production loops is quite some monkey business in my eyes.)

The more efficient I get at building, the less I like buffers. Buffers "hide" bottlenecks.

On the other hand, buffers really do make sense for "Player-shopping" locations. If your "shopping center" buffers up say, 100 solar panels, you might want to buffer up Steel / Copper / Circuits at that location. In 0.12, I used yellow-inserters for this sort of purpose to "limit" the speed that things are taken off of belts and prioritize stuff downstream (although I guess a 1-in-four or 1-in-eight splitter can also "trickle" items to the player shopping area).

At which point, a balanced buffer would be if you wanted to buffer up a lot of material, and then deliver maximum throughput if the input is slow, while output is spiky.

[Zonk]

To solve those Problems just add different Values on the inserter.
Instead of Ore >1 set it for example all except one to Ore>50 and one to Ore >75 or maybe it was < ...

The result is taht its always running as long as chests are near ~50 toward average therefore the belt gets emptied at nearly full speed (no more stopping of inserter because he is only a few ore away from average) and the last different value prevents a stop if its evened out.

[doxsroxs]

This is really interesting. Im currently using balanced loaders and unloaders for all my stations.
However, my mixed ore stations are a mess since my current solution has one combinator per box to sum each box contents prior to dividing by number of boxes.

Anyone got an idea on how this can be improved? Im running bobs mods and raw ore stations frequently load up to 10 ores in a mix. They then get sorted at a central location, saves huge amounts of time when setting up new mining outposts since I can just blanket all ore patches within a few screens distance and belt in everything without caring about overlap, sorting or ore type.

Im also looking into ways of balancing a robot driven station. Should work by setting request figures based on chest average. But feel free to post such a design if you have already done it, would save me some time
I think the real issue is switching between reading contents and setting the request figures based on the contents. Will need some sort of logic to handle that.