Challenge: Generic max-speed train unload

Post all other topics which do not belong to any other category.
Post Reply
Copy link
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:
Contact Zanthra

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

disentius wrote:You can start smaller:
The attachment 4 blue belts per wagon-smaller and extensible.png is no longer available
Here the 2 wagon version. Use the middle part for all wagons between first and last.
(also from the 4-belt post) :mrgreen:
The problem with that one is going to be the shared belt (or more accurately the shared belt lanes) in between the two wagons. You end up with priority on top belt lane to the bottom wagon, and bottom belt lane to the top wagaon. Without complex lane balancing it won't unload balanced on uneven lane demand.

Here is a variant using underground hoods to separate the lanes of the middle belt back out. The red belts indicate the output of the top wagon and bottom wagon after balance correction. This is at a cost of complexity of course, but less inserters is less power and drain.
4 belt corrected.jpg
4 belt corrected.jpg (210.14 KiB) Viewed 8324 times
4 Wagon Tiled
Last edited by Zanthra on Mon Jul 30, 2018 10:35 pm, edited 4 times in total.
Top
Durentis
Fast Inserter
Fast Inserter
Posts: 105
Joined: Mon Jun 27, 2016 3:55 pm
Contact:
Contact Durentis

Re: Challenge: Generic max-speed train unload

Post by Durentis »

Wasn't a big fan of the chest to chest thing, but it's growing on me. I fiddled with it a bit to achieve the same output as the 6-lane bots. It only saves a few MW of power over the bots (stack inserters are power hungry too) and has a bit larger footprint but it's very solid and doesn't have the timing issue or technology/cost requirement of the bots. There's no room to expand this to a seventh or eighth output lane as you can with bots, but I'm not certain that works reliably for the larger stack sizes yet anyway.

I used a 1-2-1-2-1-2 train configuration (same speed and capacity as 3-6 I think) for a direct comparison.
Image and Blueprint
Top
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:
Contact Zanthra

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

I was thinking about it and this design does not need to restore the wagons to their own belts. But it does need to make sure that the belts are mixed by splitter and not side loading. Each chest has 1 top lane inserter, and 1 bottom lane inserter, and they are all mixed by splitter to the output.

This is the result for one side two wagons. It is tileable with an appropriate balancer for any power of 2 wagons. 1, 2, 4, 8, 16, 32 etc... The balancers become very complex to guarantee balanced draw outside of powers of 2. (One side 4 wagons shown in spoiler below) It maintains the unloading balance on all the buffer chests, and manages sustained 4 blue belts per wagon (if built on both sides of the wagons).

Note that while a power of two must be used for number of wagons, output belts from the final balancer may be left unused without affecting the balance. Using just 3 of the 4 output belts or any fractional portion of them in this example will still unload evenly from the buffer chests.
2wagon.jpg
2wagon.jpg (277.58 KiB) Viewed 8298 times


This is a 2 sided implementation.


4 Wagon
Top
mrvn
Smart Inserter
Smart Inserter
Posts: 5925
Joined: Mon Sep 05, 2016 9:10 am
Contact:
Contact mrvn

Re: Challenge: Generic max-speed train unload

Post by mrvn »

Slows down unloading the trains though since you don't use all the 12 places to have buffer chests.
Top
Aeternus
Filter Inserter
Filter Inserter
Posts: 835
Joined: Wed Mar 29, 2017 2:10 am
Contact:
Contact Aeternus

Re: Challenge: Generic max-speed train unload

Post by Aeternus »

I've ran into the issue described for my megabase that I wanted to get to 10k sci/min. Smelter feeding speed can become an issue. I was using 4-12 ore trains (4 engines, 12 cars monodirectional) - large trains, mainly to make sure that the trains can flatten any biter patrol without stalling out. Could have made them wider but you run into issues at the stacker.

I was using the same basic design as described earlier in the thread. Both sides of each wagon, 6 stack inserters dumping cargo into passive provider chests, bots delivering that off to the smelters. While this unloads 24k ore in record time, the problem is that the stacker/station transfer becomes the bottleneck. It isn't possible to get more then 1 train per ~4 seconds through there, and the stacker was connected directly to the 3 unloading stations, allowing for as rapid a transfer as possible. Longer trains still allow for a faster overall transfer rate (IE one 4/12 train is better then 6 1/2 trains) but at that point the bottleneck ceases to be the train->chest and becomes the stacker->station.
Only ways to break that bottleneck is adding more engines (faster accelleration) or just duplicating the entire station plus stacker. Or just go with even larger trains.

I went with the latter and broke up the centralized smelter into 8 smaller ones.
Top
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:
Contact Zanthra

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

mrvn wrote:Slows down unloading the trains though since you don't use all the 12 places to have buffer chests.
Yes, but non powers of two are balancer hell, so if you want to unload to 6 chests per side and maintain balance it would be far easier to use a bot build.
Top
Durentis
Fast Inserter
Fast Inserter
Posts: 105
Joined: Mon Jun 27, 2016 3:55 pm
Contact:
Contact Durentis

Re: Challenge: Generic max-speed train unload

Post by Durentis »

mrvn wrote:Slows down unloading the trains though since you don't use all the 12 places to have buffer chests.
The maximum output for two lanes is 80 items per second. Assuming max inserter tech, unloading to four buffer chests is just over 110 items per second. Six buffer chests will fill up and slow the unload speed to 80 items per second just the same as four buffer chests, it just takes them a few more trains.

At 4.5s to cycle trains, four chests still gives you a net gain of resources into the buffer chests.

So you need at least 2 buffer chests per compressed blue belt of output so that chests aren't the bottleneck provided you can get trains in within 4.5s or so. Less than that and the buffer chests will be the bottleneck to train unload speed and you won't be able to compress the output belts no matter how efficient the design is.

(Edited to account for train cycling times.)
Last edited by Durentis on Tue Jul 31, 2018 6:29 pm, edited 1 time in total.
Top
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:
Contact Zanthra

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

Although unloading to fewer chests does reduce the time you have to bring the next train in after the previous one is empty. If it takes 50% longer to unload the train, then that's 50% more items that have already left on the belts before you start changing trains. If you don't switch fast enough, then the buffers may be empty before the next train is in.
Last edited by Zanthra on Tue Jul 31, 2018 6:26 pm, edited 1 time in total.
Top
Durentis
Fast Inserter
Fast Inserter
Posts: 105
Joined: Mon Jun 27, 2016 3:55 pm
Contact:
Contact Durentis

Re: Challenge: Generic max-speed train unload

Post by Durentis »

Zanthra wrote:Although unloading to fewer chests does reduce the time you have to bring the next train in after the previous one is empty. If it takes 50% longer to unload the train, then that's 50% more items that have already left on the belts before you start changing trains. If you don't switch fast enough, then the buffers may be empty before the next train is in.
Yeah, that's true. I didn't account for the train cycling in my numbers so three would be too tight. And also presumed an unload time of 12 seconds when I ran the numbers the first time. Should know better than this by now.

That said, an 18 second unload (100 stack size into four buffer chests on each side of the wagon) is still a positive gain if I have the math right this time: 18*27.7*4 - (18+4.5)*80 = 193.68 extra items per second for a 4.5s cycle time, though it still stays positive to 6.5s between trains. This is the fastest the station can unload plates. If the chests fill and it slows the unload, that's not a problem because it means they have the buffer to handle the cycle time. Unfortunately, ore would unload in 9 seconds and have a net negative items in the buffer chests so the chests could never slow the unload time and this won't work for ores.

That sound about right now?

Edit: I just tested my small 2-lane build in a 3-6 nuclear train setup using ore to see how it would handle the timings. The buffer chest in line with the central inserter actually empties during the train cycling, despite the others filling up over time. The design nevertheless just barely keeps up in this state. But when the other chests are full, that buffer chest that kept emptying starts to fill up. Even though the unloading time is increasing as the chests all eventually fill up, the unloading time will stabilize at the expected speed as throttled by the output lines, which always remain compressed. It just requires a positive flow of items into the buffer chests as a whole, not each of them individually.

It seems that it's the short unload times that are the biggest problem because shorter unload times make the cycle time more significant. As the unload times get longer, the effects of the cycle time become less significant and easier to handle.
Last edited by Durentis on Tue Jul 31, 2018 7:43 pm, edited 1 time in total.
Top
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:
Contact Zanthra

Re: Challenge: Generic max-speed train unload

Post by Zanthra »

If it's 6.5 second cycle time limit for 100 stack items, then it's 3.25s train cycle time for 50 stack items. So you would lose 1.25 seconds of unloading per cycle, or about 10 percent of the capacity.

LCC trains (less distance to travel to enter the station) with max tech and nuclear fuel cells with next waiting directly behind (forward from the stacker) and signal between the two wagons can cycle out and back in in just under 3 seconds, which is just barely enough for 4 chest buffer on ore.
Durentis wrote: Edit: I just tested my small 2-lane build in a 3-6 nuclear train setup using ore to see how it would handle the timings. The buffer chest in line with the central inserter actually empties during the train cycling, despite the others filling up over time. The design nevertheless just barely keeps up in this state. But when the other chests are full, that buffer chest that kept emptying starts to fill up. Even though the unloading time is increasing as the chests all eventually fill up, the unloading time will stabilize at the expected speed as throttled by the output lines, which always remain compressed. It just requires a positive flow of items into the buffer chests as a whole, not each of them individually.

It seems that it's the short unload times that are the biggest problem because shorter unload times make the cycle time more significant. As the unload times get longer, the effects of the cycle time become less significant and easier to handle.
If that's the case, then as long as you balance the two belts from each side, the sides of the wagons, and the wagons themselves then it will sustain the full output on unbalanced demand. The downside is that as the chests start to empty if trains don't arrive often enough, the output belts get spottier and spottier, rather than maintaining throughput until it suddenly stops with a fully balanced unloader.
Top
mrvn
Smart Inserter
Smart Inserter
Posts: 5925
Joined: Mon Sep 05, 2016 9:10 am
Contact:
Contact mrvn

Re: Challenge: Generic max-speed train unload

Post by mrvn »

Aeternus wrote:I've ran into the issue described for my megabase that I wanted to get to 10k sci/min. Smelter feeding speed can become an issue. I was using 4-12 ore trains (4 engines, 12 cars monodirectional) - large trains, mainly to make sure that the trains can flatten any biter patrol without stalling out. Could have made them wider but you run into issues at the stacker.

I was using the same basic design as described earlier in the thread. Both sides of each wagon, 6 stack inserters dumping cargo into passive provider chests, bots delivering that off to the smelters. While this unloads 24k ore in record time, the problem is that the stacker/station transfer becomes the bottleneck. It isn't possible to get more then 1 train per ~4 seconds through there, and the stacker was connected directly to the 3 unloading stations, allowing for as rapid a transfer as possible. Longer trains still allow for a faster overall transfer rate (IE one 4/12 train is better then 6 1/2 trains) but at that point the bottleneck ceases to be the train->chest and becomes the stacker->station.
Only ways to break that bottleneck is adding more engines (faster accelleration) or just duplicating the entire station plus stacker. Or just go with even larger trains.

I went with the latter and broke up the centralized smelter into 8 smaller ones.
I imagine you have a stacker with N lanes that then merge back into one. That then splits into 3 unloading stations. Or you have a N:3 cross. Anyway, only one train can ever go from the stacker to a station. Also trains need to start from 0, cross over to the station and stop without ever getting up to speed.

What you want is for trains to come from the mine, barreling in at full speed and then break at the last minute till they stop at the unloading station. Also the split to individual stations should be when the trains are still at speed so the next train doesn't have to break prematurely. So build things large, split early and have more unloading stations. Ideally have no stacker at all. If you have as many unloading stations as trains then you guarantee each train can reach a station without stopping.

You can have more trains with the assumption that some of them will be loading at the mine or on the way. But That is a fragile thing. If trains come in too slow then you run out of ore. If they come in too fast then they will wait before a station and take extra time to accelerate and break again to enter the station. There is a small window where throughput will be optimal. Better to be save and just have more unloading stations.

I'm currently building a train system in a Seablock game and my target goal is to have each station scaled to need about one train per minute or less. If thgat means more stations and more but smaller smelter than that is the way to go.
Top
zOldBulldog
Smart Inserter
Smart Inserter
Posts: 1161
Joined: Sat Mar 17, 2018 1:20 pm
Contact:
Contact zOldBulldog

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

I just wanted to come back and thank all that contributed. I didn't post much here to avoid interfering with the discussion, but I've read and reread the whole thread many times, trying to figure out which design(s) to use "most of the time" even though I know I'll come back to both this and Eradicator's thread over and over for scenario-specific designs later on.

For now, mainly due to compactness, I am testing the following in the unloads for my main bus. I'll report how they work as I use them through a build from the early low demand phase to the late high throughput space science phase. I am actually moving the smelters to their own outposts so that I just measure how these unloaders work with the bus demands, by unloading smelted products.

The tests will be done with 1-2 trains. Also, please keep in mind that I am still trying to fully understand how these balancers work, some of it is still Greek to me and I will almost certainly make some wrong interpretations and adjustments.

- DaveMcW's unloader with an 8-8 balancer. It lost some throughput due to the balancer, but worked reasonably well. It didn't unload quite 100% evenly but seemed to keep up OK. The main inconvenience was bulk, this used lots of space.

- Durentis unbalanced splitter trick unloader from Eradicator's thread (similar to Nog's in this thread but unloads with 6 splitters per wagon and produceds 4 belts) taking the belts from each side of the 1-2 train to a 4-4 balancer. I am hoping that by unloading a set from one side it will prevent train delays even if the chests get unbalanced. This one is quite compact and looks promising for unloads where I feed 1 train to less than 4 belts.

- Eradicator's final bot-based design, although I wanted to unload from both sides of the track so I placed the passive provider chests on both sides of train. I setup 4 roboports and fed it 200 bots. I hope I didn't mess up his design.

- Durentis final bot-based design, although I could not handle the "lots of track" on both sides of the track. So, I removed the tracks from one side but kept his Passive Provier, Active Provier and Buffer chests, to make the bots go "deliver" to the other side. I probably botched his design by doing this, but we'll see.

The bot-based designs are looking very attractive. They are much more compact and don't waste space or throughput as they should not require additional balancers. And except for some low-throughput train stations (like for uranium ore) I think I can get the necessary advanced chests and nuclear power going before even starting the bus and these "feed the bus" unload stations.

If you think I'm interpreting the discussions, advantages and disadvantages incorrectly... please let me know, perhaps with an explanation to help me understand. As long as I am getting good advice I don't mind being called an idiot :)

NOTE: Edited this post after laying down my test unload stations. Much more relevant now.
Top
User avatar
Killcreek2
Long Handed Inserter
Long Handed Inserter
Posts: 73
Joined: Sat Dec 10, 2016 8:39 am
Contact:
Contact Killcreek2

Re: Challenge: Generic max-speed train unload

Post by Killcreek2 »

I am really late to this thread, damnit (took a break from Factorio). Some very creative setups here, & lots of good discussion worth reading!

Hope I'm not too late to submit another design for consideration: Also bot-based but with unload-inserter throttling* (did not notice anyone else in the thread using this approach).
image
blueprint
Design points:
~ *Wagon unload inserters are all linked to the logi-net, each set to activate if iron plate < 1k. Synchronised Swinging™ prevents uneven wagons.

~ *Requester chests (the item buffer) are calibrated based on the stack size of the inserter(s) that draw from them. ~20sec of buffer storage in the example BP above. Adjust to taste.

~ *Storage chest is used as a "governor" to match the wagon unloading rate with the drain on the output belt(s). This prevents buffer over-run. (A variable-activity factory may require a few more storage chests, but only to prevent bots hovering-with-cargo due to a sudden drop in demand.)

~ Belt loading & compression is done using the (now standard) 12+7 stack size trick.

~ Compact & tileable. Though I would not recommend more than 4 wagons, as numbers of bots & ports required increases non-linearly.

~ Has easily exceeded 6 belts per wagon during testing. Back in v0.15 & early 0.16, unfortunately I did not record the max sustained average (iir: between 250-300 items/sec/wagon @stack100, better for stack200 & worse for stack50), though the next train was always waiting nose-to-tail behind; with signals 1-wagon apart to reduce the delay even further (see pic above); & eating rocket fuel. 7 belts per wagon might be feasible with nuclear fuel.

~ Requires a stand-alone roboport network. Possibly a negative...

~ Not sure how many bots are needed. Usually I dump a few hundred in, & then add more later if the active providers are not being emptied in a timely fashion.

An unanticipated (by me) & curious quirk of the design is this: As the output drain increases (up to the max sustainable throughput), the percentage of bots visiting the "governor" chest seems to decrease (ie; most of the bot traffic is from active provider to requester, at high sustained output levels).
"Functional simplicity, structural complexity." ~ Appleseed
Top
User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:
Contact disentius

Re: Challenge: Generic max-speed train unload

Post by disentius »

Nice one!
I picked up a "no bots" somewhere, not sure it was actually mentioned here.
Main reason for not throttling inserters: it makes train unloading longer. not sure that matters here.
Top
User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 694
Joined: Fri May 12, 2017 3:17 pm
Contact:
Contact disentius

Re: Challenge: Generic max-speed train unload

Post by disentius »

Played a bit with your setup.
Came up with this thingy to unload 6 belts per wagon.
Image
Upper counter: # ore in provider chests
Lower counter: # free bots

- syncing inserters with the first and last one
- 140 bots
- stackable
- symmetry

It wont work though. Found no way (in vanilla) to deliver trains fast enough. (maxed out breaking research and used nuclear fuel)
With 4 belts per wagon its a happy camper. (80 bots)

blueprint
Top
User avatar
Killcreek2
Long Handed Inserter
Long Handed Inserter
Posts: 73
Joined: Sat Dec 10, 2016 8:39 am
Contact:
Contact Killcreek2

Re: Challenge: Generic max-speed train unload

Post by Killcreek2 »

disentius wrote:Main reason for not throttling inserters: it makes train unloading longer. not sure that matters here.

It can make unloading longer, but not always. In my design it only slows train unloading when it is not running flat-out at maximum possible speed.

At less than max output it runs in a burst cycle mode (throttle partially closed), & the cycle rate is dependent on output demand. As demand increases the cycle times shorten, up to the maximum threshold where the burst cycle time approximates inserter rotation time. At that point the inserters will switch off as they unload a stack & start to swing back, but switch on again just as they return to the wagon for the next stack (throttle fully open).

As the cycle time between trains is a constant, the two variables that need to be matched per train cycle are the averaged train unloading rate & sustained belt output rate. So you are correct that it doesn't matter here, as the throttling only happens whenever output demand is less than maximum sustained, to prevent the buffer over-filling & imbalanced wagons.
disentius wrote:Played a bit with your setup.
Came up with this thingy to unload 6 belts per wagon.

I see you switched to a passive chest buffer, & using circuit wire in lieu of the logi-net connection. I was considering a circuit-based version, so you have prompted a few new ideas. Linking all the unloading inserters to the governor chest(s) would be simple enough, & I could even add a constant combi to adjust them quicker than current change-one-&-copy-pasta-the-rest method.
Though the response time of the system may suffer as a result: the logi-net version seems to run on the virtual chest contents including any pending bot deliveries (1-2 tick response time), & I'm assuming a circuit version would run on the actual chest contents after delivery instead (please correct me if I'm mistaken here!).
...Which would neatly explain your passive chest circuit approach, to avoid any bot flight-time delays. Nice solution.

So the better choices for inserter throttling would seem to be: Active with sync'd inserters for logi-net based bot designs, & passive with sync'd inserters for circuit based bots.
disentius wrote:It won't work though. Found no way (in vanilla) to deliver trains fast enough. (maxed out braking research and used nuclear fuel)
With 4 belts per wagon its a happy camper. (80 bots)
~5 belts per wagon should be possible for ores though, if you nose-to-tail the trains & place signals 1 wagon apart (would have 3.96 sec to get the next train in, if I got the math right). 6 belts per would require 100stack items @ 4.61 sec for next train, 7 belts per with 200stack @ 4.47 sec.
"Functional simplicity, structural complexity." ~ Appleseed
Top
Proculator
Burner Inserter
Burner Inserter
Posts: 10
Joined: Wed Dec 19, 2018 8:28 pm
Contact:
Contact Proculator

Re: Challenge: Generic max-speed train unload

Post by Proculator »

A lot of effort expended on this topic. Only looked at frontend and skimmed the rest … but impressive.

Hope you like my current and future efforts. I. e. Hoping to develop some Factorio friendships.

Any suggestions where in the Forum (I. e. sub-forum(s)) that a beginner should hang out?
Top
User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 884
Joined: Wed Jul 12, 2017 5:45 pm
Contact:
Contact Oktokolo

Re: Challenge: Generic max-speed train unload

Post by Oktokolo »

Proculator wrote: ↑Thu Dec 20, 2018 9:39 pm Any suggestions where in the Forum (I. e. sub-forum(s)) that a beginner should hang out?
Youtube ;)
Top
oloklir
Burner Inserter
Burner Inserter
Posts: 5
Joined: Mon Dec 17, 2018 6:09 pm
Contact:
Contact oloklir

Re: Challenge: Generic max-speed train unload

Post by oloklir »

Interesting thread is bumped. I release my work here.

Throughput is 32 belts = 1280/s. No bots, only inserter works.

Unfortunately, 8belts per wagon is not suitable for 50/stack or 100/stack contents. There is gap created while next train coming.
However, 200/stack contents can maintain belts full.
1.jpg
1.jpg (178.67 KiB) Viewed 7400 times

2.jpg
2.jpg (162.59 KiB) Viewed 7400 times
3.jpg
3.jpg (494.93 KiB) Viewed 7400 times
Top
naddur
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Jan 26, 2020 5:43 am
Contact:
Contact naddur

Re: Challenge: Generic max-speed train unload

Post by naddur »

Oooh crazily inefficient but super fast unloading challenge? Here is one similar to the box example earlier in this thread, but uses cargo wagons so you can use stack and long handle inserters. The belt portion is janky since I slapped it together more to get thruput numbers. Short of finding a way to unload from each original train with more than 12 stack and 12 long handle inserters I can't find a way to make it any faster. Unloading onto belts is fairly trivial since the wagons are soooooo long.

It scales using chests at 375.5 items per second for each "imaginary wagon". So the screen shot of 2 cargo trains does 750 items per second using boxes (4 cargo trains would do a theoretical 1500). Going from theoretical to "reality but silly", 3 train loop each with 2 nuclear engines and 2 cargo wagons, a 10 minute timer came up with 605 items per second.
Attachments
traintotrain.jpg
traintotrain.jpg (1.15 MiB) Viewed 6154 times
Top
Post Reply

Return to “General discussion”