Page 1 of 1
Those damn train signals
Posted: Sat May 27, 2017 3:27 pm
by Keseven
I have watched a few videos on signals and each time think I get it, but I can never get the simplest thing to work correctly in all situations.
To perhaps finally have the penny drop, could someone please help explain what signals I need in the below to allow trains to travel freely in the upper rail, even when any of the bottom two unloading tracks are in use?
- Capture.PNG (385.64 KiB) Viewed 4835 times
Re: Those damn train signals
Posted: Sat May 27, 2017 4:07 pm
by Kelderek
One of your first problems is the chain signal on the wrong side of the track in the lower right (see yellow X below), that needs to be removed. Based on the way you are doing this track all your signals need to be on the right hand side of the track in the direction of travel. Since your track moves east to west then the signals need to be all on the north side of each track.
R = rail signal
C = chain rail signal
This will work, the main line will have priority, but due to the way you designed this if more than one train wants to go to either of those stops then it will back up onto the main line and block traffic. If you only have one train for each of those then you may be ok.
- Train Help 8.jpg (237.79 KiB) Viewed 4826 times
Re: Those damn train signals
Posted: Sat May 27, 2017 7:52 pm
by vanatteveldt
- You need to avoid a situation where a train waiting at a signal can block another train that wants to go a different route.
- This can only happen on shared blocks, where a shared block is any block where tracks cross and trains can come from and go to different directions. Merging tracks aren't a shared block because trains always exit in the same direction, so a waiting train can only block trains that would have to wait anyway.
- For optimal throughput, you want to keep shared blocks occupied as briefly as possible
From this follow some simple signalling rules:
- Chain signals on any track right before a shared block (i.e. where the two tracks cross)
- Normal signals right after shared blocks, but there needs to be a full train length until the next signal, otherwise use a chain signal.
- Normal signals right before merges and right after splits
Re: Those damn train signals
Posted: Sun May 28, 2017 6:49 am
by Keseven
Kelderek wrote:One of your first problems is the chain signal on the wrong side of the track in the lower right (see yellow X below), that needs to be removed. Based on the way you are doing this track all your signals need to be on the right hand side of the track in the direction of travel. Since your track moves east to west then the signals need to be all on the north side of each track.
R = rail signal
C = chain rail signal
This will work, the main line will have priority, but due to the way you designed this if more than one train wants to go to either of those stops then it will back up onto the main line and block traffic. If you only have one train for each of those then you may be ok.
Using your updated image, I derived a logic to use which I extended to the rest of my rail build, which included more and different kinds of junctions and cross overs, and it all works smoothly after a few more hours of gameplay.
Thanks so much!
Re: Those damn train signals
Posted: Sun May 28, 2017 3:48 pm
by Kelderek
You're welcome, glad I could help. Your design may run into more problems as you add more trains to your network, especially if you add additional trains that try to go to the same stop. A better design would incorporate waiting bays or other additional rail segments off of your main line that feed into your stations, so if three trains decide to go to one station all at the same time you might have room for two to wait in a space that doesn't block passage on the main line. The size of your waiting bays should correspond to the number of trains that might possibly show up.
What you have now will work fine as long as only one train goes to each station.
Re: Those damn train signals
Posted: Sun May 28, 2017 4:03 pm
by Distelzombie
I usually use this rule:
If a track crosses another track place a chain signal infront of the crossing on both lines and a rail signal after.
If two tracks converge ... do the same. It works always. The picture that Kelderek showed does it differently in order to give the main line priority over the stations. Thats why he used rail signal infront of the crossings on the main line.
EDIT; Meh, I didnt really read what everyone wrote.. xD
Re: Those damn train signals
Posted: Sun May 28, 2017 8:22 pm
by vanatteveldt
Distelzombie wrote:I usually use this rule:
If a track crosses another track place a chain signal infront of the crossing on both lines and a rail signal after.
If two tracks converge ... do the same. It works always.
It is really not needed to place chain signals for mergers. If a train blocks the merge, it can only block trains that would go on to the same track, and so would also be blocked by the same thing that's blocking the train.
Schematically:
Suppose That D is blocked by another train. If a train comes from A and moves onto the merger (C), he will block access to a train coming from B. However, a train from B would also be blocked by D. So it will never matter. If you have chain signals on the merger, the train would wait at A instead of C, but the train from B can still not proceed because D is blocked and is still waiting at (now a chain signal) B.
Code: Select all
Merger:
A ---\ /---C
X
B ---/ \---D
Now suppose D is blocked but C is free. If a train from A to D is allowed to enter and block the junction X, a train from B to C would also be blocked, even though the road to C might be clear.
Re: Those damn train signals
Posted: Sun May 28, 2017 11:46 pm
by Distelzombie
vanatteveldt wrote:Distelzombie wrote:I usually use this rule:
If a track crosses another track place a chain signal infront of the crossing on both lines and a rail signal after.
If two tracks converge ... do the same. It works always.
It is really not needed to place chain signals for mergers. If a train blocks the merge, it can only block trains that would go on to the same track, and so would also be blocked by the same thing that's blocking the train.
Schematically:
Suppose That D is blocked by another train. If a train comes from A and moves onto the merger (C), he will block access to a train coming from B. However, a train from B would also be blocked by D. So it will never matter. If you have chain signals on the merger, the train would wait at A instead of C, but the train from B can still not proceed because D is blocked and is still waiting at (now a chain signal) B.
Code: Select all
Merger:
A ---\ /---C
X
B ---/ \---D
Now suppose D is blocked but C is free. If a train from A to D is allowed to enter and block the junction X, a train from B to C would also be blocked, even though the road to C might be clear.
This makes absolutely no sense to me.
Could you use ingame footage?
In the X case a train shouldnt block the junction at all if using chain signals and In the first case... I cant decipher the placement of the signals from this explanation. Of course no train can move if D is blocked... So what is your point here?
Re: Those damn train signals
Posted: Mon May 29, 2017 3:21 am
by Shokubai
You need a signal behind the train at the station and in front of the station. This pair of signals sort of captures the trains and allows movement around it. You also need to signal your crosses but that isnt specifically the problem.
Re: Those damn train signals
Posted: Mon May 29, 2017 4:09 pm
by Kelderek
Distelzombie wrote:vanatteveldt wrote:Distelzombie wrote:I usually use this rule:
If a track crosses another track place a chain signal infront of the crossing on both lines and a rail signal after.
If two tracks converge ... do the same. It works always.
It is really not needed to place chain signals for mergers. If a train blocks the merge, it can only block trains that would go on to the same track, and so would also be blocked by the same thing that's blocking the train.
Schematically:
Suppose That D is blocked by another train. If a train comes from A and moves onto the merger (C), he will block access to a train coming from B. However, a train from B would also be blocked by D. So it will never matter. If you have chain signals on the merger, the train would wait at A instead of C, but the train from B can still not proceed because D is blocked and is still waiting at (now a chain signal) B.
Code: Select all
Merger:
A ---\ /---C
X
B ---/ \---D
Now suppose D is blocked but C is free. If a train from A to D is allowed to enter and block the junction X, a train from B to C would also be blocked, even though the road to C might be clear.
This makes absolutely no sense to me.
Could you use ingame footage?
In the X case a train shouldnt block the junction at all if using chain signals and In the first case... I cant decipher the placement of the signals from this explanation. Of course no train can move if D is blocked... So what is your point here?
He actually disproved his own point, lol. The second example with the X in the middle is exactly why it is useful to have chain signals before a merger. He is correct that in the case of the first example it wouldn't matter much if the chain signals before the merger were not there, but I consider it good practice to have them since situations like the second example may come up and then they make a big difference.