Challenge: Generic max-speed train unload

Post all other topics which do not belong to any other category.
Durentis
Fast Inserter
Fast Inserter
Posts: 105
Joined: Mon Jun 27, 2016 3:55 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by Durentis »

Yeah, I’m ignoring the “average players” bit; I don’t think it’s really definable in a fruitful way. Blueprints make everything accessible to everyone so long as the input and output is clear. Beyond that, the intent becomes a matter of scale independent of ability. By scale, I mean the state of the current base in terms of its demand on resources. A beginner who puts in enough hours can need several wagons and a master at the start still only needs a couple. It’s on the upper end of the scale that I choose to focus as I feel the earlier stages have been successfully made trivial. From my perspective, that means focusing on max sustained compression of blue belts scalable from 1-2 to reasonably larger train configurations. (I should switch my build up to a sixth wagon though.. it balances the sides and looks better if wagons are even.)

Also ignoring the requirement for buffer chests to remain balanced through the unload process as I feel this steps over the line between requirement and implementation. It’s too specific and claims knowledge of a domain from a source that should be ignorant of or otherwise removed from it. If the more general requirement that belts should be sustainably compressed is met, it makes no difference how the buffer chests, if there are even any at all, function or even how long a train waits in the station.

If my ignoring these things invalidates the resulting designs for purposes of the OP’s expectations, I’m ok with that and accept that I’m simply unable to fulfill them. Some very interesting designs have nevertheless been shaken loose in the few related threads.

———

@Kalandrul: I have thus far been unsuccessful reaching sustained compression with tweaks to your design aside from a couple almost successes that occurred, I think, by starting requesters with a very high value for a moment and then switching them to a low value (I used circuits). I could automate this with a timer but I don’t think it would be sufficient. Despite periods of sustained compression, even between trains, restarting from an empty system ultimately seemed to fail to reach equilibrium without intervention. Perhaps it just takes a great many trains to reach equilibrium or it needs to be primed with resources on startup to help the bots’ flight planning, but I can’t be certain that it would remain so indefinitely. Bots are very willful, and their flight path/times seem to be a limiting factor which I couldn’t correct even with some fancy dynamic requests to play with their heads - could be a power thing, but regardless they sometimes just really want to fly the length of the array, which is quite far for 12 wagons. Further tests suggest that you have too many requester chests for the bots to keep up with recharging given so few Roboports.

Moving the Roboports inwards on my build had an unexpectedly similar effect by increasing the power requirement of the bots to the point where even a solid row was insufficient to prevent bots from waiting to recharge - unfortunate, as it looks much cleaner. (Thoughts below may fix this. Edit: Reached sustained saturation with 625 bots given 3 Roboports per wagon, just barely(?) keeping up with recharges.)

I wonder if having too many bots in the network can be worse than having “just enough”. That is, fill the station with just enough to meet the demand when it’s at equilibrium but not enough to satisfy peak/potential demand. This essentially rate limits the chest unloading to sensible speeds and reduces the number of bots that need to recharge before entering the Roboports. It also means, I think, that more bots will fill multiple requests in one recharge cycle. Even just 450 bots (90 per wagon) is sufficient in my build for 3-5 trains despite often hitting 0 available but 425 isn’t quite. Limiting bots seems to not keep them from filling requests on the far end of the array, however. A case of less is more?
Last edited by Durentis on Sat Jul 28, 2018 10:16 pm, edited 3 times in total.

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

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

Agreed on waiving the "balanced chests" so long as sustained 4 (or nearly so) saturated belts can be maintained. Updating the OP to reflect it.

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

Re: Challenge: Generic max-speed train unload

Post by Durentis »

I made several more significant adjustments:
  • Squished @timeshifter's 2-lane unloader and positioned it to draw directly from Buffer Chests instead of the Passive Requester pairs
  • Further reduced bot requirement to 375 from 450 using only two Roboports per wagon instead of three
  • Repositioned Roboports in line with squished 2-lane unloader so that they're closer to the Buffer Chests
  • Put an Active and Passive Provider Chest on both sides of each wagon in an attempt to smooth resource distribution for requests from the Buffer Chests while unloading and cycling trains respectively
  • Adjusted the request amounts for the Buffer and Requester Chests to tighten the timings
  • Narrowed the output lines
  • Added a Constant Combinator to block the station for testing. Green = 1 lets trains in when it's turned on. Turn off to drain the buffers.
Todo:
  • The timings might be a bit too tight in this example to account for the bots' willfulness, but it does reach equilibrium. An extra 25 bots could be used to account for their unpredictability early on, or I think some requests can be increased very slightly, but it does seem to stabilize fairly quickly regardless. The Passive Providers will fill eventually, taking some of the strain off of the Buffer Chests which unfortunately can't request from each other.
  • The splitters I used to squish @timeshifter's 2-lane unloader should really have just been basic belts.. sorry
  • Narrow the left side output lanes 4 more spots by dropping the first 4-lane output over top of the 2-lane splice and Roboports.
Unloading Station 3.jpg
Unloading Station 3.jpg (706.09 KiB) Viewed 5225 times

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Durentis:"Also ignoring the requirement for buffer chests to remain balanced through the unload process as I feel this steps over the line between requirement and implementation. "
Me: I agree that it's quite difficult (though my latest bot design does solve it). Guaranteed unload time is an interesting property. Albeit if we assume full output speed it's trivial, but that's my original thread, so..was that waived too :p?

Durentis:"I think, by starting requesters with a very high value for a moment and then switching them to a low value (I used circuits)."
Me: I don't see how "very high request size" could ever work. It ignores too much of the equation. Dynamic requests that can always be fullfilled ensure equal distribution while keeping bots from flying around "too much" trying to fullfill unnessecary large requests. You should really try it. Keep the automatic request size at a value that can be fullfilled with the available material.

Durentis:"I wonder if having too many bots in the network can be worse than having “just enough". That is, fill the station with just enough to meet the demand when it’s at equilibrium but not enough to satisfy peak/potential demand."

Me: In theory, yes. There is an optimal bot count or a given energy usage target. The problem is that if you have only just enough bots for the equillibrium state you can never reach that state, because you have too few bots to "climb the peak" to get there.

My designs seem to be fine with 50 bots per 4 lanes including peaks btw. You probably have too long flight routes due to the zic-zac roboport positioning. My latest design was explicitly an attempt to reduce the distance between requesters and providers.

Also btw there's a weird bit in your design:
blocked.jpg
blocked.jpg (26.43 KiB) Viewed 5209 times
The underground belt blocks the splitters second output, so this should be just a curved belt as far as i can tell.

@OP:
So, are circuits ok now? Lifting that limit opens a lot of possibilities.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

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

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

Eradicator, circuits were always OK. I don't remember having a constraint against them. And they get unlocked pretty early (red/green science if my memory is correct).

The only concern I might have with circuits would be if they slowed down throughput (I never saw a circuit-controlled design with throughput higher than 1 compressed blue belt per train, but I don't know if that was a limitation of the design or the circuits per see).

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by eradicator »

zOldBulldog wrote:Eradicator, circuits were always OK. I don't remember having a constraint against them. And they get unlocked pretty early (red/green science if my memory is correct).

The only concern I might have with circuits would be if they slowed down throughput (I never saw a circuit-controlled design with throughput higher than 1 compressed blue belt per train, but I don't know if that was a limitation of the design or the circuits per see).
Well, there was the "average player" limit. And circuits are mostly black boxes, especially to people who've never even tried to use them (==average players). They most certainly don't make designs slower though. On the contrary timed inserters can make things faster in certain situations. Also you apparently haven't looked at my latest design if 1 belt of throughput is the best you've seen.

Anyway if circuits are ok, then a circuit controlled reverse "balanced loader station" with per-chest measurement should work. I'll try to make one as soon as i have time (which might be a while).
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

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

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

eradicator wrote: Well, there was the "average player" limit. And circuits are mostly black boxes, especially to people who've never even tried to use them (==average players).
What I meant by "for the average player" was that I would have liked to create a compendium of designs/blueprints that they can "use" on the paths to launching that first rocket. As long as they can plop it down once and works well with the varying demands they'd experience as their bus sucks more and more throughput over time, it is good. I didn't expect they would understand the designs from the beginning, just use them. (Even though I would expect them to eventually start studying and analyzing the designs until they understood them... later on when they try to do their own).

I apologize if I confused you with that statement. Sometimes I think I am being completely clear only to discover that others misunderstood what I meant.

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

Re: Challenge: Generic max-speed train unload

Post by Durentis »

@eradicator:
Ok, so then enough bots to reach equilibrium, but that's still not the peak/potential. My thinking was essentially just that flooding the system with bots is probably bad and it did seem to be. I had set up an automated bot inserter that added bots to the system when needed but this ultimately put in more than necessary. The numbers I posted were what I needed to reach equilibrium in a reasonable time.

Seems to me that the required bots per lane depends on multiple factors including the number of wagons, the number of Requester/Buffer Chests per wagon, the distance of the Requester/Buffer chests from their providers, and the total value of their requests. More wagons increases the flight distance of those willful bots I mentioned that insist on not staying local in the array so more bots are required to compensate for their flight path (also slightly higher request values - see below). I can't see the Roboport alignment being too much of a problem if bots are traveling from bottom right to top left of the array at times. A couple designs actually required more Roboports when I tried straight lines right up alongside the rails, likely because it put the Requester Chests further out from the providers.

I noticed those splitters as wrong when I was posting the update, so I put the need to change it in the Todo section. They weren't supposed to put material directly into the underground, just shift a tile inwards. They work, but are wasteful. Anyway, they're gone now but I'm looking for more tweaks before I upload a fix.

Your guaranteed unload station doesn't actually need any circuitry to accomplish the same thing.. just the minimum desired request amount set to all of the Requester Chests. In fact I think it's better to simply set them to a small amount than to allow them to request arbitrary high values as the passive providers fill up (despite you limiting them to a combined 4.7k which limits the maximum dynamic request). Not sure why you chose 4.7k.. it's less than a full chest and the inserters are either all disabled or none are regardless of the contents of the specific chest they're filling. But it really doesn't change anything.

I actually did play with some dynamic requests as I mentioned, even with some math on the signals to keep the values in a hopefully sensible range. In the end, I realized it was necessary to fine tune the requests individually at as low a value as possible for stability and efficiency. They need to be set based on their rate of drain, the average number of bots it takes to just overcome that drain, and an extra bot (+4 units) because bots are willful. It now becomes more of a probability thing, I think, where the supply will exceed the drain on all chests most of the time, provided a bot doesn't get distracted (or be assigned from a distant place). You can decrease the likelihood of the drain exceeding the supply by increasing the number of extra bots but at the expense of needing more bots in the system and wasting resources. This is why you'll see different request amounts on the chests in my latest attempt. Some of the numbers are still pretty arbitrary, I think, especially in the Buffers -- I wish those pulled from each other down to their requested amount -- but it's much better than when I tried to just set everything to the same value (high, low, or something in between).

Edit: I have a solution for 3-6 trains that I'll post later. When I added the sixth wagon, the build broke. The fix was finding waste in the 2-lane requesters. By reducing their request by 12 (one insertion) each, there were enough resources to satisfy the buffers that were being depleted between trains. I don't know yet if this will be sufficient to accommodate @Kalandrul's 6-12 trains (I doubt it) but I'm hopeful this sort of tweaking will ultimately enable that configuration.
Last edited by Durentis on Sun Jul 29, 2018 4:51 pm, edited 1 time in total.

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by disentius »

Well.... An interesting discussion here.
Just realized i made what Eradicator promised above. Great minds think alike :mrgreen:

As I understand zOldBulldog's challenge:
- Equal unloading of trains under all circumstances
- Unconstrained output (full consumption of output) as high as possible
- Focused on 1-2 trains, and preferably expandable
- As small as possible
- KISS designs
Personal addendum:
- Train stuff is unlocked by red+green science, No robots, stack bonus 7, and blue belts yet:)
- stack inserter bonus 2 (Stack size 4) is the max stacksize bonus with red+green science


Some data from factorio cheat sheet: (https://dddgamer.github.io/factorio-cheat-sheet) And Eradicators post:
Unloading speed per train side:
31,00 i/s -> 4 stack inserters, chest/wagon to splitter (only room for 4 inserter/splitter combo's per wagon side)0
36,90 i/s -> 6 stack inserters, chest/wagon to red belt
36,92 i/s -> 4 stack inserters, chest/wagon to chest
55,38 i/s -> 6 stack inserters, chest/wagon to chest
Maximum red belts unload per per wagon side is 55,38/ 26,666... is a tiny bit more than 2 red belts per side, (2,07)

Output to belt is the constraint here. If you deliver enough trains, they will eventually have to wait because unloading speed drops to the max throughput from chest to belt -> 36,90 i/s per wagon side
This is why equal unloading of the buffer chests is vital.

One way to do this is a Reversed Madzuri.
Combinator balanced unload(Madzuri).gif
Combinator balanced unload(Madzuri).gif (1.66 MiB) Viewed 5180 times
This will keep the buffer chests balanced, at the cost of slightly variable output. Measured average of 1,26 belt per side, with a max of 1,36 belts per side.
The more unbalanced the initial load of the chests, the lower the output of course.
BluePrint
More later.
[EDIT]
Note that the output lanes are not necessarily balanced when there is a big difference per chest-set per wagon. i recommend belt balancers somewhere down the line.
[EDIT2}
With "Per side" i mean "per side per wagon" :oops:

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Durentis wrote:Your guaranteed unload station doesn't actually need any circuitry to accomplish the same thing.. just the minimum desired request amount set to all of the Requester Chests. In fact I think it's better to simply set them to a small amount than to allow them to request arbitrary high values as the passive providers fill up (despite you limiting them to a combined 4.7k which limits the maximum dynamic request). Not sure why you chose 4.7k.. it's less than a full chest and the inserters are either all disabled or none are regardless of the contents of the specific chest they're filling. But it really doesn't change anything.
The design is built to throttle the unloading of the whole train to exactly the amount of items that the belts drain out of the system on the other side. I don't see how that can be accomplished without circuits. But let me try to explain a few of the assumptions of the design. (Bear in mind these are assumptions on my side, and thus they may be wrong.)

a) Any arbitrary fixed request will nessecarily request too much, or not enough, causing unnessecary bot travel, and limiting the amount of items that can be buffered in the requester chests.

b) Why 4700? This is to ensure that an active inserter always has enough space to put the items in. As the system is agnostic to where the items are, we must assume that they could all be in the same chest. Thus one chest worth of the item, minus one stack of guaranteed free space.

c) Inserters all dis/enabling at the same time ensures a well distributed availability of items in passive chests and makes the train unload perfectly balanced (except for the last stack that isn't enough for all inserters to get a full grab). It also forces the bots to unload the chests in a balanced way, because they contain so few items that they empty pretty fast.

As such the system is made to buffer items at the target requester chests and not in the passive unload chests.

A system without circuits can not guarantee that all unloading chests have space to put items in (see picture above about bots grabbing from storage) and as such will, if output is stalled, fill some chests more than others. And as long as there is a full chest the corresponding inserter can not unload the train (→ slower unload). In a bad situation this could mean that only one or two inserters are unloading a wagon becaues the bots all grab stuff from those two inserter's chests and ignore the otherwise full chests. "If output is stalled" in this case is a relative term comparing input and output. If your have 12 inserters (332i/s) but only one output belt (40i/s) then you're filling the buffer 8 times faster than you can use it, nessecarily resulting in unbalanced chests.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by disentius »

And from a previous post:
BIG :D

This one unloads 2 blue belts per wagon side, balanced if the output is unconstrained.
To make certain, i put a input lane balancer at the end. Thanks to this guy: https://imgur.com/a/sgAsj#lsEagUO
4  blue belts per wagon.png
4 blue belts per wagon.png (571.29 KiB) Viewed 5176 times
Blueprint

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Oh hey, we're back to chest chaining and unrestricted output.
Can we go back to my thread now :p?.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by disentius »

Shhhhh!
I wont tell them if you wont tell them :)

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

Re: Challenge: Generic max-speed train unload

Post by Durentis »

Made more changes:
  • Added a sixth wagon to even out the output lines and Roboports and be a multiple of the 1-2 train
  • Replaced Active Providers with Passive Providers for maximum items during train swap
  • More timing adjustments
  • Seems to need 550(+?) bots now
Todo:
  • More timing adjustments, perhaps to support rocket fuel trains (almost works)
  • May need to move the 4-lane design outward one tile, change the Buffer Chests to Passive Providers and draw from Requester Chests, but I'd rather not.
  • Explore a seventh lane per wagon for 200 stack size items
The 3-6 train configuration seems to be a lot more trouble than 3-5 even with nuclear trains. Still seeing the odd miss in the lines, but not a lot. More bots, better timing, or may have cut the request values too low in spots and it's causing trouble. Not sure yet.

(Edit: May just resign myself to 600 bots.. seems to work just fine with that and 100 bots/wagon is a nice round number. Averages about 33.8MW which is approximately what it takes to run a single blue belt through a beacon smelter so not bad at all considering it produces 36 such belts.)

Is bigger than 3-6 even really necessary given 36 compressed blue belts of plates per station? Seems like a fairly balanced train configuration to me.
Unloading Station 4.jpg
Unloading Station 4.jpg (1.22 MiB) Viewed 5142 times

eradicator wrote:The design is built to throttle the unloading of the whole train to exactly the amount of items that the belts drain out of the system on the other side.
That makes more sense to me.

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

Re: Challenge: Generic max-speed train unload

Post by Durentis »

I think this is it for the 3-6 station unless anyone has any more suggestions or finds a problem with it. Thanks for the help, have learned a lot with it so far.

Made more request value tweaks and changes to the chests again. Active Providers do seem to help out the overloaded Buffer Chests more than they hinder and I put Passive Providers where they're being drawn from by inserters -- crazyness -- but they nevertheless fill up.

It seems to be holding stable with as little as 450 bots now using nuclear powered trains, so I'm pretty happy with it. That's only 75 bots to compress six blue belts and as far as I can tell it naturally throttles the train unloading speed as needed without starving any belts despite chests filling up. Worst case at this point, I think, just add 25-50 extra bots but I don't think they're needed now and that's still a long ways from the 600 I thought I'd be stuck with.


Zanthra
Fast Inserter
Fast Inserter
Posts: 207
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

disentius wrote:And from a previous post:
BIG :D

This one unloads 2 blue belts per wagon side, balanced if the output is unconstrained.
To make certain, i put a input lane balancer at the end. Thanks to this guy: https://imgur.com/a/sgAsj#lsEagUO
Blueprint
I might use this myself, but I think it might be better to do no lane balancing, as you have a left and a right lane inserter for each unloading chest chain.

Code: Select all

0eNqlXO1u2zgQfBf9tgt+f+RViuLgJEIqnCMbsnzXIMi7n1yjiYOIx9nhL8NNOrOz5O6QFJXX7n5/7o/TMM7d3Ws3PBzGU3f3/bU7DU/jbn/5t/nl2Hd33TD3z92mG3fPl2/9r+PUn07bedqNp+Nhmrf3/X7u3jbdMD72v7o7/fZj0/XjPMxDf0X8/eXlr/H8fN9Pyy+8Y50WkOHp57xdPvYLxfFwWv7XYbyQL0hbrTbdy+XTLPCPw9Q/XH+6fP2CamDUhINaGDTgoA4GdTioh0ENDhpQUME4RRRTEGdCMQUJzSimYOQv8xkDFcxRfVtPfb/fPvzsT/PKwPtv/oqav/kF9n53mYuriLe1tHv4ezuMp36alx/9D6hWC+oamMXBbBXMgVrtmtawhuhBRLeG6NYQAy7YVQVHHMxUwRKo1dxqXQPKeFT6c95uJvPacBhVM5qvDKrIsDY8RosZtIwArx5TBF51OLySqoVkHIxVnaMGLCFbmVUmYDgOrW2DF0+1jRmwdjzaJgxeQ6EWnFVYcAF1AKsJB0iF4D7q4bl/HM7P236/TPNpeNgeD/t+bS31BzEWED8K4d/D4bEf65YXPwTrNURH9OySXk8YXgkroEotqjSiiA5FTPKWrT9j11bhWc5gRAxOETZbGDOnhfNdVaa7Mw2eGBHLcraBIUEMjnddTILnCTAFQUxQnoNrbuWimMDKCJLc80tzPMuXIgUor8CGhPYjr0FA1By8AQEDCmjl65JS9px8FVGC8sK+FSt9ywexTftK4iKxLAmF6BJh+SWsLDbVitKgxMZfQ9TEsqSgNxjCLj3So4JtWEx4pI8H1+B1GINvYAgQQ4MXYRIi76YYQeIJsBRludkVZntUcrPzyKozaqn1VWo8ip2qBkg4VSmLhFOVoLzU4WsyA+ErrhBcFLuerURHbLDsZ+zaRMyENxT0JyX2wor+pAmnLkVnGvzFIo0ntTiYgxhcw3YYmg+pxcGwLIUGBixLkfdITELiCTAFmfdISEFWPAGkIGu5CRcKNxt+d2yRlWeW162TETi5l5aS4aU+X2mxOcjNuRRblJpzLbYkNlRdQcyE3ZvCozAl97tKeFoxWzWNzEGtDOGlRelfS+Z03A9z4UHgB1i1cWjV4nEao5CbnBIytJicRoxaqygYAiMagYYdGpgeYouGZUUr3iyw2LWWN/NSGWkj7Zi1BqKt1B+qiMTurajXE+23dKVBiw8ZVU1qZJ9XFmMkNnDuU7TVCZ+Jtl4Kl7mDYUXhEncw3ru7gurTmAb/ACks7R8ggeMNCmTgH5qBBIE3EZCBf2oGEiR6X6CgJZnJvFlhEqySN+/ibT7C+IpY8iL1otRaqQ/WvOHmnojsGVkxBV5qX6YWInGWqUvRRbmtGGxkGs40sfVry6URjMEpngFbZTpNOwAowdAEoAJLGwBIwF8sAVPk6f4PEgS6/4MEvEWCY5DE/lLqOIKLJb6UhNUlJ3zNJIB91hNXJG1BtSdWq38wHSbf8v0WOurV3vGbHFCD5zVYTEPgOzqYpcgzgBoS3dJBCZkmwBQE/rEESMC/AoClKPAPK0ACSxOAKXK064EKeFsFFchrOZQUrC5hiTsyXkYgt9WSwYQsOam3v7Ggezw6Kv5xd4Dafmw4LAIZGi5YByxL/FkROAz8WRGogD8qAhXwR0WgAv5CAEiQBEXmJKnhT4gC1GlSQxFDl+d10nyJJUzD1yI+j4/99DQdls9KDXwVsXl/+308ni+vt68wSh5/Xt+Qjliy+D0tOBqeLgWQIIgfS4KpifxM1dhpaWp4nyljDJkvBowhN7xGC6Yp64Z6W+F4L7jDeS5VXOaPq6C3j3VuOK4C08bXNiiBr22Nnapn/vY5OHtbihw7E8tJfnVFY6dhuaG6seiNUvyxLcigBfmRpMcow5fYSuw/Nte/T3N38+dsNt0//XS6TuAUjUlLP4zm7e0/rY84Cg==
I use here a simple 4-4 balancer to distribute the outputs evenly among the inputs. I also limited the steel chests by the number of stacks in the wooden chests down each line to keep each buffer the same.
Attachments
unloader.jpg
unloader.jpg (347.62 KiB) Viewed 5113 times

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

Re: Challenge: Generic max-speed train unload

Post by mrvn »

eradicator wrote:I don't think the bot design above is particularly complex. It uses only straight-forward mechanics, albeit at heigh density. Side-loading of things onto belts, requester chests, nothing fancy. I did(?) say that the circuit is probably out of scope there, even though it is very simple as far as circuits go. Also shrinking it down to one belt per wagon is easy, i'll leave the exercise to the reader ;).

Also a high-throughput station does not require lots of trains. It works just fine with just a few trains. And i don't even agree with the OP about the "for average players". Any design you don't build yourself is always somewhat of a black-box. And a basic station as you describe sounds like it can easily be designed by the average player by themselfs. And i don't even believe that "average players" come to the forum to get a solution they understand. They come here to find a solution that is optimal for their problem and works. Understandability might be a good bonus...

Also OP explicitly demanded that the whole train is unloaded in a balanced way. Which is a ridiculously high hurdle as far as any-length unloading goes. And definetly not doable in any way that the "average player" understands.

Also i thought OP said he wanted only one unloading bay... can't find a quote on that atm.

About your "trivial" design...let's see. It uses half-underground belts to split things, which is definetly black magic for "mr average". And with four inserters you're not filling a whole belt unless you use stack-size-override magic. Not even speaking of the 8-lane balancer. Because even experienced players couldn't tell if it works or not at a glance.

That said, i'm not "with" anyone. I just post nice designs and wait if OP thinks they meet his contradictory conditions. OP seems to be absent though. To me OP is the black-box so to speak ;).
The problem with the bot designs are threefold:

1) Bots come late and are expensive to build at first.
2) Bots use a lot of energy, a LOT.
3) If you ever accidentally place another roboport near enough to connect to the unloading stations logistic network then it will completely break down.

So you need quite a bit of extra infrastructure to even build the thing and then the footprint of the station has to include the roboport range because that's basically the exclusion zone where you can't build normally.

Note: How bad is it when the loading and unloading stations are both bot based and connect? Will bots constantly go from one to the other or will the balance out?


By "lots of trains" we mean "lots of trains per minute". If your ore fields are near enough you don't need many. But they never are near, or not for long. As you expand getting enough trains per minute to reach the station becomes harder and harder because network congestion rises.


A rather trivial balanced design is to compute the negative average contents of all chests (arithmetic combiantor connected to all chests: each / -<num chests>). Then connect each inserter to it's chest and the arithmetic combinator with "enable anything > -10. Why -10? Because it reduces stutter. Add to that that you have more inserters per wagon that needed to fill the belt and you get fully compressed belts and balanced chests.

Don't take the unloading speed to the extremes and compressing belts and balancing becomes trivial. That's my point. Use 2 stations instead of one and you more than half the problems.

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by disentius »

@Zanthra:
Tested your blueprint, and you are absolutely right about the balancing part. Thanks!
4  blue belts per wagon-TESTRESULT.png
4 blue belts per wagon-TESTRESULT.png (3.35 MiB) Viewed 5084 times
Not sure about chest limiting myself. i like to empty the trains asap (and have a bigger buffer)
This design was posted originally in Eradicators thread about his "4 blue belts per wagon" deathwish. viewtopic.php?f=194&t=58728
You ll find other ideas there too.

@mrvn:
I posted something like that above (reversed madzuri). See no need for the -10

Zanthra
Fast Inserter
Fast Inserter
Posts: 207
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

disentius wrote:@Zanthra:
Tested your blueprint, and you are absolutely right about the balancing part. Thanks!

Not sure about chest limiting myself. i like to empty the trains asap (and have a bigger buffer)
This design was posted originally in Eradicators thread about his "4 blue belts per wagon" deathwish. viewtopic.php?f=194&t=58728
You ll find other ideas there too.

@mrvn:
I posted something like that above (reversed madzuri). See no need for the -10
I would post in the other thread, but there are better builds for raw unload already, this design is interesting because of the balanced unloading properties.

Here is the full 4 belt per wagon unloader for LCC with the 8 belt demand properly balanced among the unloading chests.
4 Belt Unloader.jpg
4 Belt Unloader.jpg (244.6 KiB) Viewed 5068 times
Very easy to explain the balancer behavior too. Just a basic tree. Red is unbalanced demand, Yellow is 1/2, Green is 1/4, Blue is 1/8, and Purple is 1/16. Forgive my terrible drawing skills.
4 Belt Unloader - Splitter Tree.jpg
4 Belt Unloader - Splitter Tree.jpg (250.29 KiB) Viewed 5068 times


It can also be expanded like this for more cargo wagons, although it requires locomotives between pairs for the crossover or a lot more space for the belts on the back side.
LCCLCC Unloader

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Challenge: Generic max-speed train unload

Post by disentius »

You can start smaller:
4  blue belts per wagon-smaller and extensible.png
4 blue belts per wagon-smaller and extensible.png (429.72 KiB) Viewed 5058 times
Here the 2 wagon version. Use the middle part for all wagons between first and last.
(also from the 4-belt post) :mrgreen:

Post Reply

Return to “General discussion”