It has been suggested that this article or section be merged with Merging Tracks. (Discuss)

This article may need to be updated. Please update this article to reflect recent events or newly available information, and remove this template when finished. Please see the talk page for more information.

In our networks we often have lots of tracks that want to join to other lots of tracks. Often the load on the tracks is unequal, so you want to provide incoming tracks with the choice to pick any outgoing line, otherwise you might end up having pretty much empty lines joining to other pretty much empty lines and full lines trying to join to other full lines. The first is obviously fine but you can see the latter might be problematic. Enter: balancing.

Single-track to multi-track: 2+1->2

This is a situation you'll often come across in our games; a sideline joining a mainline at a sideline hub. This is also pretty straight forward, you just want the sideline to be able to pick from every mainline. A potential issue when you start joining to multiple tracks is blocking. Blocking happens when the block between the mainline and the joining line is not large enough to hold an entire train and a mainline train enters the priority section while a train is joining, which then gets stopped and also blocks other trains trying to join. Got that? The image below shows a blocked train.

A train that got blocked while joining

The solution to this is to eliminate the combo signal, meaning you want every block to be able to hold at least one train.

Non-blocking 2+1->1 join.

It's pretty easy to repeat this process when you have more than 2 original tracks.

A 4+1->4 balanced merge

Multi-track to multi-track: 2+2->2

This is where it gets interesting. These kinds of joins usually occur at backbone hubs and main station hubs. The easy way to balance these is to just repeat the single-track to multi-track merge for every incoming track, as seen below.

A 2+2->2 join that actually consists of a dual 2+2->1 join

There is however an issue with this approach. The track that joins first has an advantage over the later joins, because the later joins also have to cope with the added load added by trains joining from the merges before. When you use this technique for larger joins the problem becomes bigger too:

Showing ProZone Game 05's massive 8+8->8 join, joins like these magnify the problem described above

This can be solved by adding a cross allowing trains to switch the joining track, as you can see below:

A 2+2->2 join using a cross to allow trains to switch, non-blocking, of course

The same join, with trains occupying the reserved blocks

This cross-joining style can be used for wider tracks relatively easily:

Showing a 3+2->3 merge in Public Server Game 146

alternative for the 2+2->2 where all trains join in 1 point:

Priorities on BBHs

It is often said that priorities are not needed in BBHs, because the loads have equal priority anyway. Priorities on backbone hubs, however, don't actually serve the purpose of giving priority; they are only there to disrupt ML traffic as little as possible. Often the priorities are nowhere near long enough to allow for full acceleration, unlike those at SLHs, and it's no problem to shorten them if the joining track seems to be jamming because of the long prios.

<< Priority | ^^ Back to Presignals Guides Index | Complex Junctions