In this tutorial, we will continue adding signals to the route and discuss some of the ways these can be controlled. BVE signalling is very versatile and this tutorial can in no way be considered a fully comprehensive guide to the subject. Nevertheless, sufficient detail will be included to allow implementation of basic signalling.
Additional objects used in this tutorial session may be found here:
http://vps.bvecornwall.co.uk/dennislance/DLTUTORIAL_1_8.zip
Unzip to the DLTUTORIAL_2 folder in your objects folder.
At the moment, we have a signal with a fixed stop aspect which, in combination with TPWS, controls the approach to the buffer stops and we also have a ‘calling on’ (shunt) signal at the entrance to the turn back siding. Our next job is to add signalling to the main running line.
When adding signals to a route, don’t forget that good signal sighting is essential and that sufficient distance is provided to allow all trains to brake safely to a stand when required to do so.
Time to open the route file and get coding…
Because of the short length of our route, the number of signals required is small. Despite this limitation, a number of different types can be employed.
The first signal to be added to the route is a conventional 3 aspect signal at the start of the route to control the exit from the first station. Referring to the signal types listed in the BR signals documentation referenced in the previous tutorial, we need to add the following code:
1 |
75,.sigf 3;1;-2.75;4.6,.section 0;2;4, |
Signal type 3 is a conventional 3 aspect signal with no feathers or subsidiaries. Section 0;2;4, specifies that the signal can display red, yellow or green aspects.
For simplicity, all of our signals will be mounted on a standard pole which only contains an identification plate although it is worth pointing out at this stage that signal plates, telephones and other paraphernalia are often also present on signals and for added realism should be included. Useful sources of information regarding the signs present include http://www.railsigns.co.uk and http://www.rgsonline.co.uk Signals may also be mounted on brackets or overhead gantries as required by route conditions (which include sighting and space availability).
The signal pole object has been included in the objects download for this tutorial and before use, as with all free objects, must be indexed in the ‘with structure’ part of the route:
1 |
.freeobj(40) DLTUTORIAL_2\signal_pole.csv, |
Next add the object to the route (if the x and y distances of the signal pole object are altered, those of the signal head must also be changed otherwise the head will not sit correctly on the pole):
1 |
75,.sigf 3;1;-2.75;4.6,.section 0;2;4,.freeobj 0;40;-0.5;-0.2, |
If we take a look at the route now, the signal will display a green aspect right from the start. If we wanted the signal not to show a green aspect immediately, there are a couple of options available. The first option is to make the signal change at the station departure time. Recalling from tutorial 1_2 the station command, the sixth parameter controls the aspect of signals at stations. Therefore, if we change:
1 |
0,.Ground 1,.back 0,.railtype 0;1,.sta yourname1; 09.2720;09.2805;;1;0;;;7;10;;0, |
To:
1 |
0,.Ground 1,.back 0,.railtype 0;1,.sta yourname1; 09.2720;09.2805;;1;1;;;7;10;;0, |
We should now find that the signal clears a few seconds before the departure time.
The second way which signal aspects may be controlled is to specify in the route file how far in front a preceding train is. The easiest way of doing this is to include the route.run interval command;
Route.runinterval x,
Where x is the time interval from the preceding train.
(An alternative means of varying the location of a train ahead is to use the ‘pretrain command’ – this will not be covered in this series of tutorials.)
As the (imaginary) train proceeds along the track at linespeed, signals will clear in sequence behind it in the normal way. By including this command, it is possible to catch up with the preceding train as it enters slower parts of the route. If we include a short run interval in our route as it is at the moment, delays can be expected due to the relatively long distances between signals. See what happens if the run interval is set to 200 seconds by including this code immediately before the ‘with train’ section:
1 |
Route.runinterval 200, |
The signal at the first station does not clear until about five minutes after the scheduled departure time as we now need to wait for the preceding train to clear the sections ahead. Introducing an additional signal between the first and third stations will reduce this delay.
The additional signal can be placed at the second station; at this location there is a junction where a signal is desirable both to control movements over the junction itself and also to provide an indication of which route is to be taken. Referring to the documentation provided with BR signals, we find that a three aspect signal with left hand feathers is signal type 6, so to add a signal of this type and the pole just after the second station stop, we need to add this code:
1 |
2875,.rail 1;14.13,.sigf 6;1;-2.75;4.6,.section 0;2;4,.freeobj 0;40;-0.5;-0.2, |
While reducing the delay before starting off, it is probably sensible to extend the route run interval by a minute or so to eliminate it altogether (unless you want delays!), so change the number in the previously discussed Route.runinterval 200 command, to Route.runinterval 300, or even longer if you wish to start running under a green aspect.
To overcome the ‘exceeded the speed limit of the signal warning’ which occurs when running at moderate speeds under yellow aspects, we can set more appropriate speed ‘limits’ at which these warnings are displayed by making use of the route.signal command:
Route.Signal(n) x,
Where n is the signal aspect as per previously:
Aspect Index | Meaning |
---|---|
0 | Red (Stop) |
2 | Single Yellow (Caution) |
3 | Double Yellow (Caution) |
4 | Green (Clear) |
(Don’t try and set a speed limit for a red aspect mind!)
x represents the ‘speed limit’ of the signal aspect (in kmh)
Thus, in our route file, we add this code after the Route.Gauge statement:
1 |
Route.Signal(2) 120, |
If we had higher line speeds and four aspect signalling, we might also wish to include
1 |
Route.Signal(3) 180, |
to prevent ‘exceeded the speed limit of the signal’ warnings occurring when running under double yellows.
It is also worth remembering that if we want the signal at the second station to display a stop aspect until the departure time, we can modify the .sta command in exactly the same way as was shown for the first station.
The only other signal we are going to add to the running line is a bit superfluous really, but has been included to demonstrate how to install a ‘distant’ signal. These are found on many routes signalled using semaphore replacement signals (SRS) rather than true multiple aspect signalling.
Signal type 13 is to be used for the yellow / green distant signal. This needs to be positioned (together with the signal pole) somewhere around halfway between the second and third stations:
1 |
3900,.sigf 13;1;-2.75;4.6,.section 2;2;4,.freeobj 0;40;-0.5;-0.2, |
Our last job before moving on to install AWS is to correctly position the signal at the third station and to add the signal pole object. This can be done by changing the current
1 |
5050,.sigf 11;1;-7;2.005,.section 0;2, |
To:
1 |
5050,.sigf 11;1;-2.75;4.6,.section 0;2,.freeobj 0;40;-0.5;-0.2, |
And changing the .sta command to ensure the calling on signal does not release until departure time, changing it to look like this:
1 |
4900,.sta yourname3; 09.3500;09.3600;;-1;1;;;30;30;;0, |
All of our signalling is now installed and fully functional (hopefully!!) – go for a test drive to check this before we install working AWS for the signals.
To install AWS, we need to make use of the appropriate beacon command placed 185m before the signal. For the signal at the second station, which is located at 2875m, we need to place our AWS beacon at 2690m by adding this:
1 |
2690,.Beacon 44000;1;1;0, |
Similarly, for the distant signal at 3900m, the AWS beacon is required at 3715m:
1 |
5615,.Beacon 44000;1;1;0, |
And that’s it for installing AWS – go for a test drive and make sure everything is working correctly.
The next job is to install TPWS (train protection and warning system) to prevent passing the signals at danger. There are two separate aspects to this safety system
First, a speed trap is situated some distance before the signal (typically 50-450m, depending on line speed and gradient). This acts to automatically apply the (emergency) train brakes if the approach speed is above that of the speed trap. This function of TPWS may also be used on the approach to speed restrictions, either permanent or temporary, and also at terminal approaches.
The second function of TPWS is to automatically apply the train brakes if a signal is passed at danger. We have already made use of this at the buffer stops.
Dealing with the second of these functions, we need to install TPWS beacons just before all of our signals (expect the distant at 3900m where there is never a requirement for trains to stop), using this command:
1 |
.beacon 44003;0;1;0, |
So, for the signal at the first station, we need to add this:
1 |
71,.beacon 44003;0;1;0, |
Similarly, for the signal at the second station, add this:
1 |
2871,.beacon 44003;0;1;0, |
Finally, for the signal at our third station, add this:
1 |
5046,.beacon 44003;0;1;0, |
Now, passing a signal at danger will result in an automatic brake application (to test this, reduce the route run interval and speed to ensure signals at danger are encountered or force red aspects to be displayed by changing the .section parameters).
Don’t worry about the grey squares visible in the track where the trainstops are situated – we will eliminate these and fit TPWS loops and install other associated objects in the next tutorial.
The final job for this tutorial is to add the speed traps on the approaches to signals. These will automatically apply the train brakes if a signal at danger is approached at excessive speed. The speed trap (or over speed sensor as it is also known) will be located between 50-450m in front of the signal, depending on factors such as line speed and gradient. The maximum permitted speed allowed by the speed trap will typically be 60kph (38mph), although this may can vary depending on local conditions and traffic types.
The following is an extract from GERT8030, the RGS standard which covers the requirements of TPWS systems:
The infrastructure controller, in association with train operators, shall develop and implement the rules for the positioning of OSS transmitters that optimise their safety benefits. The rules shall take account of:
a) the braking performance of trains as defined in Railway Group Standard GM/RT2045
b) the attainable speeds of trains on the approach to the signal or other location
c) the distance from the stop signal to the point of conflict at the crossing or convergence ahead
d) the gradient of the line on the approach to the signal or other location
e) the interleaving of other location OSS functions where signal OSS and TSS functions are or will be installed
f) the risk of inhibition of the vehicle TPWS self test on power up
g) the risk of unwarranted intervention during movements in the opposite direction on bi-directional or reversible lines.The provision and positioning of TPWS track sub-system is dependent upon track layout, the location of signals and the attainable speed of trains. The provision and positioning of TPWS track sub-system shall be reviewed if a change to the infrastructure or the operational use of the railway is proposed which may affect the track layout, signal location or the attainable speed of trains.
Much of this is equally applicable to BVE routes and puts the onus on the route developer to correctly set up the speed traps to prevent signals being passed at danger!
To implement the speed traps, we need to make use of another beacon command, this time
.beacon 44002;0;1;n,
where n is the speed (in kmh) above which activation will occur.
Setting up the speed traps is really a matter of trial and error but there is one very useful point to remember – if you manage to SPAD on a test drive, the speed trap is incorrectly set-up or insufficient braking distance exists between the signals.
The first speed trap we are going to add is for the signal at the second station. Here, the line speed is low (and the entry to the speed restriction will be protected by it’s own speed trap). Because of this, it is possible to place the speed trap relatively close to the signal and have a low speed setting. To position the speed trap 50m in front of the signal and set a speed limit of 10mph (=16kmh), add the following code:
1 |
2825,.beacon 44002;0;1;16, |
One potential drawback with this configuration is that an emergency brake application will be made when overrunning the correct station stop point at speeds over 10mph – something potentially injurious to passengers standing ready to disembark.
The only other signal on our route where a speed trap is required is at the third station. Here, the line speed is significantly higher so the speed trap will need to be placed at a greater distance in front of the signal to ensure trains do not pass the signal at danger.
To position the speed trap 175m in front of the signal and setting the maximum permissible speed to 38mph (=60kph), we need to add this code:
1 |
4875,.beacon 44002;0;1;60, |
These are the only speed traps we need to add to signals. To add a speed trap at the start of the 20mph restriction approaching the second station, a similar beacon command may be employed:
1 |
2375,.limit 32,.freeobj 0;21,.beacon 44004;0;1;32, |
That’s all of the signals protected with AWS and TPWS. A speed trap has also been added to the restriction approaching the second station and the buffer stops have been protected with TPWS.
In the next tutorial we will enhance the appearance of the route by adding TPWS loops and other lineside objects.