Upcoming Games

No games to display

Full list
Add a game

Upcoming Events

No events to display

2v10: Ding-ding, and away!?

You are here: Home > Forum > Simulations > Released > Westbury > 2v10: Ding-ding, and away!?

Page 1 of 1

2v10: Ding-ding, and away!? 29/05/2014 at 01:57 #61040
eeldump
Avatar
19 posts
In the attached simulation file, try to set the route out for 2V10...you'll get a "Subroute locked in opposite direction" interlocking error, then the train will depart on its own, without the route cleared for it, and with the signals still showing red! :doh
[attachment=2492]wes-spad.ssg[/attachment]

Post has attachments. Log in to view them.
Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 06:51 #61041
BarryM
Avatar
2158 posts
" said:
In the attached simulation file, try to set the route out for 2V10...you'll get a "Subroute locked in opposite direction" interlocking error, then the train will depart on its own, without the route cleared for it, and with the signals still showing red! :doh
[attachment=2492]wes-spad.ssg[/attachment]

It appears that the joining of 2M79 with 2V10 at the Up end of P2 has not cleared the locking of the subroute. The problem will be reported.
To fix the problem, using F2, reverse 2V10 and request a shunt forward.
The train will move in the down direction, clearing the subroute, stop and reverses and you then get a TRTS.
Barry

Barry, Sydney, New South Wales, Australia
Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 08:39 #61042
Steamer
Avatar
3913 posts
It looks like 2V10 stopped too far down the platform, so when 2M79 entered it stopped overhanging signal 311. If you turn Track Circuit breaks on (F3> Display) you'll notice that the TC ahead of the signal is occupied. The signal can't be cleared because the track circuit in front of it is occupied, which still has the route into the platform set over it (hence 'Subroute locked in opposite direction'). To fix, tell 2V10 to reverse direction (using the F2 menu) and it will move completely within the platform, allowing you to set the route from 311.
"Don't stress/ relax/ let life roll off your backs./ Except for death and paying taxes/ everything in life.../ is only for now." (Avenue Q)
Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 22:35 #61104
BarryM
Avatar
2158 posts
" said:
" said:
In the attached simulation file, try to set the route out for 2V10...you'll get a "Subroute locked in opposite direction" interlocking error, then the train will depart on its own, without the route cleared for it, and with the signals still showing red! :doh
[attachment=2492]wes-spad.ssg[/attachment]

It appears that the joining of 2M79 with 2V10 at the Up end of P2 has not cleared the locking of the subroute. The problem will be reported.
To fix the problem, using F2, reverse 2V10 and request a shunt forward.
The train will move in the down direction, clearing the subroute, stop and reverses and you then get a TRTS.
Barry

Eeldump, further to my 1st reply, it appears that you created the problem by allowing 2V10 to enter P2 ahead of 2M79. You need to check the times that joining trains arrive. Allowing 2V10 to arrive first, has not left enough room for 2M79 to clear the overlap at signal 311.
All part of a learning curve!
Barry

Barry, Sydney, New South Wales, Australia
Last edited: 29/05/2014 at 22:37 by BarryM
Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 23:04 #61106
Finger
Avatar
220 posts
" said:
" said:
" said:
In the attached simulation file, try to set the route out for 2V10...you'll get a "Subroute locked in opposite direction" interlocking error, then the train will depart on its own, without the route cleared for it, and with the signals still showing red! :doh
[attachment=2492]wes-spad.ssg[/attachment]

It appears that the joining of 2M79 with 2V10 at the Up end of P2 has not cleared the locking of the subroute. The problem will be reported.
To fix the problem, using F2, reverse 2V10 and request a shunt forward.
The train will move in the down direction, clearing the subroute, stop and reverses and you then get a TRTS.
Barry

Eeldump, further to my 1st reply, it appears that you created the problem by allowing 2V10 to enter P2 ahead of 2M79. You need to check the times that joining trains arrive. Allowing 2V10 to arrive first, has not left enough room for 2M79 to clear the overlap at signal 311.
All part of a learning curve!

Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.

Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 23:08 #61107
postal
Avatar
5189 posts
" said:
Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.
Afraid it does matter. If the TTs of the second joining train include any stopping position instructions like F, N, FX or NX and it arrives first, that could well cause the first joining train arriving out of sequence to lie foul.

“In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe
Log in to reply
The following user said thank you: BarryM
2v10: Ding-ding, and away!? 29/05/2014 at 23:18 #61109
Finger
Avatar
220 posts
" said:
" said:
Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.
Afraid it does matter. If the TTs of the second joining train include any stopping position instructions like F, N, FX or NX and it arrives first, that could well cause the first joining train arriving out of sequence to lie foul.

That's only true with FX and NX - and none of it is used with the two trains in question. Also there could be problems with multiple joins/divides - but this movement is not a multiple join.

Last edited: 29/05/2014 at 23:19 by Finger
Log in to reply
2v10: Ding-ding, and away!? 29/05/2014 at 23:43 #61110
postal
Avatar
5189 posts
" said:
" said:
" said:
Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.
Afraid it does matter. If the TTs of the second joining train include any stopping position instructions like F, N, FX or NX and it arrives first, that could well cause the first joining train arriving out of sequence to lie foul.

That's only true with FX and NX - and none of it is used with the two trains in question. Also there could be problems with multiple joins/divides - but this movement is not a multiple join.
If you had included all of those provisos around your original blanket statement, then I wouldn't have made my posting.

“In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe
Log in to reply
2v10: Ding-ding, and away!? 30/05/2014 at 00:35 #61115
BarryM
Avatar
2158 posts
[attachment=2498]wes-spad00703.ssg[/attachment]
" said:
" said:
" said:
Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.
Afraid it does matter. If the TTs of the second joining train include any stopping position instructions like F, N, FX or NX and it arrives first, that could well cause the first joining train arriving out of sequence to lie foul.

That's only true with FX and NX - and none of it is used with the two trains in question. Also there could be problems with multiple joins/divides - but this movement is not a multiple join.

But it does. Here is a save. 2M79 needs to be in the platform before 2V10 otherwise they will not join.
Barry

Post has attachments. Log in to view them.
Barry, Sydney, New South Wales, Australia
Last edited: 30/05/2014 at 00:37 by BarryM
Log in to reply
2v10: Ding-ding, and away!? 30/05/2014 at 00:35 #61116
BarryM
Avatar
2158 posts
" said:
" said:
" said:
Well, in Simsig, everywhere else you do it, it will just correctly reserve space on the other end of the platform for the join to happen - so it shouldn't matter which train you allow in first.
Afraid it does matter. If the TTs of the second joining train include any stopping position instructions like F, N, FX or NX and it arrives first, that could well cause the first joining train arriving out of sequence to lie foul.

That's only true with FX and NX - and none of it is used with the two trains in question. Also there could be problems with multiple joins/divides - but this movement is not a multiple join.

But it does. Here is a save. 2M79 needs to be in the platform before 2V10 otherwise they will not join.
Barry
[attachment=2497]wes-spad00703.ssg[/attachment]

Post has attachments. Log in to view them.
Barry, Sydney, New South Wales, Australia
Log in to reply
2v10: Ding-ding, and away!? 31/05/2014 at 18:53 #61178
Stephen Fulcher
Avatar
2007 posts
The problem with the subroute locked has nothing to do with orders of joins or anything similar.

It is caused simply by one or other part (doesn't matter which) of 2V10 being stood on BK track circuit, which is in advance of signal W311. This means that the opposing route locking for the arriving train has not being released. You cannot see this directly on the panel as it is the last track circuit in the route which is locked so there are no white lights (the track circuit occupied overrides the route lights), but until that track circuit clears the route remains locked. Sometimes you can see this in a real interlocking as for a split second after the clearance of the track circuit the route lights will briefly light again before going out.

As such, there is no bug with the simulation for Peter to need to fix. As the train goes on its merry way almost as soon as I unpause the sim I am presuming that you have had a call from the driver requesting authority to proceed, and that you granted such authority, although you have not got the route set correctly so the driver will pull up short of the points anyway.

The issue with these two trains will occur whichever way you let them into the platform, they are both set to a standard stopping point, which as the trains arrive from opposite ends of the platform, means they are going to hang foul one end or the other whichever order you let them in. From a simulation point of view as it is a simple two-train join, it should not matter which order they arrive as they will each "see" that they are booked to join with the other at Westbury, and therefore they will join.

There is a timetable issue where the stopping points of both trains need to be adjusted to somewhere more suitable so that there is ample room for both to be accommodated in the platform whichever order they arrive. The combined length is only 91 metres so this should be possible. Postal is more of an expert in timetabling than I am, so would be able to advise which instructions to add to each train to correct this problem.

Log in to reply
The following user said thank you: BarryM
2v10: Ding-ding, and away!? 01/06/2014 at 15:02 #61220
postal
Avatar
5189 posts
" said:
Postal is more of an expert in timetabling than I am, so would be able to advise which instructions to add to each train to correct this problem.
I think you may have a higher regard for my capabilities than is justified as most of my "expertise" boils down to trial and error and a bit of playing until a solution that works appears.

In this particular case you have two trains arriving from opposite directions. If you set them both to NX stops then they will stop 100m apart and never join. If you set them both to FX then the first to arrive runs right through the platform and the second can't enter the platform to join. If you leave the first train with the default stopping position and set the second to FX to make sure it buffers up to the first, you have a problem if they arrive out of sequence as the "second" train will be at the far end of the platform blocking the "first" train.

To make sure that they meet somewhere about the middle of the platform you need to specifically tell both trains to stop just past the middle; then, whichever arrives second will run through the platform until it meets the first arrival just before it gets to halfway and the join should take place. P2 at Westbury is 203m long; if we want either train to stop of its own accord just over halfway along the platform (after say 103m.) then it needs a stopping position set of FX@100 or 100 metres short of the far end. The 100 is entered in the adjustment box in the TT editor after Far End Exact is chosen as the stopping position. Set both trains to FX@100 and the first arrives and stops 103m into the platform. The second arrives and want to travel 103m along the platform. However, the second train only gets 100m into the platform and it meets the first where it makes the join. I've just run a test with both set to FX@100 and whichever arrives first, they both fit onto the platform and make the join.

If you need to make the join towards one end of the platform rather than in the middle, you adjust one of the stopping positions upwards and the other downwards. For example to join right at the West end of P2, you would set 2M79 to say FX@50 (to allow 2V10 to get into the platform if it arrives second) and 2V10 to say FX@155 (so it gets into the platform but stops almost immediately if it arrives first).

Hope that all makes sense and is a bit of help if anyone is having any problems.

“In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe
Log in to reply
The following users said thank you: Stephen Fulcher, AndyG, BarryM
2v10: Ding-ding, and away!? 14/01/2019 at 21:51 #114771
Afterbrunel
Avatar
94 posts
I have just started using this sim and timetable. 2V10 and 2M79 join perfectly. The problem is that the combined train starts without authority, and in doing so runs wrong line (according to the lie of the points, obvs.)

I presume this was the original problem, implied by the title of the thread.

Log in to reply