Rail3D*


 
System.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name: length at System.String.Substring(Int32 startIndex, Int32 length) at R3DWeb.sParseContent(String sPageID, String sText) at cms.Page_Load(Object sender, EventArgs e)

Flashing Junction Aspects


 


In uk colour-light practise, junction routes are usually indicated by a “position junction indicator” or “feather”, a group of 5 lights that indicate the direction the driver will take. There are up to 6 feather positions available - 1 (diagonal left up), 2 (horizontal left), 3 (diagonal left down), and 4–6 on the right hand side from top to bottom. In complicated, low speed, areas, “matrix” or “theatre” route indicators are also used, displaying a letter or number for the route - see [[wiki/Projects/MatrixRouteIndicatorDisplay]].

However, both of these methods only give the driver the information once the signal comes into view - and if it’s a 40mph junction from a 100mph line, it certainly isn’t enough warning! The simplest solution is to hold the junction signal at danger until the train is confirmed to have slowed down sufficiently, or to hold the signal at caution in 4-aspect territory (so the driver receives a yy aspect first) - features known as “approach release”.

These solutions are also somewhat flawed - a driver may “expect” an approach release signal to clear (“because it always does!”), and then be taken by surprise when it doesn’t, potentially too late. For junctions where the signal stays at caution, there is no confirmation as to whether the signal is staying at yellow because it’s a junction indication, or because the next signal is at danger, and so the driver must crawl along until he sees it. Both methods can also cause trains to run slower than necessary - if the junction route is 60mph from a 100mph route, the driver may well have slowed below 60mph by the time he sees the junction aspect.

 

The flashing yellow aspects

The solution invented were the “flashing yellow” aspects. These show a flashing Y, informing the driver that the next signal is clear but is showing a junction aspect, and to slow to the junction speed. A flashing yy aspect is provided in 4-aspect territory. This also allows the junction signal to clear to a more favourable aspect (yy or G) without the worry that the driver will suddenly accelerate past the junction speed (usually - a loco was derailed at Bletchley recently in similar circumstances!), helping to clear the junction faster.

This cab ride video shows the sequence of aspects for a train approaching Birmingham International: www.youtube.com/watch?v=_xuqSgYTWWs&feature=player_detailpage#t=252s

(The video also shows Preliminary Route Indicators, the white arrows just after the flashing signals, and the new led 2-lamp signals - more projects for the future!)

 

Implementing in Rail3D

A 3-aspect flashing indication for a simple junction would be relatively easy to implement in Rail3D - the flashing signal’s state table would be something like:

LAMP	//Red
ID 1

STATE S.X	255.0.0
STATE C.X	0.0.0
################
LAMP	//Yellow
ID 2

STATE S.X	0.0.0
STATE C.X	255.255.0
STATE X.J	255.255.0 FLASH
STATE X.J2	255.255.0 FLASH
STATE L.X	0.0.0
################
LAMP	//Green
ID 3

STATE S.X	0.0.0
STATE C.X	0.0.0
STATE L.X	0.255.0

(Note that I haven’t tested this at all!)

For 4-aspect signals, though, scripts are needed - the yy flashing aspect requires the signal after the next one to be J, which can’t be checked using the normal state table. In addition, the whole thing gets more complicated if there are multiple junction routes (some of which may be approach released) and route tags. The two scripts below handle all of this, and check that:

  • The yyflash, yflash and junction signals are all cleared - otherwise there’s an intermediate train, and you don’t know which route the second train will take, or the junction signal is at danger.
  • The junction signal is actually showing a junction aspect (quite important!).

In theory, the yflash signal shouldn’t flash if the yyflash aspect was not seen by the driver before (i.e. the criteria were not satisfied when the train passed the first signal). However, I can’t think of a good way to do this - I don’t think there’s any way for one script to interact with another? Otherwise I could check a persistent variable in one script (“did the yyflash signal flash?”) and respond accordingly.

The Flashing Y script could easily be edited to apply to any 3-aspect signal as well (in fact, as long as there’s no Lamp id 4, it should run out of the box without any adverse effects)

 

Example Background

The example scripts below are based on Birmingham International. This has 5 platforms - 1 and 2 are on a loop on the Down side, 3 and 4 are the Down/Up mains respectively, and 5 is on a loop on the Up side. In the down direction, a “through” route goes via platform 3, whilst any other route has a 40mph speed limit over the crossovers/pointwork. The setup I have used revolves around route tags, though the script would work perfectly fine with junctionsig.IsJct() and so on in simpler areas. “ns 99″ is the signal at the junction (the one with the feathers). I’ve applied lamp ids to the 4-aspect signal, and they are hopefully self-explanatory! I’ve left the debug lines in, but they only give feedback when testing a setup and can be deleted.

 

Flashing yy signal

//Flashing YY for UK4

OnSetLamps()
{
    signal junctionsig=Document.GetSigByID("NS 99");

    Signal.UnsetLamp(1);
    Signal.UnsetLamp(2);
    Signal.UnsetLamp(3);
    Signal.UnsetLamp(4);

    //If junction is at danger
    if(junctionsig.IsOn())
    {
        debug.printL("Signal is on");
        return;
    }

    //If this signal is at danger
    if(Signal.IsOn())
    {
        debug.printL("Signal is on");
        return;
    }

    //If next signal is at danger
    if(Signal.IsCau())
    {
        debug.printL("Signal is on");
        return;
    }

    string tag=junctionsig.GetRouteLabel();
    debug.printL(tag);

    //If plain route is set
    if(tag=="P3")
    {
        debug.printL("Signal is non-J");
        return;
    }


    //Junction routes
    if(tag=="P1")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,255,255,0,1);	//Yellow 2
    }

    if(tag=="P2")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,255,255,0,1);	//Yellow 2
    }

    if(tag=="P4")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,255,255,0,1);	//Yellow 2
    }

    if(tag=="P5")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,255,255,0,1);	//Yellow 2
    }
}
 

Flashing Y signal

//Flashing Y for UK4

OnSetLamps()
{
    signal junctionsig=Document.GetSigByID("NS 99");

    Signal.UnsetLamp(1);
    Signal.UnsetLamp(2);
    Signal.UnsetLamp(3);
    Signal.UnsetLamp(4);

    //If junction is at danger
    if(junctionsig.IsOn())
    {
        debug.printL("Signal is on");
        return;
    }

    //If this signal is at danger
    if(Signal.IsOn())
    {
        debug.printL("Signal is on");
        return;
    }

    string tag=junctionsig.GetRouteLabel();
    debug.printL(tag);

    //If plain route is set
    if(tag=="P3")
    {
        debug.printL("Signal is non-J");
        return;
    }


    //Junction routes
    if(tag=="P1")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,0,0,0,0);	//Yellow 2	
    }

    if(tag=="P2")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,0,0,0,0);	//Yellow 2
    }

    if(tag=="P4")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,0,0,0,0);	//Yellow 2
    }

    if(tag=="P5")
    {
        Signal.SetLamp(1,0,0,0,0);	//Red
        Signal.SetLamp(2,255,255,0,1);	//Yellow 1
        Signal.SetLamp(3,0,0,0,0);	//Green
        Signal.SetLamp(4,0,0,0,0);	//Yellow 2
    }
}
 

Afterthoughts

It might be possible to make the script generic by using NextSig() twice for the yy signal (and once for the Y), and then you could apply it as a model script to something like “uk4_FlashingYY.sig”. That would require that there’s no alternate routes that can be taken before the junction signal, however - otherwise you could be trying to give Flashing yy for the wrong junction!


 


MRG 28/06/2013 07:44:37