I'm re-opening this thread to post the results of testing Brummfondel's path rule with lower quadrant semaphore signals. Brian (Kennilworth) has helped me enormously with his time and ideas, and I'm very grateful to him - without him I'd have given up or gone down some wild-goose chase.
I'm not presenting this as the definitive way to do these things, only as a way which we've found to work. There may well be people out there who do things differently; I just want to describe what we've found in the hope that it may save someone else spending as much time as we have over this.
Uploaded with
ImageShack.us
I built a test layout, modelled very, very loosely on Shrewsbury (UK). It's a double junction, so trains can leave to and arrive from two directions (Crewe and Chester) in the north, and two (Telford and Hereford) in the south.
A train approaching from Crewe proceeds either to Platform 1 or Platform 3, depending on whether it's bound for Telford or Hereford. The right branch semaphore S1 shows which route it's taking.
For most of the testing there were only two approach paths in use: one from Crewe and one from Chester, both converging to use Platform 3 en route for Hereford.
The semaphores in use were
Sig GWR Home R branch <kuid2:218467:24630:1>
Sig GWR Home L branch <kuid2:218467:24631:1>
Sig BR(W) Combined 20ft <kuid2:218467:24544:1>
Problem 1: Semaphores could not be used as path starters.
When the branch semaphore (or even a simple home semaphore) was used as the path starter signal, the trains worked (apart from problems mentioned below), but when under path control the arms did not animate (although the lights changed). Visually of course this is unacceptable.
This problem was solved by putting an invisible signal <kuid2:45324:24010:2> (marked as IS in the diagram) just ahead of each semaphore. This was specified as the path starter (set to green in the path definition), and the semaphore was set to automatic in the definition. It was found that the distance between the invisible signal and the semaphore had to be no more than 5m, or a train could get "stuck" forever between them.
Problem 2: Trains go the wrong way.
(This problem is nothing to do with semaphores; it occurs with colour light signals as well.)
At times, when there was contention, a train from Crewe which should have been going to Hereford instead went straight on to Telford! What happened was that after a previous train from Crewe had correctly passed through to platform 3, a train from Chester arrived, and grabbed the path to platform 3. While this still held the path, another train from Crewe arrived, and (correctly) failed to get the path. However, because we were using the no-wait (aka queued) option on the getpath command, and the default position for junction J1 was straight on (as it was for further junctions down platform 1) the semaphore S1 was clear for the straight-on direction, and the train carried merrily on past platform 1 to Telford! This also caused later trains from Chester to queue up indefinitely, because the path request for this second Crewe train was still queued up (although the train itself had now gone), and when the path request could be satisfied it enabled the *third* Crewe train to proceed correctly. So the n'th Crewe train was always using the (n-1)'th train's path request!
The problem is that the path starter signal is only under path control when a path has been set. At other times it reverts to automatic, and hence can be clear if the default path beyond it is clear. This must not be allowed to happen. It could have been prevented by setting the default position for junction J1 to the right, but as I want to use Andi's junctions it's not prototypical to see a crossover set in this way, so I added an invisible trailing junction (in blue - marked ITJ1), which had a default position of right. So the path starter was never clear unless it was set to be so by path control.
Problem 3: platform starter signal shows clear then danger.
(Again, this problem occurs with colour light signals as well as semaphores.)
Each train gets two paths: the approach path to get it to the correct platform (no-wait option for this one), and then a second path (with wait) when it is ready to leave the platform, to route it towards its destination. Consider a train approaching platform 3 en route for Hereford. It has not yet issued the getpath command for the leaving path, so the leaving path starter signal (LS1) is not yet under path control. So if the route ahead to Hereford is clear LS1 will be clear. However, if a train now approached from Telford, and gets the path to take it platform 4, when the Hereford train tries to get its leaving path it will fail, and LS1 will now go to danger. This is not prototypical (signalman don't usually changed their minds!), so again the solution is to add an invisible trailing junction (ITJ2) with default direction right, so that LS1 is always at danger unless a successful getpath command from a train at platform 3 has been issued.
With these changes in place for all of the 8 possible paths through the station (as in the diagram) I ran a test generating trains every 2 minutes from each of the four remote places, with alternate trains either running straight on through Shrewsbury or using the crossover to go to the diagonally-opposite destination. Although queues did gradually build up - Shrewsbury station couldn't cope with this volume - all trains were still passing through correctly after 1.5 hours.
In summary, the two rules which worked, at least for this scenario, were
1. Never let a path starter go to clear when not under path control. Ensure there is no default path beyond it.
2. Don't use a semaphore for a path starter. Instead, have an invisible signal no more than 5m in front of it, and use that as the path starter.
I hope somebody finds this useful!
Peter
