Mutiple Block Clearance (A way to acheive it).

[simonjackson1964]

Apologies to anyone who has already figured this out on their own, or has actually got a better way of doing it.

Something I have noticed while travelling by train is that on modern railway networks it is normal for the signals on the main line to default to "Clear", green, "drive" or off (all meaning the same), unless there is a train in the block they are protecting. This is to avoid unnecessarily slowing an express train. I can't say this for certain but I can imagine that in the days of hand pulled signals, the signalmen would want to clear the express through as far as possible too.

One way to try and simulate this on MBS v7 would be to have a single route containing all the block sections you wish to clear at once. The problem with this is that the route will not fully release and thus will not allow another train into the first block, until the last block is empty. Obviously this kind-of defeats the object. The ideal way to set routes is a one-to-one correlation between block sections and routes.

A better way to simulate the route of the train being cleared as far as possible is to "cascade" or "domino" the individual routes.

Each route will have a variable on it, naming the next route in sequence. There can also be a keyword if you wish but it's not strictly necessary. An event "When any route is activated/deactivated", holds the condition: "If Trigger Route is Active", and the action: "Activate Route (Trigger-Route.Next-Route)".

Defer Request is important, as at some point you will have a route that cannot be activated immediately due to a train being on it. I have tested this and it works perfectly on a straight track between two depots and on a continuous circuit. Set one route to clear and the rest cascade all the way around. On a continuous loop with a single train it will clear the entire loop except the one with the train on, but that will be deferred until the train leaves, allowing the train to run indefinitely on the loop with no intervention.

But what about junctions? What if there is more than one possible route for my train to take?

For this we require a slight modification:

On any route where there is more than one possible next route, do not add the "Next Route" variable to it.

Instead, place a track contact at the earliest place a train will encounter it - this will usually be immediately after any preceding junction, inside the first block after that junction. This track contact should have a keyword "Junction" (or similar), and a list variable holding the routes available for that junction. While this would normally be two, a multiple junction for sidings would be treated as a single junction.

NB: This solution does not cater for choosing the First Free Siding. I leave that for people to figure out on their own! But if each train always goes into the same station platform, for example this works just fine.

So: Track contact in place.

Now each locomotive that will pass through the junction will need a list of routes it will take at each facing junction it comes to. If the train will only go through one facing junction, still use a list, as this cuts down on coding. A list of one element is still a list.

Now we need an event, activated when a track contact with Keyword "Junction" is triggered upon entering The keyword is important and can be added to any track contact including a signal, as long as it is in the right place and has the list of available routes on.

Within this event we have two nested iterations, one for the triggering contact and the other for the triggering vehicle. It doesn't matter which order they are in, but I usually put the track contact one outside because usually (not always) it will have the fewer iterations.

Within the inner iteration, the condition "If Iter1 = Iter2" will say "This train is taking this route", and if the condition is met, set the route active-deferred.

Important:

• This is not necessary on trailing junctions, only facing.
• The route immediately before the junction is the one that does not have the "Next Route" variable and is the last possible place that the "Junction" track contact can be. The routes that start at the junction should each have their own "Next Route", so that when the junction is set, the cascade/domino will continue
• Terminus routes, including those ending at a virtual depot or fiddler yard, will not have a "Next Route".

This should work, in theory, if routes for more than one junction are placed within the same available list on a single track contact, thus cascading past multiple junctions. However I've not tested this on an actual layout, only on a test-bed.

I hope someone finds this useful.

Cheers.

Simon

 

[Goetz]

Hello Simon,

vor 13 Minuten schrieb simonjackson1964:

it is normal for the signals on the main line to default to "Clear"

In Germany, two different systems are in use for protecting block sections.

1. self block - always clear
2. central block - clear only upon request

vor 13 Minuten schrieb simonjackson1964:

But what about junctions?

They are always protected by red signals.

The "default to clear" that you observed is for block sections only.
Block sections don't diverge nor merge. Ever!

Greets
Goetz

[simonjackson1964]

1 minute ago, Goetz said:

They are always protected by red signals.

Except when a train is approaching the junction...! "Always" implies that the signal will never be set to green, which of course would not work!

5 minutes ago, Goetz said:

• self block - always clear
• central block - clear only upon request

I'm talking about the self-block, from a modern layout perspective, but also "Central bock" from the perspective of hand pulled semaphore signals when every block section had it's own signal box, and bell codes were used to pass messages from one signal box to the next. If box A sends "Express entering block" to box B, Box B will want to send "Clear for Express" to box C, and as soon as he gets the acknowledgement, will clear the signal, and get the token ready for the fireman on the express to grab in passing, thus blocking the line.

I tried doing it the opposite way to the above and having the route reselect itself as soon as it was released. It doesn't work anything like as well as the simple cascade system.

The track contact to set the route at the facing junction can be as close to that junction as you want, or it can set multiple junctions, but I can't guarantee that won't cause conflicts if there are trailing junctions in between.

20 minutes ago, Goetz said:

Block sections don't diverge nor merge. Ever!

True. However, for the route system on V7 to work, the route must start on the other side of the junction to the block it equates to. Otherwise the route will not set the junction, nor the signal protecting the junction.

Whether the sections of track between the signals are separate routes or not, the route must start at the signal before the junction in order to correctly protect the junction where the actual block starts is not really relevant to a virtual model railway. On the trailing junction (right to left) each route will select the next one and cascade through, unless the junction is already blocked for that route (and using a diamond crossing with track switches added ensures this works). On the facing junction, a track contact in the preceding block will attempt to activate the route the train requests.. If activated, that route will then cascade to the next facing junction, or next blocked section.

Whether the block entry signals after the junction are the starts of their own Routes or included in the routes that lead to them is not important from the perspective of the model as it will work either way However, you would never stop a train on the junction, you would hold it at the junction signal, so those block starter signals should be included in the  route that starts at the junction signal.

Cheers

Simon

[Goetz]

vor 4 Stunden schrieb simonjackson1964:

"Always" implies

oh please, Simon ... in context it should be quite clear what I was saying, don't you agree?   
Especially when you consider my "protected by".

And to my knowledge, self and central block are not determined by old / modern signals.

 

vor 4 Stunden schrieb simonjackson1964:

for the route system on V7 to work, the route must start on the other side of the junction

Of course it does. But such junction is alway protected from all sides by red signals, until one route is specifically requested and granted for one train.
It would be silly to have any of the signals set to "green" per default, because you have four different paths through that junction. You won't know which one is required until one train requests one specific route. 

 

vor 4 Stunden schrieb simonjackson1964:

I tried ... having the route reselect itself as soon as it was released. It doesn't work anything like as well

It won't when you use it in inappropriate places.

 

vor 4 Stunden schrieb simonjackson1964:

where the actual block starts is not really relevant to a virtual model railway.

Oh yes, it is!
You want the same protection to guarantee safe passage as a real world network needs.
Makes sense that the same rules apply. Because they serve that very purpose that you're after.

[simonjackson1964]

3 hours ago, Goetz said:

oh please, Simon ... in context it should be quite clear what I was saying, don't you agree?   
Especially when you consider my "protected by".

Yep, I was being obtuse, because you seemed to have missed my point.

I know that junctions are always signal protected. The question was rhetorical, or rather, a self-ask in response to this:

9 hours ago, simonjackson1964 said:

I have tested this and it works perfectly on a straight track between two depots and on a continuous circuit.

In other words it doesn't work with junctions, so how do we make it work with junctions?

Your comment was missing the point.

3 hours ago, Goetz said:

And to my knowledge, self and central block are not determined by old / modern signals.

I never said they were. I said that I am considering self block from a modern perspective and central block from an older perspective. That neither excludes nor includes Old Self block, nor modern Centre block. The system I have devised will work just fine with KS, 69 and semaphore signals. It will need tweaking to work with KS multiblock, but it will need tweaking to include advance signals on either of the other systems. I haven't got as far as them yet.

3 hours ago, Goetz said:

Of course it does. But such junction is alway protected from all sides by red signals, until one route is specifically requested and granted for one train.
It would be silly to have any of the signals set to "green" per default, because you have four different paths through that junction. You won't know which one is required until one train requests one specific route. 

You are answering a question I have not asked. Allow me to ask you one:

When is a train allowed to request a route at a junction? 10m away? 100m? 1km? 10 km? What, to you is a reasonable distance between the train and the junction at which the junction should be set for that train's approach?

8 hours ago, simonjackson1964 said:

The track contact to set the route at the facing junction can be as close to that junction as you want

The point is that at some point in time the signalman, and/or the Automatic Train Protection System is/are going to notice that a train is approaching a junction. And either the computer system will flip some relays, or a human in a signal box or control centre will flip switches, press buttons and/or pull levers, thus changing the points and the signals. Where this happens in real life is down to the allowed track speed, the positioning of the track contacts and the alertness of the person pulling the levers. As I already said, back in the days of levers, wires, bell-codes, metal tokens and semaphore signals, it took time to get everything ready (I did a spell working a signal box on a preserved line!), so if there is an express coming through you would want to get those points changed, level crossing barriers down and signals set as quickly a possible. Of course for a stopping service that wasn't strictly necessary.

But the think is, on a model, it is up to you, the modeller, where to put your track contact.

4 hours ago, Goetz said:

It won't when you use it in inappropriate places.

First of all, how do you know that I was using it in inappropriate places? Second of all, this is why I looked for and found what I consider to be a better and easier method.

4 hours ago, Goetz said:

Oh yes, it is!
You want the same protection to guarantee safe passage as a real world network needs.
Makes sense that the same rules apply. Because they serve that very purpose that you're after.

In that case, I respectfully request that all the diamond crossings in the catalogue have switches added to them, in order to avoid this highly unrealistic situation:

However, if you look at what I actually said rather than what you think I said, and put it back in the original context:

9 hours ago, simonjackson1964 said:

Whether the sections of track between the signals are separate routes or not, the route must start at the signal before the junction in order to correctly protect the junction where the actual block starts is not really relevant to a virtual model railway. On the trailing junction (right to left) each route will select the next one and cascade through, unless the junction is already blocked for that route (and using a diamond crossing with track switches added ensures this works). On the facing junction, a track contact in the preceding block will attempt to activate the route the train requests

Does the block start at the signal in front of the junction? Or at the signal after the junction? Does the signal after the junction even exist? The signal in front of the junction protects the junction. It goes green when requested by an approaching train at a distance determined by the location of the track contact. Provided the diamond crossing has switch positions added, then selecting the route from bottom left to top right will block that route, the route left to right along the bottom and the route right to left along the bottom. It will set the junction signal bottom left to green set the lower point to curved, the diamond crossing to "angled" and that's it.

What I'm saying is that the same route might as well include the block starter signal on the upper right exit track as well, because you are never going to set the one without the other. If a train cannot enter that block, it should not be allowed to enter the junction.

 

[Goetz]

Hello Simon,
I'm sorry that I misunderstood so much of what you wrote.

vor 7 Stunden schrieb simonjackson1964:

In other words it doesn't work with junctions

This sounded to me like "a self block method doesn't work with junctions".
Which led to my misunderstandings. I didn't pay propper attention, it seems.

 

vor 7 Stunden schrieb simonjackson1964:

When is a train allowed to request a route at a junction?

Probably when it enters the previous block. Or when it leaves the station, in case there is no extra block inbetween.
From this moment onwards it is certain that the train will want to pass the junction next. 

 

vor 7 Stunden schrieb simonjackson1964:

how do you know that I was using it in inappropriate places?

I was under the wrong impression that you want to use a self block method at the junction.

 

vor 7 Stunden schrieb simonjackson1964:

I respectfully request that all the diamond crossings in the catalogue have switches added to them

Agreed. They are not fully protected.
Your train with the yellow tankers must have reached the end of his route section, releasing his route.
The route was its only protection. The vehicles on the crossing are not recognised as obstacles when they should be.

 

vor 7 Stunden schrieb simonjackson1964:

Does the signal after the junction even exist?

No, there is no need for a signal at that spot.
The next signal would be a block distance away. Or where the next hazard requires a signal.
 

Your tanker should not release the route before it has cleared the junction.
If the tanker train is longer than the distance to the next signal, you may want to set a route that ends at another signal further down the line.

 

Kind regards
Goetz

Bearbeitet 1. Oktober 2022 von Goetz

[neuLich]

vor einer Stunde schrieb Goetz:

The route was its only protection. The vehicles on the crossing are not recognised as obstacles when they should be.

Hallo

Vielleicht überrascht uns ja V8 mit der innovativen Lösung das Weichen, Drehscheiben ausgenommen, grundsätzlich nur schalten können wenn kein Fahrzeug auf ihnen drauf steht. Soweit ich die Fahrstrassen verstehe können sie blockierte Weichen (weil in Benutzung) nicht schalten, oder doch?

Perhaps V8 will surprise us with the innovative solution that switches, with the exception of turntables, can only be switched when there is no vehicle on them. As far as I understand the routes, they cannot switch blocked points (because they are in use), can they?

Bis neuLich

[Goetz]

Korrekt @neuLich,
es wäre besser, wenn alle im Objekt enthaltenen Gleise auf "besetzt" geprüft würden.
Nur so lassen sich alle Konfliktfälle sicher ausschließen.

Viele Grüße
Götz

[simonjackson1964]

The solution is simple: Edit the diamond crossing to add switch positions to the two track routes. Then the Routes (capital R to distinguish them from the routes contained within the track section) will select the correct route through the crossing, disabling the other one.

At present,the default for a diamond crossing is that both routes through it are always active, meaning that bot can be selected at the same time. Adding switch positions prevents this.