|
|
| (10 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| − | 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.
| + | #REDIRECT [[Merging Tracks]] |
| − | | + | |
| − | Let us clear out some misunderstandings first.
| + | |
| − | | + | |
| − | :''"The goal you want to achieve by balancing is to have equal loads on every track."''
| + | |
| − | | + | |
| − | This is not true. Mainlines are built for 100% capacity so it's not a problem when you have a two-track mainline with one track that is 40% loaded and one that is 90% loaded. The problem emerges when you try to join a 70% loaded track to an 80% loaded track.
| + | |
| − | | + | |
| − | :''"I don't have to balance this join, traffic is already balanced."''
| + | |
| − | | + | |
| − | The point I made before also shows this assumption is wrong; balancing is ''not'' about achieving equal loads. This is also why constructions such as the one below are completely pointless.
| + | |
| − | [[File:inline_balancing.PNG|400px|thumb|none|Inline balancing. Pointless and bound to cause problems once you get dense traffic running]] | + | |
| − | | + | |
| − | ==Balancing in text==
| + | |
| − | If you want to describe what kind of merge you're talking about, use this format:
| + | |
| − | :Amount of original tracks + Amount of incoming tracks -> Amount of outgoing tracks
| + | |
| − | So if you'd have a sideline joining a two-track mainline, you'd have 2+1->2.
| + | |
| − | | + | |
| − | So much for the theory, let's get building.
| + | |
| − | | + | |
| − | == Single-track to single-track: 1+1->1==
| + | |
| − | Of course this is not actual balancing; there is only one outgoing track so you can't provide choice. If you do want to have some control you could add a simple [[priority|priority]] line. Or if you're feeling really adventurous you could even throw in a [[compressor|compressor]]
| + | |
| − | Now let's move on to some more relevant stuff.
| + | |
| − | | + | |
| − | ==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.
| + | |
| − | | + | |
| − | [[File:Block.PNG|400px|thumb|none|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.
| + | |
| − | | + | |
| − | [[File:noblock.PNG|400px|thumb|none|Non-blocking 2+1->1 join.]]
| + | |
| − | | + | |
| − | It's pretty easy to repeat this process when you have more than 2 original tracks.
| + | |
| − | | + | |
| − | [[File:4_1_4.PNG|400px|thumb|none|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.
| + | |
| − | | + | |
| − | [[File:ugly.PNG|400px|thumb|none|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:
| + | |
| − | | + | |
| − | [[File:even_uglier.PNG|400px|thumb|none|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:
| + | |
| − | | + | |
| − | [[File:crossjoin.PNG|400px|thumb|none|A 2+2->2 join using a cross to allow trains to switch, non-blocking, of course]]
| + | |
| − | | + | |
| − | Alternatively this cross can be made a bit smaller, but also a bit less effective, using PBS:
| + | |
| − | | + | |
| − | [[File:crosspbs.PNG|400px|thumb|none|A crossover/switch using PBS]]
| + | |
| − | | + | |
| − | This cross-joining style can be used for wider tracks relatively easily:
| + | |
| − | | + | |
| − | [[File:snowycross.PNG|400px|thumb|none|Showing a 3+2->3 merge in Public Server Game 146]]
| + | |
| − | | + | |
| − | ==Priorities on BBHs==
| + | |
| − | It is often said that priorities are not needed an 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.
| + | |
