Incorrect route complaint at Carstairs UPL

Can you quote the exact message? Also what was the TD that was in the TD berth associated with the route?

Peter

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

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

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.

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

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

" 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

" 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

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.

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.