Realism of weird approach locking behaviour with preset shunt

1. Bring a train to a stand at red signal 35 outside Ex SD.


2. Set a route forward from 35 to 37. 653 clears to white as a preset shunt and then 35 clears to yellow.


3. Wait for the train to pass 35. 35 goes red as soon as TC TJJ occupies. 653 remains clear as the train has not yet passed it.


4. Before the train reaches it, cancel 653’s route. 653 immediately turns red. Question 1: If I do nothing further, 653 will remain red but circuits TJL, TJM, TJN, and TJP will remain locked (white) forever with the train standing at 653. Is it prototypical that these TCs do not time out and unlock?


5. Wait until TJJ clears causing 35 to undergo TORR.


6. Restroke 653→37 (this would have been impossible, with the message “Cannot overset a different route”, had 35→37 still been set, but as 35→37 has now TORRed, it works).


7. 653 clears, this time with a white stem instead of a grey stem signifying an actual set route.


8. Immediately cancel 653. Message: “30 seconds approach locking”.


9. Wait 30 seconds, then route from 653 to somewhere else (in my test, into carriage sidings). Question 2: The train just came rolling in on a clear main signal. Why was I allowed to throw points in front of it after waiting only 30 seconds instead of the usual 2 minutes?
   [li]Question 3: The train doesn’t phone in claiming an ACOA. Isn’t clear main signal followed by red shunt signal considered an ACOA?

1. Do steps 1 through 8 above.


2. Instead of setting a route forward, reverse the train and let it drive back to 658 (the LOS).


3. With every TC between 35 and 37 unoccupied, unlocked, and no routes set, call 35→37. The route locks, but neither 35 nor 653 ever clears. Cancelling it and then calling the route again brings everything back to normal. This appears to be something affecting 653, not something specific to 35, because replacing the 35–37 call in this step with a 35–237 call works fine, and then even after that route has been taken, calling 35→37 afterwards fails as described the first time. This behaviour only happens if 653 was restroked and approach-locked in steps 6–8 above; it does not happen if you just cancel 653 while it’s preset and then turn the train around and back it out of the area without restroking 653 (i.e. if you skip steps 6–8). Question 4: Is this prototypical?

Question 1: If I do nothing further, 653 will remain red but circuits TJL, TJM, TJN, and TJP will remain locked (white) forever with the train standing at 653. Is it prototypical that these TCs do not time out and unlock?

Restroke 653→37 (this would have been impossible, with the message “Cannot overset a different route”, had 35→37 still been set, but as 35→37 has now TORRed, it works).

653 clears, this time with a white stem instead of a grey stem signifying an actual set route.
Immediately cancel 653. Message: “30 seconds approach locking”.
Wait 30 seconds, then route from 653 to somewhere else (in my test, into carriage sidings). Question 2: The train just came rolling in on a clear main signal. Why was I allowed to throw points in front of it after waiting only 30 seconds instead of the usual 2 minutes?

Question 3: The train doesn’t phone in claiming an ACOA. Isn’t clear main signal followed by red shunt signal considered an ACOA?

Here’s another odd behaviour I don’t entirely understand:
Do steps 1 through 8 above.
Instead of setting a route forward, reverse the train and let it drive back to 658 (the LOS).
With every TC between 35 and 37 unoccupied, unlocked, and no routes set, call 35→37. The route locks, but neither 35 nor 653 ever clears. Cancelling it and then calling the route again brings everything back to normal. This appears to be something affecting 653, not something specific to 35, because replacing the 35–37 call in this step with a 35–237 call works fine, and then even after that route has been taken, calling 35→37 afterwards fails as described the first time. This behaviour only happens if 653 was restroked and approach-locked in steps 6–8 above; it does not happen if you just cancel 653 while it’s preset and then turn the train around and back it out of the area without restroking 653 (i.e. if you skip steps 6–8). Question 4: Is this prototypical?

In the real world to re-clear 653 whilst it's in preset mode all you would have to do is click on 653 (no need to press an exit).

otherwise you'd just get an entrance cursor merrily flashing away (for a short time).

Train passed first signal: Pulling the first signal button has no effect on
the aspect of the intermediate signal, but may initiate route release if
TORR has not already taken place. Pulling the intermediate signal
button will replace this signal, but no approach locking release will take
place, and the remaining portion of the route will remain locked until the
train has passed through. The signal may only be re-cleared by
restroking the route from the intermediate signal entrance button to the
next exit button on the line of the route which is set. This last condition
differs from Route Relay Interlocking practice, where only the
intermediate signal entrance button needs to be pressed to allow the
signal to re-clear (it is treated as an emergency replacement). This is
not possible in SSI as a push button may not be used both as a single
operation button and as the entrance button for a multi-button
sequence.

As for a panel controlling an SSI... not sure :lol: