Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
2006 Cts on 2012 IRSE tables
#8
Yes I agree that for setting 171A(M) there is a need to prove that 122D(M) route locking is normal, or at least the overlap locking on EL and EK has timed out, should 228 be locked Normal.

However if 228 are free then 171A(M) is available to set and, when it does so, then 228 will be called Reverse. 228 will subsequently be locked Reverse by "counter-conditional locking" until such time as one or other of the mutually opposing overlaps has been released.

Therefore in the route level of 171 there should be an "or" condition "228 R or free to go" conditioning out the opposing route locking entry.

You are correct that if 228 are set R by the signaller initially then the route will set with overlap as described. I do now note that 122C(S) has been given a shunt overlap as far as CL and therefore yes I agree that this presents a similar situation- I am somewhat old in the tooth and thus giving shunts overlaps is not something that comes naturally to me!

Yes it is horrendous- suggest you adopt NIR practice and dispense with the complexity of Swinging Overlaps. Indeed Network Rail seems to be coming to much the same view after a few particular nasties when attempting to implement is SSI or SSI-like data; hence the "NoticeBoard 125 entitled "Simple Is Effective".

The route from 175 would read to 159 and there is no stated requirement that 159 be off, although I agree that this is something that could have been adopted. Whereas any GPL in line of route from one running signal to another would be pre-set (effectively false fed to a proceed aspect when the main signal is ready-to-clear and then proved actually to be OFF before the main signal actually does clear), then this would not be done for another main aspect. Typically any control is at aspect level, the signaller setting the routes in either order, but the first signal not clearing until the one to which it reads has itself cleared- this would be implemented when a particular risk is believed to exist should the exit of the first route suffer a SPAD.

In scenario in which this does not apply, 175 reads to 159 which can be at Red and yes sections AF and AE are locked as its overlap in the Down direction. 175 is required as route normal in 122A(M) but not 122A(W); similarly its associated route locking should be shown as {AF, AE [AJ, AH AG or (AG occ for t)]}, so yes you are right.
122A(W) only locks AD as its overlap and this abutts end-on the overlap AF, AE beyond 159 so in this case there is no conflict with the route from 175.


(30-07-2014, 08:37 AM)StrongLifts5x5 Wrote: Hi Peter

I have been working through the control tables for the 2006 exam however if you could address some concerns I have?

171A(M) do you not have to take into consideration opposing locking from 122D(M)?? also if the signalman keys 228R then sets the route the route would the route not set up to 225B locking 225N? So therefore you need to consider 122C(S) as well?

It a horrendous set of controls to complete in an hour, my first attempt took around an hour excluding the point controls.

My experience is with NIR controls so most of our interlocking would not contain complex swinging overlaps.

Cheers,

Darren

Also I am unsure about the route setting from 175 signal coming of the branch, does this set to 159 signal and if it did would the O/L of 159 therefore not conflict with 122A(M), and would we not put 175A in the route normal for 122A(M) or prove train is timed to a stand at AG tc??
PJW
Reply


Messages In This Thread
2006 Cts on 2012 IRSE tables - by dorothy.pipet - 15-07-2013, 08:16 AM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 16-07-2013, 06:03 AM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 19-07-2013, 05:51 AM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 16-07-2013, 12:17 PM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 04-08-2014, 08:00 PM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 04-08-2014, 08:11 PM
RE: 2006 Cts on 2012 IRSE tables - by PJW - 05-08-2014, 06:17 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)