Train queuing...

[Mr. Tact]

I was working on a new ore off loading station for one of my factories and was thinking about how ore deposits are going to be further and further away. Meaning it will take longer for the trains to do round trips, meaning I'll need more trains, meaning I should probably have some type of ability to queue up trains for when the timing is such that several show up at the same time -- I don't want them backing up onto the main line and blocking other traffic. I did what I assume is a pretty standard build coming up with this:

train queue 2.jpg (575.84 KiB) Viewed 14007 times

So, only one Train Stop for the moment, but room to make it a second off loading position if needed and then room for six trains to queue up behind them. Okay, that's all the background / setup. Now I have a question..

When trains are queued up behind a single stop like this, what determines the order in which they will cycle through the stop?

[Miravlix]

As I understand it, while signal queueing kinda works, it's accidental feature that is not coded for optimal CPU usage. It also not a real queue, so no guarantee that 2/3 of those trains won't be stuck in the line forever.

To ensure consistent behavior, you want only one waiting line.

[searker]

Yes, there isnt any real queue implemented atm. Basically, every red signal is looking for a free path ever so often (dont know the correct number, lets say every second / 60 ticks).
Therefore, you cant really predict which train will leave next. In your example, one of the chain signals would turn green meaning that one of those three trains will leave next. However, the same signal could turn green again in the next "cycle" meaning one of your three lanes would now be empty but the other two would still have 2/2 trains in them.

This leads to multiple solutions:
If you want a real queue, you have to use only one lane for waiting trains.

If you just process one resource and a "first in, first out" flow is not needed, you can have as many parallel lanes and blocks in those lanes as you like (your current setup).

If you process multiple resources and use one shared waiting area, you should use parallel lanes containing only one "waiting-block" per lane to ensure no train is being blocked by a train with a different resource sitting infront of him.

edit:
Besides that mechanic, trains will try to get as close to their destination as possible (not the real distance, but rail-block-wise), meaning that your trains should try to fill all blocks in the waiting-area before backing up to the main line.

[Mr. Tact]

Well, that is disappointing to hear, although not entirely surprising.

I starting running a bunch of trains through this setup with short timers to see if I could figure out a pattern. It definitely is not a FIFO operation. But, despite enough traffic where one row could sit idle while the other two lanes were serviced, that didn't seem to happen -- which was nice to see. However, I did see a behavior I could not explain, perhaps someone else could? You'll notice in the lower right hand corner of the image, on the inbound line just before the three splits, I have a Rail chain signal with standard Rail signals not far behind on each of the queuing lines. Occasionally (not often) a train would stop at this chain signal despite there being open spots in the queue. Each time it happen, the train cleared when a line with two trains already waiting, advanced. I guess it had chosen that lane prior to the second train showing up in the previous signal check cycle?

[Shokubai]

There is a balance to be had with Queues, Trains and unloading.

Too many trains and too few unloading areas and, as somebody mentioned, some trains may never leave the queue.

Just be sure you can process all your trains in less time than it takes for the average round trip commute and you should be fine.

Nice design!

[searker]

I guess it had chosen that lane prior to the second train showing up in the previous signal check cycle?

Yes, that is what mentioned after my edit. Depending on the distance from / to your outposts, this might happen more or less often.
The only way to minimize this behaviour as far as possible would be to add a second train-stop somewhere around the lower right chain signal with a stop time of 0 for all trains.
This would lead to every train stopping there, but would force them to recalculate their path when entering the waiting-area.

Because of this "problem", most people tend to only using one block per parallel lane; That, way, every incoming train will "reserve" its own lane before waiting outside the area.

[Mr. Tact]

Yeah, this design is totally over-engineered. It is intended for a single ore. My current setup is the unloading spot with room for a single train queued behind it -- basically I'm just trying to add in the queuing. Even if I take on the goal I was considering which got me thinking about this expansion, I can't believe that I'd ever have (or need) eight separate trains running for a single ore. But it got me thinking / wondering...

[Neotix]

I think that non of that train will stuck because trains already are queued inside game code.
I tested some setups with 2 way rails (intersection), few stations and trains. It wasn't rail queue but it shows queue behawior.

Test setup:

Code: Select all

[A] ----------[S1]-\
[B] ----------[S2]-------------- [D]
[C] ----------[S3]-/

There was 3 trains that have schedule (different times in schedules):
Train 1 - [A] <-> [D]
Train 2 - <-> [D]
Train 3 - [C] <-> [D]

It works like that:
Train 1 go to station [D]. Train 2 stop on signal [S2]. Train 3 stop on signal [S3].
Train 1 go to station [A]. Train 2 go to station [D]. Train 3 waiting on signal [S3].
Train 1 stop on signal [S1]. Train 2 stop on station [D]. Train 3 waiting on signal [S3].

In that moment we have 2 trains on signals and Train 3 arrive to the signal before Train 1.

Train 2 go to station . Train 3 go to station [D]. Train 1 waiting on signal [S1].
That step proved internal queue because without it, Train 1 would go to station [D] and Train 3 would stuck on signal [S3].

I don't know if that wasn't changed because i tested long ago before chain signals. But if wasn't then rail queue should work without problems.

[ratchetfreak]

If you need each train to leave at some point then you can wait until 0.13 where you can create a circuit to make a proper round robin waiting queue.

[Mr. Tact]

Hmm, replacing the chain signal with a normal signal SEEMS to have resolved the issue with trains occasionally stopping outside the queuing area despite there being open spots. I'll run the trains through the setup a while longer and we'll see....

[SpeedDaemon]

Besides that mechanic, trains will try to get as close to their destination as possible (not the real distance, but rail-block-wise), meaning that your trains should try to fill all blocks in the waiting-area before backing up to the main line.

I don't think you can count on that. If a train last updated its path when one of the three waiting tracks was empty, then it will still try to go there, even if it's full, if it hasn't had something trigger a pathing update before it takes the final split.

The OP has a chain signal before the split, but I don't know if that would force the train to stop or recalculate its path if its original path now has a red signal on the block exit. I'm pretty sure I've seen problems with this, which is why I generally just build parallel stops with a FIFO waiting area instead of parallel waiting areas and one stop.

[Mr. Tact]

Did this get addressed? I was looking at again today and it seemed to be working on a FIFO basis, but my dataset was not large, I might just have been flipping heads every time.

[Mr. Tact]

Hmm, looking again I added another chain signal to the setup. Maybe that makes the difference?

train queue 3.jpg (316.83 KiB) Viewed 13809 times

[Hannu]

Hmm, looking again I added another chain signal to the setup. Maybe that makes the difference?

I think that signal in that place makes nothing.

But what is the actual problem if identical trains are not circulated evenly? In any case they act as buffers. If your consumption increases or ore production of frequently used train's mines decreases they are ready to begin their work. When there is no trains waiting it is time to increase something.

I make parallel waiting tracks with own stops for every trains. Room and tracks are practically free and it is easy to build. I get also nice realistic looking rail yards. Such a system works flawlessly hundreds of hours under heavy load, except sometimes a train try to go through a wrong track and get couple of minutes delay, but I have enough buffers to handle such situations.

[Mr. Tact]

I'd hesitate to call it a "problem", I originally noticed I did not get FIFO processing with the setup. Which could potentially cause issues with ore loading sites being visited in an "uneven" order which could potentially cause heavily visited ore loading site chests to run dry. But I was messing it with again yesterday and I SEEMED to be getting FIFO processing. But as I said, the sample size was not large...

[Mr. Tact]

I make parallel waiting tracks with own stops for every trains. Room and tracks are practically free and it is easy to build. I get also nice realistic looking rail yards. Such a system works flawlessly hundreds of hours under heavy load, except sometimes a train try to go through a wrong track and get couple of minutes delay, but I have enough buffers to handle such situations.

Share a screenshot?

[Boogieman14]

Since rail signals can now be hooked up to circuit networks, you could probably implement some kind of round robin mechanism to enforce all trains getting their turn. (I have no clue how that would work, I'm not too well versed in combinator logic, but in theory it might be possible )

[realm174]

This is the type of layout I've been using lately. I have a multi track unloading area (7 in this case, but could be larger/smaller). The entrance to those different tracks all have a rail signal hooked up to the unloading chests for each track. If there's something in the chests, the signal is red, forcing trains to use a different track, and balance the unloading (that way, a train isn't stuck waiting for room in chests to unload). Once the train is unloaded, it goes to the "Waiting Area". On there, I have 5 tracks only: Iron, Copper, Coal, Stone, Alien Ore. Each train specialises in a specific ore to pick up. So when they unload, they go to their respective waiting area. There, signals are hooked up to all the chests in the unloading section, keeping track of how much of each ore there is. Signal turns green when level of any given ore is low. I chose (in this case) to hook up those signals to the chests in the unloading area, but if you tend to store inventory in other chests, that's where you would have them linked to.

Anyway, here's a screen shot.

[Hannu]

I make parallel waiting tracks with own stops for every trains. Room and tracks are practically free and it is easy to build. I get also nice realistic looking rail yards. Such a system works flawlessly hundreds of hours under heavy load, except sometimes a train try to go through a wrong track and get couple of minutes delay, but I have enough buffers to handle such situations.

Share a screenshot?

http://imgur.com/a/GoHwX

Tukikohta rauta = Base iron
Tukikohta kupari = Base copper
Tukikohta öljy = Base crude oil
Tukikohta hiili = Base coal
Tukikohta kivi = Base stone

These are unload stations. There are only on coal and stone trains, so they go straight to their unload stations through pass tracks. There are (up to) 6 iron plat trains. They go first to Varikko rauta 1-6 tracks and wait 10 seconds there (Varikko means (train) depot). Then they move to next chain signal which sends one train to unload. I do not have any special turn system, but I do not see any need for that. I have currently two iron smelting factories and two iron train per factory and they are able to keep my base running at full consumption as long as my mines work. I have 5 tracks for copper (Varikko kupari 1-5). It is more than needed now (2 trains and 1 smelting unit), but when I made this railyard I had copper smelting in my base and I had 4 ore trains. Varikko Öljy 1-2 are waiting tracks for crude oil trains.

Tukikohta puolustus is loading station for 2 defense trains. They are so short that other one can wait on the same track if they come simultaneously.
Tukikohta työjuna is for my personal work train.
Tukikohta vararaide is a spare track. I have another 6 wagon train there, which I connect to my work train if I need huge amount of stuff.
Tukikohta huolto is for service train between the Base and metal smelting factories.

Edit:
I added another picture from smelting unit.
Rautasulatto 1 means Iron smelting factory 1.
malmi odotus 1-6 means ore waiting 1-6. Ore trains wait on these tracks before actual unloading on Rautasulatto 1 malmi.
rauta odotus 1-2 are waiting tracks for plate trains and Rautasulatto 1 rauta is loadind station.
hiili odotus is not used because there is only 1 coal train (which services all my smelting units).
There is also tracks for work train (työ) and service train (huolto). The service train brings solid fuel for ore trains and transports some iron ore to the main base to make concrete.

[vanatteveldt]

I make parallel waiting tracks with own stops for every trains. Room and tracks are practically free and it is easy to build. I get also nice realistic looking rail yards. Such a system works flawlessly hundreds of hours under heavy load, except sometimes a train try to go through a wrong track and get couple of minutes delay, but I have enough buffers to handle such situations.

Is there a benefit to adding stations on the waiting bays instead of just placing a bunch of parallel tracks behind chain signals?

My current setup is a bunch of waiting bays, followed by a u-turn, followed by a bunch of (un)loading bays which each have room for one waiting train to minimize empty station time:

station

(Since the edge bays come from a horizontal track, this can be extended indefinitely to the sides to create extra bays without becoming any longer vertically)