Smart setups of railway stations, intelligent routing, solutions to complex train-routing problems.
Please provide - only if it makes sense of course - a blueprint of your creation.
disentius
Filter Inserter
Posts: 452
Joined: Fri May 12, 2017 3:17 pm
Contact:

viewtopic.php?f=194&t=58728&start=40#p360163

viewtopic.php?f=194&t=58728&start=40#p360198

viewtopic.php?f=194&t=58728&start=40#p360395

All output balanced with unrestricted flow.
You do need balancers if you expect backlogs/bottlenecks down the road.

golfmiketango
Filter Inserter
Posts: 543
Joined: Fri Jan 29, 2016 2:48 am
Contact:

zOldBulldog wrote: - 1-belt balancers (balance left/right lanes of a belt) help to draw equally from both sides of a belt. There are well known standard designs that do it. I typically place these for every belt, between the bus and the factory bays (as a matter of fact I reserve a full chunk between the bus and the factory bay for this kinds of things).
Agreed. Since splitters "best-effort-balance" belts, not lanes, but never actually lane-swap (without shenanigans), even in an ideal world where splitters and belts had completely lane-symmetric business logic, I imagine this would still lead to all sorts of muddled-up partial input-side balancing, perhaps not unlike we see in practice.

Speaking super generally: Let's say you have a n->m contraption made of belts and splitters with no lane preferences, and it's not input balancing your n inputs like you were hoping... and, let's assume they are all holding the same item, i.e., only iron ore...

I'd say, almost universally, you can mostly solve your input balance problem by
• lane-balancing each of the n input lanes
• lane-splitting (so that you now have 2*n belts, each with only one or the other lane containing stuff)
• sorting by lane (so we have n left lanes grouped together, and n right lanes grouped together)
• slapping two of your n->m contraptions down, one for each lane
• resorting so that each output from the contraption meets back up with it's other-lane equivalent
• side-load zippering the resulting lanes up into m two-lane belts
the resulting composite n->m contraption will almost always much more nearly "do what you expected" on the input side.

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

I think I'm not explaining well the problem of uneven demand. Trying now:

- Let's look at the latest screenshot in this thread (tzwaan's), it is typical of most unloaders discussed here.
- Imagine that each belt goes to a different factory.
- Now imagine that factories 1-7 are off, pulling nothing. But factory = belt 8 is using up a fully compressed blue belt.
- What will happen is that some chests empty, others (especially those for the other wagon) remain full. The train stalls.

A normal case is less extreme, but over time we often see some chests empty faster than others and trains staying at the station longer and longer.

Traditional balancers help but they are designed to distribute less than full capacity evenly. In this case we have tons of ore, but are unable to pull from the chests evenly, totally breaking the high throughput unloaders.

What we need is a balancer that operates exactly backwards to the current design. Instead of distributing the available ore equally, it needs to draw evenly from the input belts regardless of how unbalanced the demand is.

The problem is that the only designs I've found that do this are circuit based, and processing the logic ends up slowing down the unload to maybe 1 belt per wagon.

Is it even theoretically possible to do better?

disentius
Filter Inserter
Posts: 452
Joined: Fri May 12, 2017 3:17 pm
Contact:

mrvn
Smart Inserter
Posts: 4268
Joined: Mon Sep 05, 2016 9:10 am
Contact:

What 1-belt balancer did you use? Because the standard designs balance the output, not the input.

As for lane balancing with multiple cars: Don't.

You can balance 4 lanes just fine. Balancing 8 lanes is big but ok-ish. But balancing 16, 32 or even 64 lanes gets just insane. And anything inbetween is ugly too.

Instead design your factory that each unloaded car has it's separate sub factory and loads into a different car on the output side. The draw and output per car will then be absolutely equal and no balancing between cars is needed. That just leaves balancing the belts of each car separately, which is a much smaller undertaking.

Smart Inserter
Posts: 4227
Joined: Tue Jul 12, 2016 9:03 am
Contact:

zOldBulldog wrote:Is it even theoretically possible to do better?
A high-speed unloader can never do balancing without sacrificing speed, because it already requires all 6 available tiles on each wagon side to even get up to high speed. If any of the lanes doesn't accept input at full speed then you can't compensate for that using the other lanes, because the other lanes are already at full speed. Thus your only option is to slow the other lanes down.

And now i would much appreciate if you did your discussion about factory wide balancing in a thread dedicated to that topic. That would make it a lot easier to find for anybody else interested.
Author of: Hand Crank Generator Deluxe, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

mrvn wrote:What 1-belt balancer did you use? Because the standard designs balance the output, not the input.

As for lane balancing with multiple cars: Don't.

You can balance 4 lanes just fine. Balancing 8 lanes is big but ok-ish. But balancing 16, 32 or even 64 lanes gets just insane. And anything inbetween is ugly too.

Instead design your factory that each unloaded car has it's separate sub factory and loads into a different car on the output side. The draw and output per car will then be absolutely equal and no balancing between cars is needed. That just leaves balancing the belts of each car separately, which is a much smaller undertaking.
Good point on the lane balancer, I didn't even think about that. I will need a lane balancer that ensures even draw on input, not just output. I have not seen any, I'll have to think on how to design one.

I am puzzled about the suggestion of one factory per car. If one factory consumed less than the other, wouldn't I end up with the same problem? One car full-ish and the other empty, holding up the train and starving one factory? But I use 1-2 trains for deliveries to the base, so the 8-8-lane ok-ish balancer is what I use.

I was playing around in my head with the idea that perhaps I should directly output 12 unsaturated belts (6 per wagon) and immediately feed them into a 12 to 8 balancer. A bit too big, yet I could live with that, but what bugs me is the doubt about whether it would be effective at keeping the unload chests balanced. My instincts say no, but I can't figure out why. No matter, I will keep at it, I am determined to find a solution to the "high throughput unload in spite of uneven demand" problem.

mrvn
Smart Inserter
Posts: 4268
Joined: Mon Sep 05, 2016 9:10 am
Contact:

zOldBulldog wrote:
mrvn wrote:What 1-belt balancer did you use? Because the standard designs balance the output, not the input.

As for lane balancing with multiple cars: Don't.

You can balance 4 lanes just fine. Balancing 8 lanes is big but ok-ish. But balancing 16, 32 or even 64 lanes gets just insane. And anything inbetween is ugly too.

Instead design your factory that each unloaded car has it's separate sub factory and loads into a different car on the output side. The draw and output per car will then be absolutely equal and no balancing between cars is needed. That just leaves balancing the belts of each car separately, which is a much smaller undertaking.
Good point on the lane balancer, I didn't even think about that. I will need a lane balancer that ensures even draw on input, not just output. I have not seen any, I'll have to think on how to design one.

I am puzzled about the suggestion of one factory per car. If one factory consumed less than the other, wouldn't I end up with the same problem? One car full-ish and the other empty, holding up the train and starving one factory? But I use 1-2 trains for deliveries to the base, so the 8-8-lane ok-ish balancer is what I use.

I was playing around in my head with the idea that perhaps I should directly output 12 unsaturated belts (6 per wagon) and immediately feed them into a 12 to 8 balancer. A bit too big, yet I could live with that, but what bugs me is the doubt about whether it would be effective at keeping the unload chests balanced. My instincts say no, but I can't figure out why. No matter, I will keep at it, I am determined to find a solution to the "high throughput unload in spite of uneven demand" problem.
But all the factories would be identical. E.g. 24 furnaces per car. They would consume identical amounts of inputs to produce identical amounts of outputs. Unless you have recipes with randomness but even that evens out over time.

Why not simply output 6 lanes per wagon and feed that into 6 rows of furnaces. Then feed the 6 resulting output belts back into a wagon. Same number of furnaces per lane means same consumption on every lane. All buffer chests will empty and fill equally. And so what if the 6 belts aren't saturated? Use less furnaces so consumption equals the inserter speed. The only reason to use compressed belts would be to save on belts and that is only worth at long distances.

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

mrvn wrote: But all the factories would be identical. E.g. 24 furnaces per car. They would consume identical amounts of inputs to produce identical amounts of outputs. Unless you have recipes with randomness but even that evens out over time.

Why not simply output 6 lanes per wagon and feed that into 6 rows of furnaces. Then feed the 6 resulting output belts back into a wagon. Same number of furnaces per lane means same consumption on every lane. All buffer chests will empty and fill equally. And so what if the 6 belts aren't saturated? Use less furnaces so consumption equals the inserter speed. The only reason to use compressed belts would be to save on belts and that is only worth at long distances.
Aha! I see where we are miscommunicating.

You are thinking of high speed unload under the umbrella of megafactories, where each factory is a standalone outpost that receives resources by train, produces exactly one product and ships it out also by train.

I am using high speed unload as a mechanism to feed the bus or (more commonly) the smelter arrays that directly feed the bus. My unbalanced demand and thus unload comes from various factories downstream pulling different resources from the bus at different rates depending on what I am doing and what products I am putting demand on at a given time. Even if each factory did perfectly balanced pulls from the bus of whatever it needed, the demand ripple as I made one product or another (maybe belts at one time, or beacons at another) would go all the way back up to unloader. So, "somewhere in the chain" there must be a demand-based balancing mechanism, so that the unload chests remain balanced.

mrvn
Smart Inserter
Posts: 4268
Joined: Mon Sep 05, 2016 9:10 am
Contact:

zOldBulldog wrote:
mrvn wrote: But all the factories would be identical. E.g. 24 furnaces per car. They would consume identical amounts of inputs to produce identical amounts of outputs. Unless you have recipes with randomness but even that evens out over time.

Why not simply output 6 lanes per wagon and feed that into 6 rows of furnaces. Then feed the 6 resulting output belts back into a wagon. Same number of furnaces per lane means same consumption on every lane. All buffer chests will empty and fill equally. And so what if the 6 belts aren't saturated? Use less furnaces so consumption equals the inserter speed. The only reason to use compressed belts would be to save on belts and that is only worth at long distances.
Aha! I see where we are miscommunicating.

You are thinking of high speed unload under the umbrella of megafactories, where each factory is a standalone outpost that receives resources by train, produces exactly one product and ships it out also by train.

I am using high speed unload as a mechanism to feed the bus or (more commonly) the smelter arrays that directly feed the bus. My unbalanced demand and thus unload comes from various factories downstream pulling different resources from the bus at different rates depending on what I am doing and what products I am putting demand on at a given time. Even if each factory did perfectly balanced pulls from the bus of whatever it needed, the demand ripple as I made one product or another (maybe belts at one time, or beacons at another) would go all the way back up to unloader. So, "somewhere in the chain" there must be a demand-based balancing mechanism, so that the unload chests remain balanced.
Yes, if you just fill a bus with 6 wagons (that's 24 blue belts, some bus there) and then draw from it for everything from gears to roboports then you have to "balance" it in some way. What I do on a bus is have each station draw from one belt of the bus. When all belts have been tapped I balance the belts and repeat. At each balancer you can probably drop a belt or two. Having each split from the main bus consume equally from both sides of the belts helps a lotor you have to balance each belts sides too.

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

With thanks to many, but in particular to mrvn for great ideas and constructive criticism, I contribute an unloader mechanism to this thread:

- Designed for 1-2 trains.
- It is based on a well known input-balanced 6 to 4 balancer/compressor.
- Each 4 belt section should draw equally from the chests on both wagons, even if demand is uneven across the belts. Thus it should be resilient against train slowdowns.
- The balancer section DOES NOT attempt to balance the output. You may use a separate balancer downstream if you need that feature. On the other hand, it should be quite suitable if you plan to use the belt-shift approach to maintain fewer but full belts on one side of the bus and if you are feeding a generic bus that pulls unevenly on the various belts.
- I am not certain if this balancer design also input balances the left right lane of each belt. I recommend using a separate left/right balancer for that purpose.

Finally, I only did light testing and it might be some time before I can fully stress-test it. But since it is based on a well known design it should work. If anyone happens to test before I do, please let me know how it performed.
unloader.jpg (993.08 KiB) Viewed 3886 times

Code: Select all

tzwaan
Inserter
Posts: 37
Joined: Thu Jul 07, 2016 12:12 am
Contact:

zOldBulldog wrote:With thanks to many, but in particular to mrvn for great ideas and constructive criticism, I contribute an unloader mechanism to this thread:
Your unloader does not actually fulfull the requirement of the thread: 4 fully compressed blue belts per wagon.
You're putting the output of 12 inserters through a balancer and making it into 4 belts, but the way you're doing it can never compress those belts as those 12 inserters don't have enough throughput on their own.

It seems like you've missed the point of this thread, which wasn't the balanced output of the chests, but actually getting 4 full belts out of a wagon. Balancing the draw from the different belts can always be added on top of any of the unloaders in this thread by just slapping a balancer on the end, just like you did.
zOldBulldog wrote: The balancer section DOES NOT attempt to balance the output.
But it does.
It balances both the input and output belts and lanes. This design used to not balance the output lanes in the past, but that changed with the 0.16 belt changes where the different belt lanes are now split by splitters completely separately from eachother.
https://wiki.factorio.com/Balancers#Lane_Balancers

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

tzwaan wrote:
zOldBulldog wrote:With thanks to many, but in particular to mrvn for great ideas and constructive criticism, I contribute an unloader mechanism to this thread:
Your unloader does not actually fulfull the requirement of the thread: 4 fully compressed blue belts per wagon.
You're putting the output of 12 inserters through a balancer and making it into 4 belts, but the way you're doing it can never compress those belts as those 12 inserters don't have enough throughput on their own.

It seems like you've missed the point of this thread, which wasn't the balanced output of the chests, but actually getting 4 full belts out of a wagon. Balancing the draw from the different belts can always be added on top of any of the unloaders in this thread by just slapping a balancer on the end, just like you did.
zOldBulldog wrote: The balancer section DOES NOT attempt to balance the output.
But it does.
It balances both the input and output belts and lanes. This design used to not balance the output lanes in the past, but that changed with the 0.16 belt changes where the different belt lanes are now split by splitters completely separately from eachother.
https://wiki.factorio.com/Balancers#Lane_Balancers
Thanks for catching that, my skill at this type of design isn't the best.

What troubles me is that none of the other designs seems to achieve the goal of the thread either - at least not for long before they fall apart - except for the rare case where your consumption of the 4 belts is perfectly even. Any imbalance on consumption results in on the chests by the train getting unevenly full which in turn results in trains staying longer and longer at the station until some of the chests reach the empty state... at which point throughput degrades.

I understand that Eradicator's personal need is only for that very special case, but he is not the only user of this thread, so unless he changes the title and original post to limit the thread to that specific condition (and we create a new thread for the generic case where output demand might be uneven) then the problem isn'tn fully solved unless we address both scenarios:. 4 -saturated belts (1) perfectly even output demand AND (2) with uneven demand.

Splitting the threads is probablythe best idea.

Smart Inserter
Posts: 4227
Joined: Tue Jul 12, 2016 9:03 am
Contact:

zOldBulldog wrote: What troubles me is that none of the other designs seems to achieve the goal of the thread either - at least not for long before they fall apart - except for the rare case where your consumption of the 4 belts is perfectly even.
Author of: Hand Crank Generator Deluxe, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

zOldBulldog
Smart Inserter
Posts: 1108
Joined: Sat Mar 17, 2018 1:20 pm
Contact:

zOldBulldog wrote: What troubles me is that none of the other designs seems to achieve the goal of the thread either - at least not for long before they fall apart - except for the rare case where your consumption of the 4 belts is perfectly even.
If you only want discussion on a specific scenario in your thread you need to make it clear in the title and original post. Anything else (even clarifying a few pages into the thread) is inadequate and misleading.

In this particular topic - and under the title and terms of the experiment as described in the original post - it is simple logic that if some factor causes a failure to unload 4 chests (like the unload chests getting unbalanced and causing delays in train unloads) then the problem isn't solved... Even if you can get solid 4-blue belt throughput for 30 seconds or 5 minutes. No worries, I will make a new thread for the generic case.

As to prompting your personal attacks, it was my mistake to assume you were a mature adult and that you could engage in intelligent discussion without throwing a temper tantrum. For that I apologize to the other readers. I shall avoid your threads in the future. Unsubscribing and moving on to the new thread.

Smart Inserter
Posts: 4227
Joined: Tue Jul 12, 2016 9:03 am
Contact:

zOldBulldog wrote:As to prompting your personal attacks, it was my mistake to assume you were a mature adult and that you could engage in intelligent discussion without throwing a temper tantrum.
People who falsely accuse me of "personal attacks" in the same sentence they personally attack me never fail to amaze me.
Author of: Hand Crank Generator Deluxe, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Durentis
Fast Inserter
Posts: 102
Joined: Mon Jun 27, 2016 3:55 pm
Contact:

Building on @timeshifter's "dumb dump" and @Teraka's splitter trick, I managed to make a tiny 2-lane output with only seven stack inserters and no circuitry or bots.

The central stack inserter has to insert onto the belt or else the output will skip once in a while, though almost unnoticeably. (So disappointing. And restricting its stack size made a difference, especially 6, but ultimately didn't work. I had to make a long snake of belts to see them. You can always remove the extra belt extension to tighten it up a tile but drop a 4-4 lane balancer on top of the two vertical splitters and run two belts out of it if you really want to, but I don't think it's necessary as I don't think it skips so long as the 1-belt extension is in place. If you don't care that it skips occasionally, you can just take out the 1-belt extension and let the central stack inserter unload right into the splitters (with stack size 6).

The underground belts are required. Without them, the inserters try to put their items on the splitter side of the belt.

This doesn't draw evenly from the buffer chests.
TwoLaneUnloader.jpg (107.38 KiB) Viewed 3627 times

mrvn
Smart Inserter
Posts: 4268
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Does this work in all directions even mirrored?

Durentis
Fast Inserter
Posts: 102
Joined: Mon Jun 27, 2016 3:55 pm
Contact:

All directions, yes.
Mirrored, no. (Because the inserters insert on the splitter side of the belt.)

Saunis
Burner Inserter
Posts: 15
Joined: Tue Jan 09, 2018 2:55 pm
Contact:

I did a little comparing, how these work.

There are all kind of plus and minus things...

disentius build were really most effective and even unload.
But it needs more space and most of material. (because there it possible to unload into 6 box, I did used 3 line output and then ran it through 3-2 balancer, so it had 2 out puts)
And to be honest. I didn't like how it look. But I can't denied than this build is the most powerful.

From other tests, those who did full compression in to 2 belt really did uneven load from boxes. And it took longer time them to empty all 6 boxes than it took from those what didn't make fully compressed belts but had even steady pace to emptying boxes.

Here's small video of it:
(2. top is mine own tryout... Im just testing what kind of thing I might use on my normal map)
https://youtu.be/szMISAUkdlU

What would happen if I drove many wagon unload cycles through those things?
Would unbalanced wagon unload start to slowdown whole cycle because 1-3 chests were full too soon?

### Who is online

Users browsing this forum: No registered users