Brummfondel's path rule: MX junctions

[pwjohnson]

Does anyone understand exactly how brummfondel's path rule MX junctions work? Here is the example he gives:

A --J1---J2-- B
      \ /
       X
      / \
C --J3---J4-- D

Two parallel tracks with a crossover in each direction, with a crossing X in the middle. He uses one of the real junctions (J2) as the MX junction, which has to be added to the path A-D.

But (as a theoretical example) could one instead have an entirely separate junction JX (on invisible track somewhere that no train ever goes, although it does have to be connected to the network) designated as the MX junction for that crossing, so that both paths A-D and C-B have to specify JX as an MX junction? I've tried this and found (I think!) that it doesn't work. Brummfondel states "every junction can only be locked by one path", which while it must be literally true, could be misinterpreted to suggest that the example ought to work. I think there's more to it.

When you specify an MX junction, you don't have to say anything about what direction you want it set to.
My feeling is that what actually happens is that the MX junction is set to a direction other than the default for that junction. If two or more paths each designate that junction as an MX junction there is no conflict, because each is trying to set it to non-default, and this is why my theoretical example doesn't work.

It would not prevent brummfondel's example from working, however.

What I've actually got is a double track from A-B and another double track from C-D, with double crossovers (i.e. each line in the diagram above is doubled), so that there are actually 8 crossings: 4 in the middle, and another 4 at the "corners". I had thought that I could protect the crossings with 8 invisible junctions, but if my assumption above is correct I'm going to need about double that! This is going to be horribly messy, so before I embark on it I'd like to be fairly sure that it will work.

I'd be very grateful to hear from anyone who's been down this path (sorry) before and has some thoughts on it.

Peter

 

[trev999]

Hi Peter - MX means Mutually Exclusive.

Junction X does not exist. J2 is specified as the MX for path A-D. When path A-D is selected J2 is set 'Right' which prevents a train from traversing the C-B path and also prevents a train from travelling from B to A since J1 is set against it.

The MX junction for C-B path would be either J1 or J4, either of which would be set 'Left'.

Hope this clears things up. As for your 8-crossing problem, I haven't thought too much about it. If you can try to include a track layout maybe we can help more.

Cheers - Trevor

 

[pwjohnson]

Hi Trevor - nice to hear from you again.

I realise that there is no junction X in brummfondel's example - my junction X was a theoretical example. I'll try to draw what I meant below. Sorry, I should have done this in my previous post.

But back to brummfondel's example: what I originally thought he meant when he said that J2 was locked was that no other path could access it at all, but now I don't believe that that's the case. It's true that no other path can *change* it, but if it happens to be set as the other path wants then no problem. You say that J2 is set 'Right'. This must be true, but why? In the path definition you say it's an MX junction, but there's no place to say whether it should be set to right rather than left. All I can think (not certain) is that it gets set to right because the default position is left, though brummfondel doesn't say this.


Here's a diagram for my "theoretical example":

                  /
               JX/----
                /
A --J1---J2---IJ---- B
       \ / 
        X 
      /  \ 
C --J3---J4-- D

IJ is an invisible junction which is always set 'right'. Everything north of it is invisible. JX is used as the MX junction for both the A-D path and the C-B path. If it were the case that either of these paths locked JX so that the other path could not access it, then this example would work. But I don't believe it does work, and the reason is that both paths will cause JX to be set to the same (non-default?) position, and so will not conflict.

My actual problem is as brummfondel's example, but with every path doubled:

-------J-----------J------------------------
        \         /
----J----X-------X----J--------------------
     \    \     /    /
      \    \   /    /
       \    \ /    /
        \    X    / 
         \  / \  /
          X    X
          /\   / \
         /   X    \
        /    /\    \   
       /    /  \    \
      /    /    \    \
-----J----X------X----J----------
         /         \ 
--------J-----------J-----------

Hope this is intelligible. J represents a simple junction, and X a simple crossing.

I plan to do some more testing, but won't be able to for a few days (family visiting!). Meanwhile, any more thoughts would be welcome...

Thanks, Peter

 

[cgwright]

Does anyone understand exactly how brummfondel's path rule MX junctions work? Here is the example he gives:

A --J1---J2-- B
      \ /
       X
      / \
C --J3---J4-- D

I'd be very grateful to hear from anyone who's been down this path (sorry) before and has some thoughts on it.

Peter

Hello Peter

The way it works is more simple than you think - or at least, than I think you think!

I've used the Path Rule, and it is very useful for overcoming crashes at junctions.

Essentially, the Path lists a series of junctions that must be in the specified direction for the signal to clear. To take the example, if you were setting a route from A to B, you would need J1 left (straight) and J2 right (straight). This would automatically prevent any routes from C or D from conflicting, since they would require one or other of J1 and J2 to be reversed (diverging). Once a set of points (switch) has been taken control of, it is locked as far as other trains are concerned, so J1 and J2 cannot be changed until the train from A has passed and released the route.

Now, the MX thing gets around the fact that Trainz has no knowledge about overlapping tracks, so the "X" crossing is simply two separate bits of track, so the signalling system *would* allow a train to go from A to D at the same time as another was signalled from C to B - a recipe for a mixup.

So if you are setting up a route from A to D, then you would require J1 right (diverging) and J4 right (diverging), but you would also specify the MX junction J2 right (straight). Now, J2 is locked, so if a train appears at C wanting to get to B it can't switch J2. This means that the route it wants will be locked until the first train has passed. Imagine the second train is standing at signal C, it can change J3 to left, but can't switch J2, so the tracks ahead of the signal will have an open end at J2. If you hover the mouse cursor over signal C, it will say "track ahead is unsignalled" - that is because the tracks are open ended.

Once the first train clears the crossing, the second train can switch J2, and it's signal at C will turn green.

The same thing would apply to a train arriving at B wanting to go to anywhere. Because J1 is locked diverging, and J2 is locked straight, the route is forced to be open-ended, so again signal B won't clear.

You could equally specify J3 as the MX junction - the effect is exactly the same.

My problem was with "double junctions". These were extremely common is steam-era British practice, and can experience the same effect. Here is a picture...

A  --------J1-----------------------  B
                 \
C  ----J2----X----------------------  D
           \       \
            \       \
             E       F

So the potential conflict is when a train from A wants to go to F. All that is necessary to specify J1 as right (diverging) and J2 right as the MX. This prevents the conflicting route from D to C from clearing, as J2 is locked in the diverging direction, but it doesn't stop a non-conflicting movement from E to C since J2 is in the right position. I have assumed British directions (trains travel on lefthand track).

Hope this helps

Chris

 

[pwjohnson]

Hi Chris,

Thank you for your reply - I've only just noticed it. I've been corresponding on this with Trevor (trev999) by email, and I'd omitted to check the forum. Very remiss of me; I'm very sorry.

I understand what you're saying, except for

you would also specify the MX junction J2 right (straight)

In particular, the "right (straight)" bit. As far as I can see, there is nowhere in the definition that you can specify the direction of the MX junction.

When I started this thread, the central question I was looking for an answer to was this:

When brummfondel says "the junction is locked", does he mean
1. No other path can be set which references that junction in any way, or
2. No other path can be set which wants that junction set in a different direction.

This question applies to any junction, but clearly my interest is for an MX junction. But for MX junctions, what controls what direction they will be set to? I've noticed that sometimes a junction referenced as an MX by a path has its direction changed when the path is set, but in other cases it does not, which seems strange!

From other tests I've done, I believe that if two paths specify the same junction as an MX, they can both be satisfied at the same time, so I don't think that 1 can be the right answer (though Trevor thinks that it is).

I'm still doing more tests. I'm trying to control slip crossings by arbitrarily designating one of the junctions of the crossing as the "control", which must either be specified explicitly by the path or, if the path does not directly need it, it is referenced as an MX junction.

Peter

 

[cgwright]

Hello Peter

Ah, yes. I've obviously been confused, because I was posting from memory! The Path Rule I am thinking about is the one by _mutton_ This is <KUID2:71155:60006:3> which does very much a similar thing to the brummfondel one, however, this doesn't have a dedicated MX entry. I think it is much simpler really, because you put a list of junctions, which can be (essentially) random, and a position that each one must be.

If I remember rightly the brummfondel one only allows you to add points (switches) as you come to them along the path, so you cannot (in the example) add J1, J4 and J3, because J3 is "off the route". The _mutton_ one just lets you add any junctions, in any order, and the path commands simply calls the specified junctions to the specified directions.

However, the _mutton_ one doesn't have the other's "path trigger" facility, so if you are using those triggers, then I don't think you can do it as easily. I do prefer the _mutton_ one though, because it seems easier to set up and use paths.

I stopped using both "path rules" because they insist on trying to control the entry signal. If they could force the signal red until the path is cleared, but then switch the signal to Auto, so it can work its own aspect, I would use them again like a shot. The problem with them forcing the signal to a particular aspect is that the wonderful animated semaphores by the SnC team are incompatible with having an aspect forced onto them. They seem to leave the signal arm horizontal (danger) but just turn the lamp green.

If you are using colour light signals, then you won't experience that problem, though you can experience another one. If you have specified that the signal goes green once the path is obtained, then it will do so, even if the line is only clear to the next signal (one block clear) - when it should be yellow, of course. The converse applies if the rule forces the signal yellow - if the line is clear two blocks then the signal should be green!

Anyway, that is why I am talking from memory, because I haven't used them for a while. Ho-hum. Well, I hope I may have helped a little.

Regards
Chris

 

[cgwright]

Hello again Peter

I have made a quick test layout. I believe I have only used assets included in TS2010, so hopefully it should load OK. The only thing you should need to download is the _mutton_ path rule.

The .CPD is at http://www.megaupload.com/?d=1K5U5AUL

You don't have to do anything, just edit the session then hit the quickdrive button. The green deltic grabs path 2, and drives off. The blue deltic waits 10 seconds, then tries to take the conflicting route, but waits at the signal unit the first loco clears its "release" trackmark.

Hope this makes it a bit clearer

Cheers
Chris

 

[trev999]

I stopped using both "path rules" because they insist on trying to control the entry signal.

Hi Chris - Another user made a modification to Brummfondel's command so that the first signal could be set to automatic. It only needed a line or two of editing. If you want the info, please send me your e-mail address so we can discuss this further.

Could you use an invisible signal ahead of the semaphore as the leading signal? That way you would not be forcing the aspect of the semaphore.

Cheers - Trevor

 

[pwjohnson]

Hi Chris,

I tried Mutton's path rule a long time ago, but decided to go with brummfondel's. I think it was over problems with the signalling (I too use the SnC semaphores), though when I sorted out these problems with brummfondel's rule, I never went back to look again at Mutton's. Your point about Mutton's rule allowing "off the route" junctions is interesting. Perhaps an off-route junction could be used as an MX junction in this way, though if more than two paths can traverse a given crossing it's going to get very messy. I'll have another look at it, and also try the test route you've done - thank you.

As Trevor says, use an invisible signal just in front of the semaphore (which can be a branch). The two have to be quite close together (say 1m between them). Specify the invisible signal as the path starter, and the semaphore as automatic. You also have to prevent trains going past the signals if they can't get the path, so I put an invisible (trailing) junction after the signals, set against the mainline by default. This keeps the signals at danger unless the path is set. This all works fine, and looks great with the branch semaphores.

Peter

 

[pwjohnson]

Hi Chris,

I tried your route, and it worked fine. (I suspect you didn't need to specify all 3 junctions on both paths - could you not have omitted junction D on path 3? Since C is set differently that should be sufficient to ensure both paths can't be set at the same time.)

However, Mutton's rule does have some serious drawbacks:
- can't queue the command;
- no junctions are released until the train has completed the path.
Nothing's perfect... (sigh).

So thanks for the suggestion, but I think I'll persevere with brummfondel's for now.

Peter

 

[cgwright]

Hello Peter

Yes, I could have omitted one of the junctions from one of the paths, but there was no cost in making the paths symmetrical, and I was just demonstrating the principle.

Not sure what you mean about queuing the commands.

As for releasing the path, well, you set when you want the path to release, I'd used a trackmark beyond the junctions to do it. Why would you want to release some of the junctions before the train has completely completed the path? Real signalmen were specifically told not to replace the signals to danger until the train has completely cleared the junction - this is because "the signal holds the road" so that no other movement can be made. You can read about the accident at Hull Paragon to learn of the consequences of putting a signal lever back too soon!

A brief description is at:
http://en.wikipedia.org/wiki/Hull_Paragon_rail_accident

But I digress. The MX junctions on the Brummfondel path command work the same way, except that you don't need to specify a junction direction. When the command checks the path, it will not clear until it has "taken ownership" of all the junctions required. As it takes ownership, it locks other paths from simultaneously taking ownership. So if the first path requires a junction for MX purposes, a conflicting path is prevented from owning the same junction.

Which was your original question, I think!

Cheers
Chris

 

[cgwright]

Hello Peter

Hi Chris,

As Trevor says, use an invisible signal just in front of the semaphore (which can be a branch). The two have to be quite close together (say 1m between them). Specify the invisible signal as the path starter, and the semaphore as automatic.

I did do some experimentation with invisible signals, but I always found that they messed up the aspect sequence - so you could get a green leading to a red. The invisible signal, of course, was displaying the yellow, but as far as looking at the thing in Driver, it just looked wrong to me!

But, with some off-thread discussion with Trev, I will likely go back to using the brummfondel rule myself...

All the best
Chris

 

[pwjohnson]

Hi Chris,

"queueing the command" is brummfondel's terminology. If the path is currently unavailable when the driver command asking for it is issued, the train (optionally) does not stop, but proceeds to the invisible signal/semaphore, where it will stop gracefully(!) if the path is still unavailable. With mutton's rule, as I understand it, the train stops abruptly if the path is unavailable when the driver command is issued.

re releasing the junction: with brummfondel, each successive junction is released as soon as the train has *completely* passed over it. So if a second train is waiting for a path which references one of the junctions of the first train's path, the second train's path can be set as soon as the first train has passed over that junction. With mutton, no junctions are released until the first train's path is complete, so the second train's path could not be set until then. The contention time is therefore reduced somewhat with brummfondel, while still (I hope!) being safe.

I see what you mean about green -> red. Of course, if you're using semaphores, you can solve that by just having a home signal (i.e. not a combination) as the last one before the invisible signal!?

Good luck with brummfondel's rule. It really is very powerful, though I'm still a bit unsure of the MX stuff in more complex scenarios.

Peter

 

[cgwright]

Hello again Peter

"queueing the command" is brummfondel's terminology. If the path is currently unavailable when the driver command asking for it is issued, the train (optionally) does not stop, but proceeds to the invisible signal/semaphore, where it will stop gracefully(!) if the path is still unavailable. With mutton's rule, as I understand it, the train stops abruptly if the path is unavailable when the driver command is issued.

re releasing the junction: with brummfondel, each successive junction is released as soon as the train has *completely* passed over it. So if a second train is waiting for a path which references one of the junctions of the first train's path, the second train's path can be set as soon as the first train has passed over that junction. With mutton, no junctions are released until the first train's path is complete, so the second train's path could not be set until then. The contention time is therefore reduced somewhat with brummfondel, while still (I hope!) being safe.

OK, I understand what you mean now by the queuing. No, the _mutton_ rule does the same thing. If you look at my test layout that you have downloaded, you will see that the second train moves up to the red signal, slows and stops there and waits for the green light. If you are in the session, you can select the driver command for select path, there is also a "manage paths" option which shows you which paths are active, whether they are blocked or clear, and which train is using it. You can also manually release a path if things get locked up by some mishap. As far as the driver's command queue is concerned, the "select path" command vanishes as soon as it is called, even if the path is blocked, allowing the driver to continue to try to drive to the next trackmark. Brommfondel's rule has both "blocking" and "non-blocking" versions, so you can do either, but the _mutton_ one is always non-blocking.

I take you point about releasing junctions one-by-one, but I reiterate my question "why would you want that?" Real railways don't work that way, a path (route) is cleared from one signal to the next, and it holds all the points (switches) between the first signal and the second. No other train is allowed onto a conflicting route until the first train has passed the further signal. British practice does not allow trains to be dodging about across junctions willy-nilly - a safe distance between trains is maintained at all times. Train timetables take account of junctions, specifically to avoid delays, but a train arriving out of course is liable to be stopped. That's just how it is.

The concept of being 'safe' is not really applicable to the virtual world, since nobody gets hurt if trains collide, however, I would want to have my trains work as the real ones they are simulating would, so (personally) I prefer the _mutton_ method!

But we are all gods in our virtual worlds, so we can do whatever makes us happy. It is the diversity of people's creations is what makes it fun, but it is good to have help in using the tools to make it all happen

Regards
Chris

 

[pwjohnson]

Hi Chris,

My information on mutton's rule being blocking came from a forum post of a year or more ago. Clearly it's not right, so my apologies to you (and to M Mutton if he's listening). Could it be that it's changed? I had to download a new version of the rule (level 3) to run your session. Anyway, sorry!

The 'manage paths' option sounds extremely useful - I wish brummfondel's rule had such a thing. It would make checking what's gone wrong much easier.

As for releasing the junctions, I just like to see lots of trains doing 'stuff' at the same time, so value the reduction in contention. OK, maybe it's not so prototypical, but I can live with that. I'm much more concerned about other aspects of prototypical behaviour (animated junctions are a must). As you say, we're all gods in our own little world!

Peter

 

[REFJR2]

I am sorry, but what is the kuid's (item names) that yall are referring to ?

Because I have been reading all of your posts and whatever you
are referring to sounds interesting (ie something I would like to download
from the DLS if I had the KUID's for them) thank you for your help.

- REFJR2

 

[pwjohnson]

Hi REFJR2,

For information on brummfondel's (aka Jurgen Schmitz) path rule, take a look at

http://www.js-home.org/trainz/index.php

and click on Path Control. If you want to try it out, in CMP search set "Author" and "brummfondel" and you will see all of his stuff. The ones you need to try his path control are

Path Control Library <kuid2:192081:51:3>
PathControl setpath <kuid2:192081:6:2>
jsTRF-Path Control <kuid2:192081:16:2>

You'll need more things if you want to use his trigger option, but it's described on his website. I should stick with the basic stuff first. There are also a number of forum threads to look at; search on brummfondel.

The kuid of Mutton's rule is given in an earlier post by Chris Wright: it's <KUID2:71155:60006:3>. The description of his rule is at

http://www.mutton.de/trainz/pathrule/

BTW, his Author id is _mutton_

Peter

 

[cgwright]

Hi Chris,

As for releasing the junctions, I just like to see lots of trains doing 'stuff' at the same time, so value the reduction in contention. OK, maybe it's not so prototypical, but I can live with that. I'm much more concerned about other aspects of prototypical behaviour (animated junctions are a must). As you say, we're all gods in our own little world!

Peter

I think then that we can agree that we all want different things from our pastime - there is no right or wrong answer. I am going to have another look at the various "Path" things again, as I said, I stopped using them, but it looks like I could be missing out!

I definitely agree about animated junctions - I use Andi06's JK turnouts.

All the best
Chris

 

[pwjohnson]

Following Trevor's advice, I've converted my double crossover to a single crossover, so that there is now only one central crossing, and 4 single-slip crossings at the "corners". There's 1 invisible junction on one of the tracks leading to the central crossing, which is used to protect that crossing - any path crossing the crossing references this junction either normally or as an MX junction. Each slip crossing is protected by any path using it quoting one of the junctions either normally or as an MX. There are also 4 other invisible junctions, one on each of the straight-through paths, to ensure the starter signal is red when a path is not set (I use semaphores and invisible signals).

I've now run this for over an hour, with trains arriving on average every minute. Nothing has gone wrong, so I'm pretty confident that it's OK now.

I think I can draw the following tentative conclusions. I want to emphasise that I haven't proved these beyond all doubt, it's just that they are consistent with what's happened at various times.

1. I think the answer to my question is indeed 1, as Trevor thought, i.e. when brummfondel says "the junction is locked", he means no other path can be set which references that junction in any way.

2. Except that.... I think an MX junction can only protect against that junction being specified normally, not as an MX in another path. For example, if
- path A references junction xyz normally,
- path B references junction xyz as an MX junction, and
- path C references junction xyz as an MX junction, then
path A cannot be set at the same time as either path B or path C, but path B CAN be set at the same time as path C.

3. Each time I've saved a session, when I've come to restore it later the paths have gone wrong. For example the default direction of some junctions may have changed, with the result that the starter signal is clear even though the path is unavailable, so the AI train goes through - the wrong way. This has now happened to me 3 times, when the identical session, not saved and restored, has worked OK. I don't know whether this only happens with paths that use MX junctions; but this may well be the case, since I'd guess lots of people have used brummfondel's paths, and I've never seen this reported before.

My thanks to Trevor, Chris and Brian for their useful comments.

Peter