Incorrect route complaint at Carstairs UPL

You are here: Home > Forum > Simulations > Released > Motherwell > Incorrect route complaint at Carstairs UPL

Page 1 of 1

Incorrect route complaint at Carstairs UPL 21/01/2016 at 14:39 #80028
Lyn-Greenwood
Avatar
239 posts
I came across the following during a Motherwell 1984 Multiplay session earlier this week and would appreciate other users' views on what happened.

Here's the scenario:

Train 1C22 moves to Carstairs UPL prior to its 'Propel back and Join' with 1M22 in Carstairs P2. However, because 1M22 is running very late, 1C22 is showing status 'Waiting right away at Carstairs UPL', but it has to stay there until 1M22 arrives in P2.

Meanwhile, 1S01 arrives in Carstairs DPL for a loco swap, with the loco (0S01) scheduled to go to Carstairs Up Sidings via the UPL. Because 1M22 is running very late, I signalled 0S01 from the DPL to the UPL (behind 1C22) and then into the Up Sidings. I was quite surprised when the driver of 1C22 complained of an incorrect route being set. The route had been set for 0S01 which happily moved off into the Up Sidings.

Question: was the driver of 1C22 correct in complaining about the incorrect route when loco 0S01 was located between train 1C22 and the signal in question? My feeling is that he should have known that the route was set for 0S01 and not for his train, 1C22.

I'm assuming that in real life the Guard of 1C22 would see the loco that had entered the UPL (and may even have been verbally advised), so he wouldn't give the right away for the Set-back move until the loco was clear and the route correctly set into P2.

It would appear that the simulation is associating the route which was set for 0S01 (and which it took) with train 1C22, which I don't believe is correct.

I thought I'd get some views on this before I report it as an inconsistency (I don't like the word 'bug').

Log in to reply
Incorrect route complaint at Carstairs UPL 21/01/2016 at 21:28 #80036
Peter Bennet
Avatar
5355 posts
Can you quote the exact message? Also what was the TD that was in the TD berth associated with the route?

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Incorrect route complaint at Carstairs UPL 21/01/2016 at 22:05 #80037
Lyn-Greenwood
Avatar
239 posts
" said:
Can you quote the exact message? Also what was the TD that was in the TD berth associated with the route?

Peter
I'm afraid I don't have the information to hand, Peter. I was pretty busy at the time and as I wasn't hosting I wasn't in a position to save the session.

I'll set up a small test session tomorrow to see if I can replicate the scenario and will take note of the exact message, TID, etc. if I get the same behaviour. I'll also save the session just prior to the move and immediately afterwards for your perusal.

Lyn

Log in to reply
Incorrect route complaint at Carstairs UPL 21/01/2016 at 22:43 #80039
Peter Bennet
Avatar
5355 posts
OK my thought is that the message was "routed off planned path" and the TD was 1C22. That makes sense as ARS is driven by the TD so if I am correct in my assumption ARS saw the route being set compared it to what that TD was expecting and queried it.

Could be wrong but that's my best guess at the moment reading between the lines of what you said.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Incorrect route complaint at Carstairs UPL 21/01/2016 at 23:46 #80041
Andrew G
Avatar
548 posts
Online
" said:
OK my thought is that the message was "routed off planned path" and the TD was 1C22. That makes sense as ARS is driven by the TD so if I am correct in my assumption ARS saw the route being set compared it to what that TD was expecting and queried it.

Could be wrong but that's my best guess at the moment reading between the lines of what you said.

Peter
I don't think it would have been an ARS message as ARS was disabled in the session - ARS Off TORR On - was the option selected.

Hopefully Lyn can recreate.

Log in to reply
Incorrect route complaint at Carstairs UPL 22/01/2016 at 15:04 #80047
Lyn-Greenwood
Avatar
239 posts
" said:
OK my thought is that the message was "routed off planned path" and the TD was 1C22. That makes sense as ARS is driven by the TD so if I am correct in my assumption ARS saw the route being set compared it to what that TD was expecting and queried it.

Could be wrong but that's my best guess at the moment reading between the lines of what you said.

Peter
Peter,

I've put together a small test WTT that shows up the problem quite well and have attached 5 saved sessions wrapped up in a .ZIP file.

Here are the details and the F2 status of the trains:

Save01 shows 1C22 in UPL and 0S01 in DPL, both 'Waiting right-away'.
Save02 shows the two trains in UPL, both 'Waiting right-away'.
Save03 shows route set to Up Sidings for 0S01, but 1C22 also starts to move towards signal MC406!
Save04 shows 1C22 'Waiting for correct route to be set'.
Save05 shows 1C22 'Stopped at signal MC406' thus preventing the new 0S01 from getting behind MC406 in order to join 1S01 in the DPL.

However, if the departure time of 1C22 from the UPL is made much later (so it's not 'Waiting right-away'), then everything works correctly and 1C22 doesn't move when the route is set into the Up Siding for 0S01.

It looks like 1C22 isn't aware of 0S01 being at signal MC406 and when the signal clears for 0S01, 1C22 thinks it's for him.

I wonder if the problem also shows up in sims with large Terminal Stations where there could be more than one train in a platform ready to depart at the same time?

I hope the info provided is useful, Peter.

Lyn

Post has attachments. Log in to view them.
Log in to reply
Incorrect route complaint at Carstairs UPL 22/01/2016 at 19:07 #80058
Meld
Avatar
1098 posts
Online
Lyn, how about reversing 1C22 when it arrives in the UPL back to down before you send 0S01 on top of it. After 0S01 goes to sidings change 1C22 back to up and intheory everything should be ok.
Passed the age to be doing 'Spoon Feeding' !!!
Log in to reply
Incorrect route complaint at Carstairs UPL 22/01/2016 at 21:59 #80063
Lyn-Greenwood
Avatar
239 posts
" said:
Lyn, how about reversing 1C22 when it arrives in the UPL back to down before you send 0S01 on top of it. After 0S01 goes to sidings change 1C22 back to up and intheory everything should be ok.
I was hoping there would be a Rule that found a way round the problem, but I would need two separate locations and the WTT editor only allows one. A Rule '1C22 must not depart Carstairs UPL until 0 minutes after 1M22 arrives at Carstairs' would do the job. If you use 'Carstairs' as the location for both trains then 1C22 would be held in Carstairs P2 until 1M22 arrived. Not a good idea! I may add a request to the Wish-list for a 2nd location in Rules. I'm sure it would be very useful.

The idea of changing the Direction of 1C22 doesn't appeal to me because in a Multiplay scenario, clients are limited in what they can do and it's a bit messy anyway.

Let's see what Peter comes up with and I'll take it from there.

Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 15:37 #80071
Peter Bennet
Avatar
5355 posts
Although I am testing on a later iteration of the Sim I think your comment on save 3 is erroneous. As soon as I load it it is apparent that 0S01 is in the middle of vanishing into the siding. So your later comments on 0S01 being blocked by 1C22 seem misplaced.

I agree there is a problem of both trains moving off at the same time - that needs to be reported. 1C22 then hoves up at the signal which, despite being off it stops at, claiming wrong route. There is no wrong route coded for that signal but I think it's querying the "goods line" designation. I thought that explicitly said it was goods line though.

You then have to restore the route which gives an adverse change of aspect followed by the related phonecalls.

Peter

I identify as half man half biscuit - crumbs!
Last edited: 23/01/2016 at 16:29 by Peter Bennet
Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 16:31 #80073
Peter Bennet
Avatar
5355 posts
Another issue is that the signal is classed as Last wheel replacement so if the TC is still occupied by the other train the conditions to replace can't be met.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 16:55 #80074
Lyn-Greenwood
Avatar
239 posts
" said:
Although I am testing on a later iteration of the Sim I think your comment on save 3 is erroneous. As soon as I load it it is apparent that 0S01 is in the middle of vanishing into the siding. So your later comments on 0S01 being blocked by 1C22 seem misplaced.

I agree there is a problem of both trains moving off at the same time - that needs to be reported. 1C22 then hoves up at the signal which, despite being off it stops at, claiming wrong route. There is no wrong route coded for that signal so I guess the core code has noted that the route has already been used - don't know. You then have to restore the route which gies an adverse change of aspect followed by the related phonecalls.

Peter
Thanks for taking a look at the saves, Peter, but I believe you have misunderstood one of my earlier comments. Save 3 shows the original 0S01 moving into the Up Sidings with 1C22 following it along the UPL (all displayed in the F2 list). 1C22 finally stops at signal MC406 and shows 'Waiting for correct route to be set', as I noted for Save 4. The route to the Up Sidings clears automatically once 0S01 is clear, but for some reason there is no ACOA reported and no phone call from the driver of 1C22. Save 5 shows 1C22 stopped at signal MC406, thus preventing the new 0S01 (which appears 1 minute after the original 0S01 exits) getting from the Up Sidings to the UPL in order to join 1S01 in the DPL. I should have used 0S01-1 & 0S01-2 instead of UIDs to avoid confusion and also provided just the initial save for you to work through yourself so you could see how the situation develops.

For the real 1984 WTT, I've tried to find a Rule that will prevent 1C22 moving away from the UPL until 1M22 (the train it joins) arrives at Carstairs P2, but I need 2 locations for the Rule and there's only 1 available, so this may be one for the Wish List.

Lyn

Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 17:08 #80075
Lyn-Greenwood
Avatar
239 posts
" said:
Another issue is that the signal is classed as Last wheel replacement so if the TC is still occupied by the other train the conditions to replace can't be met.

Peter
The route cleared automatically once the first train was clear (see my earlier reply), so I never needed to cancel the route. I wonder why there was no ACOA reported for the second train, but it moved to status 'Waiting for correct route to be set'?

Lyn

Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 17:33 #80077
Peter Bennet
Avatar
5355 posts
" said:
" said:
Although I am testing on a later iteration of the Sim I think your comment on save 3 is erroneous. As soon as I load it it is apparent that 0S01 is in the middle of vanishing into the siding. So your later comments on 0S01 being blocked by 1C22 seem misplaced.

I agree there is a problem of both trains moving off at the same time - that needs to be reported. 1C22 then hoves up at the signal which, despite being off it stops at, claiming wrong route. There is no wrong route coded for that signal so I guess the core code has noted that the route has already been used - don't know. You then have to restore the route which gies an adverse change of aspect followed by the related phonecalls.

Peter
Thanks for taking a look at the saves, Peter, but I believe you have misunderstood one of my earlier comments. Save 3 shows the original 0S01 moving into the Up Sidings with 1C22 following it along the UPL (all displayed in the F2 list). 1C22 finally stops at signal MC406 and shows 'Waiting for correct route to be set', as I noted for Save 4. The route to the Up Sidings clears automatically once 0S01 is clear, but for some reason there is no ACOA reported and no phone call from the driver of 1C22. Save 5 shows 1C22 stopped at signal MC406, thus preventing the new 0S01 (which appears 1 minute after the original 0S01 exits) getting from the Up Sidings to the UPL in order to join 1S01 in the DPL. I should have used 0S01-1 & 0S01-2 instead of UIDs to avoid confusion and also provided just the initial save for you to work through yourself so you could see how the situation develops.

For the real 1984 WTT, I've tried to find a Rule that will prevent 1C22 moving away from the UPL until 1M22 (the train it joins) arrives at Carstairs P2, but I need 2 locations for the Rule and there's only 1 available, so this may be one for the Wish List.

Lyn
OK, I see - makes sense.

I think there are two things to report:

1C22 moving when it should not.
How LWR should work in such circumstances to avoid an ACOA.

I think everything else is consequential on these two issues.

Peter

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 18:10 #80082
Lyn-Greenwood
Avatar
239 posts
" said:
" said:
" said:
Although I am testing on a later iteration of the Sim I think your comment on save 3 is erroneous. As soon as I load it it is apparent that 0S01 is in the middle of vanishing into the siding. So your later comments on 0S01 being blocked by 1C22 seem misplaced.

I agree there is a problem of both trains moving off at the same time - that needs to be reported. 1C22 then hoves up at the signal which, despite being off it stops at, claiming wrong route. There is no wrong route coded for that signal so I guess the core code has noted that the route has already been used - don't know. You then have to restore the route which gies an adverse change of aspect followed by the related phonecalls.

Peter
Thanks for taking a look at the saves, Peter, but I believe you have misunderstood one of my earlier comments. Save 3 shows the original 0S01 moving into the Up Sidings with 1C22 following it along the UPL (all displayed in the F2 list). 1C22 finally stops at signal MC406 and shows 'Waiting for correct route to be set', as I noted for Save 4. The route to the Up Sidings clears automatically once 0S01 is clear, but for some reason there is no ACOA reported and no phone call from the driver of 1C22. Save 5 shows 1C22 stopped at signal MC406, thus preventing the new 0S01 (which appears 1 minute after the original 0S01 exits) getting from the Up Sidings to the UPL in order to join 1S01 in the DPL. I should have used 0S01-1 & 0S01-2 instead of UIDs to avoid confusion and also provided just the initial save for you to work through yourself so you could see how the situation develops.

For the real 1984 WTT, I've tried to find a Rule that will prevent 1C22 moving away from the UPL until 1M22 (the train it joins) arrives at Carstairs P2, but I need 2 locations for the Rule and there's only 1 available, so this may be one for the Wish List.

Lyn
OK, I see - makes sense.

I think there are two things to report:

1C22 moving when it should not.
How LWR should work in such circumstances to avoid an ACOA.

I think everything else is consequential on these two issues.

Peter
I quite agree, Peter. 1C22 moving when it shouldn't is the more serious problem. I can live with ACOAs, but didn't actually get one in this case. Maybe I should have!

Thanks for looking deeper into the problem. I'll now sit back and wait for the outcome.

Lyn

Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 19:56 #80089
Jan
Avatar
889 posts
A while ago, Geoff mentioned this:

" said:
There's logic in the code to (a) have the 2nd train ignore the signal until the rear of the first has gone past the signal (to prevent it driving off), and (b) prevent adverse change of aspect messages. However, I'm aware of occasions where this has not happened for some reason.
I've been able to replicate a similar situation to the one described here in Rugby South - if you open the attachment, set the route for 5Z00 and then watch the train list, you can see that 5Z01 goes to "waiting for right-away" and then starts to move off before 5Z00 has actually cleared the platform track section.

So (b), the prevention of ACoA messages is still functioning, but (a), preventing the second train from leaving, is somehow broken.

There's also an old issue (#5599) which sounds a bit like this.

Post has attachments. Log in to view them.
Two million people attempt to use Birmingham's magnificent rail network every year, with just over a million of them managing to get further than Smethwick.
Last edited: 23/01/2016 at 19:57 by Jan
Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 20:28 #80091
bill_gensheet
Avatar
1309 posts
From the timetabling point of view, I would suggest that 1C22 should not have been placed in the DPL with 1S01 / 0S01 around given the requirements of that shunt, or 0S01 just has to wait. The rest are consequences of trying to get out of jail in an adventurous manner.
Had I set 1C22 to 'near end stop exact' instead of just 'near' you would not be able to send either 0S01 in there anyway.

None of that suggests that there might not be some abnormal behaviour in the sim, but I would tend towards the thought that 1C22 is objecting to the goods line before considering the route.

Bill

Log in to reply
Incorrect route complaint at Carstairs UPL 23/01/2016 at 21:17 #80094
Peter Bennet
Avatar
5355 posts
" said:
A while ago, Geoff mentioned this:

" said:
There's logic in the code to (a) have the 2nd train ignore the signal until the rear of the first has gone past the signal (to prevent it driving off), and (b) prevent adverse change of aspect messages. However, I'm aware of occasions where this has not happened for some reason.
I've been able to replicate a similar situation to the one described here in Rugby South - if you open the attachment, set the route for 5Z00 and then watch the train list, you can see that 5Z01 goes to "waiting for right-away" and then starts to move off before 5Z00 has actually cleared the platform track section.

So (b), the prevention of ACoA messages is still functioning, but (a), preventing the second train from leaving, is somehow broken.

There's also an old issue (#5599) which sounds a bit like this.
Thanks for digging that out - have added a note to #5599.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply