Tigger Posted October 31, 2011 Author Share Posted October 31, 2011 For info - Widnes uses RailRoad & Co software to drive the signals and it simulates the SSI cycles, the feathers clear and a few seconds later the main aspect changes. I'm using a Picaxe programmable microprocessor for this little project that will go on my SWAG Module. I will post a video later when I have finished the programming so you guys can check its operation for authenticity Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted October 31, 2011 RMweb Gold Share Posted October 31, 2011 Certainly 30s is not credible for a simple interlocking-busy situation, as the TFMs would have shut down in the meantime. I'm not sure what you are implying here Edwin but given I have witnessed it several times, I probably even have a video of it, I will politely say you are wrong - 30 seconds is perfectly normal for that signal, one of the Sandhills IECC signals, at Bidston, controlling the connection to the Dee Marsh line. Link to post Share on other sites More sharing options...
RMweb Gold big jim Posted November 1, 2011 RMweb Gold Share Posted November 1, 2011 i had it a few weeks back where i got a sub signal entering marylebone but no route indicator indication of where i was going (which is the norm) the signaller then contacted me via the csr to say there was a points problem and i would be crossing over twice between the signal and platform and that caused the route indicator not to work, not something ive experienced before. ive also had it heading through wolverhampton towards bescot where the route indicator displays "B" for branch or bescot or "S" for stour (towards new st), as i approached it expecting a "B" i looked up to see "S", put the brake in ready to stop then i realised a couple of bulbs were out at the bottom left and top right of the box which made the B look like an S! Link to post Share on other sites More sharing options...
Edwin_m Posted November 1, 2011 Share Posted November 1, 2011 I'm not sure what you are implying here Edwin but given I have witnessed it several times, I probably even have a video of it, I will politely say you are wrong - 30 seconds is perfectly normal for that signal, one of the Sandhills IECC signals, at Bidston, controlling the connection to the Dee Marsh line. I'm not disputing that you have seen it, but I don't agree with your suggested explanation. If the interlocking was taking as long as 30 seconds to respond then it would be delaying the indications of track circuit occupancy by a similar amount, which would be a safety issue. Panel requests may be queued when the interlocking is busy but responding to changes at the trackside is done on a fixed cycle which as explained above shouldn't go over one second and if it does by much then other things will stop working. It is probably worth taking it up with your signalling contacts as it sounds as if there may be a fault in the hardware, probably the indicator proving circuit. A data fault is also possible but unlikely given the amount of checking and testing that is done. Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 1, 2011 RMweb Gold Share Posted November 1, 2011 I'm not disputing that you have seen it, but I don't agree with your suggested explanation. If the interlocking was taking as long as 30 seconds to respond then it would be delaying the indications of track circuit occupancy by a similar amount, which would be a safety issue. You might consider my response was slightly tongue in cheek ... However If the interlocking was taking as long as 30 seconds to respond then it would be delaying the indications of track circuit occupancy by a similar amount, which would be a safety issue. In this case it's not really a safety issue as the proceed aspect is the "thing" that's delayed, not the proving of points etc. I would expect track occupancy to be "instant", even a 1 second delay could mean an alternate route could be free to be set but fortunately the route timeouts (if cancelled) prevent this sort of thing - I hope. however Panel requests may be queued when the interlocking is busy but responding to changes at the trackside is done on a fixed cycle which as explained above shouldn't go over one second and if it does by much then other things will stop working. Slightly concerning that a train could be on a track for around 1-2 seconds before the system knows about it, but I guess that's part of the design. It is probably worth taking it up with your signalling contacts as it sounds as if there may be a fault in the hardware, probably the indicator proving circuit. A data fault is also possible but unlikely given the amount of checking and testing that is done. Not really, I've seen it on plenty of signals, it's not an unusual phenomena and as you know it happens with relays too - just relays are a lot quicker, my son and I try and photograph "half" signals when we are out and about, getting them on an IECC is easy as there is a notable pause between indicators clearing and main aspects stepping up, not easy at all on relays. But we digress - if I get chance I will dig out some photos of the said signal. Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 1, 2011 RMweb Gold Share Posted November 1, 2011 Here's the signal taking about 3 seconds, which is around the normal time but it can, and frequently does(did), take longer. Link to post Share on other sites More sharing options...
royaloak Posted November 1, 2011 Share Posted November 1, 2011 That signal is certainly very slow clearing and cycling through to green. Link to post Share on other sites More sharing options...
Edwin_m Posted November 1, 2011 Share Posted November 1, 2011 In this case it's not really a safety issue as the proceed aspect is the "thing" that's delayed, not the proving of points etc. I would expect track occupancy to be "instant", even a 1 second delay could mean an alternate route could be free to be set but fortunately the route timeouts (if cancelled) prevent this sort of thing - I hope. Delay of the order of 30s in displaying the track status to the signalman would be a safety issue because he doesn't know where the trains are. A delay of 1s or so is typical of signal display systems, including relays via TDM, and isn't seen as a problem. As to how the interlocking sees it, it rather depends whether the incoming indications are all delayed and queued up somehow or if some overtake others. It's impossible to say which of these could apply, as I still content that delays of that magnitude can't happen in the first place. I described above how a delay of around 3s could arise, and incidentally the delay in stepping up from single yellow is a deliberate SSI feature because (IIRC) of some transients that can occur if the next signal loses lamp proving. The fact it sometimes takes longer than this is to me indicative of an intermittent hardware fault. Considering that SSIs are also used in the likes of Liverpool Street and Paddington throats, it's also unlikely that the Wirral is high on the list of heavily loaded interlockings. As a software engineer yourself Dave and someone who is often rightly dismissive of people's half-baked notions of signalling, I hope you'll appreciate where I'm coming from in saying this system has been programmed, validated and tested to the highest standards of integrity, has over 20 years of accident-free service and system overload simply can't cause this type of behaviour. As I said above I knew many of the people who developed it and I was later project engineer for some closely-related systems, so without blowing my own trumpet too loudly I have to say I believe I know more about the internal workings of SSI than anyone else I've encountered on this forum. Link to post Share on other sites More sharing options...
RMweb Gold The Stationmaster Posted November 1, 2011 RMweb Gold Share Posted November 1, 2011 I described above how a delay of around 3s could arise, and incidentally the delay in stepping up from single yellow is a deliberate SSI feature because (IIRC) of some transients that can occur if the next signal loses lamp proving. The fact it sometimes takes longer than this is to me indicative of an intermittent hardware fault. Considering that SSIs are also used in the likes of Liverpool Street and Paddington throats, it's also unlikely that the Wirral is high on the list of heavily loaded interlockings. Very true Edwin - some of the Paddington area signals take longer than that from what I've observed! Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 1, 2011 RMweb Gold Share Posted November 1, 2011 Delay of the order of 30s in displaying the track status to the signalman would be a safety issue because he doesn't know where the trains are. A delay of 1s or so is typical of signal display systems, including relays via TDM, and isn't seen as a problem. I don't recall anyone claiming there was a delay in the track status indication. You might like to reread what I actually did say. As to how the interlocking sees it, it rather depends whether the incoming indications are all delayed and queued up somehow or if some overtake others. It's impossible to say which of these could apply, as I still content that delays of that magnitude can't happen in the first place. If its impossible to say which route the messages take then it's impossible to contend that the delay I mentioned can't happen, you won't take my word for it but you don't actually know what did happen at the time. I described above how a delay of around 3s could arise, and incidentally the delay in stepping up from single yellow is a deliberate SSI feature because (IIRC) of some transients that can occur if the next signal loses lamp proving. The fact it sometimes takes longer than this is to me indicative of an intermittent hardware fault. Considering that SSIs are also used in the likes of Liverpool Street and Paddington throats, it's also unlikely that the Wirral is high on the list of heavily loaded interlockings. Actually the delay in stepping up from the single yellow is because the next signal had to clear - there is a starter around the corner, Whether it's more or less than Paddington or Liverpool Street is really immaterial - are the processors identical ? are they running identical software ? are the interfaces the same ? the same number ? all these things can make a difference, is it peak, off peak, do the service patterns drop into a simple in and out ? etc. etc. chalk and cheese. As a software engineer yourself Dave and someone who is often rightly dismissive of people's half-baked notions of signalling, I hope you'll appreciate where I'm coming from in saying this system has been programmed, validated and tested to the highest standards of integrity, has over 20 years of accident-free service and system overload simply can't cause this type of behaviour. As I said above I knew many of the people who developed it and I was later project engineer for some closely-related systems, so without blowing my own trumpet too loudly I have to say I believe I know more about the internal workings of SSI than anyone else I've encountered on this forum. Not doubting your claims, but I notice you still dismiss my 30 seconds comment. As a software engineer I also know that software can still have bugs, despite rigorous testing and I also know that some "testing" is not actually what it's claimed to be, and I know of plenty of "that can't happen" problems which do happen - who would have thought a mission to Mars would try and land several feet below the surface due to a basic error - I bet that was tested and bug free too ... FlyingSignalman may recall I actually spoke to him at the time as I was a bit concerned about the delay but if his memory is as "good" as mine he probably won't. If I could remember when it (the longer than normal delay) happened I would dig out the (time stamped) photos. Link to post Share on other sites More sharing options...
Edwin_m Posted November 2, 2011 Share Posted November 2, 2011 I don't recall anyone claiming there was a delay in the track status indication. You might like to reread what I actually did say. The clearing of the aspect in response to the route indicator proving is the interlocking responding to a change of state from the trackside. If as you claim this response is delayed within the interlocking then either the interlocking is delaying processing the track status or it is delaying processing the action. This would either affect indications or controls (the interlocking doesn't and couldn't prioritise the important ones) and delaying either by 30s is a safety issue. If its impossible to say which route the messages take then it's impossible to contend that the delay I mentioned can't happen, you won't take my word for it but you don't actually know what did happen at the time. It's a bit like arguing which way a flying saucer was rotating, when the person you are discussing it with contends the flying saucer doesn't exist. Actually the delay in stepping up from the single yellow is because the next signal had to clear - there is a starter around the corner, I bow to your knowledge on that one - however I do believe (though this sort of detail is a little hazy after 20 years) that the aspect sequence is prevented from going straight from red to green. Has anyone observed this in other SSI areas? Whether it's more or less than Paddington or Liverpool Street is really immaterial - are the processors identical ? are they running identical software ? are the interfaces the same ? the same number ? all these things can make a difference, is it peak, off peak, do the service patterns drop into a simple in and out ? etc. etc. chalk and cheese. Liverpool Street was the first IECC in 1989ish and ran three SSIs for the station throat and out to Bethnal Green. Merseyrail was 1994ish and I was involved in developing systems for both. Paddington was indeed later and I didn't have much to do with that. At some point the SSI was upgraded from Mk1 to Mk2 but I don't know the details of when, but I would suggest that the original system would have the same or older kit. Not doubting your claims, but I notice you still dismiss my 30 seconds comment. Invisible ink,., I'm not disputing that you have seen it, but I don't agree with your suggested explanation. To be blunt, as you so often are with me and others on this forum, it's pretty clear that you have no knowledge of how SSI works so your "explanation" can be no more than speculation on your part - and potentially damaging speculation to boot. Perhaps If I see a puff of smoke coming from a nuclear power station I should post that your software has just caused a meltdown? Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 Perhaps if you told me about the puff of smoke but I dismissed it as being impossible (not that I actually witnessed the puff of smoke but I know it didn't happen) as I was the expert (and I would tell you I was just so you understood where you stand) in puffs of smoke we might be nearer to a like for like. I've had some discussions with some drivers regarding this and it seems I am not alone in observing strange goings on with SSI, but hey, they must be wrong too - as must StationMaster who pointed out that Paddington is often longer than your times. BTW - I, haven't, aside from a tongue in cheek comment (which obviously hit your raw nerve), offered any explanation - that's all been you - please don't try and put your words in my mouth, maybe your signalz are getting crossed ? Time for me to leave you to this one I think, I'm happy to have "blunt" discussions but I really do get annoyed when people make out I've said something I haven't, not once but twice. Let's hope I actually was wrong and I can't tell the difference between 3s and 30s because if this is a safety issue as you say (and I bow to your expert judgement) and if I really did observe it, then somewhere, something is not right. I'm done - if I find anything meaningful on video or still, I will raise it through other routes - pardon the pun. Time for me to report my own posting again. Link to post Share on other sites More sharing options...
Edwin_m Posted November 3, 2011 Share Posted November 3, 2011 For the third time, I don't dispute your report of 30s delay. You did offer an explanation, system overload, not once but twice and that is what I disagree with. Subject closed. I have other softer brick walls to bang my head on. Link to post Share on other sites More sharing options...
RMweb Gold Colin_McLeod Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 This may help with the head banging LOL Just print out and affix to suitable surface. Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 For the third time, I don't dispute your report of 30s delay. You did offer an explanation, system overload, not once but twice and that is what I disagree with. I did not offer an explanation other than the tongue in cheek one (for the third time of saying) - are you reading the same topic as me ? - could you try quoting where I gave the explanation as, even though I typed the replies, I still cannot see it - as it's obviously upset you so much it would be useful to see where, so, if necessary, I can apologise for and learn from it, of course if you cannot do this then maybe it's not you that needs a different wall. Link to post Share on other sites More sharing options...
ZippyHG Posted November 3, 2011 Share Posted November 3, 2011 As a signal maintenance technician, what beast 66606 describes is very true. The real world signalling system rely on transmission to route the requests to the TFM and depending on the amount of TFM on the system it can indeed be very slow to repsond. combine this with the fact that there is diverse routing for the system, meaning that only one of the links needs to be active to allow a command to be proccesed. I would like to say that you are both correct, and under test bench or simulator conditions the response would indeed be very quick. I have wiitnessed on many occasions the junction or route indicator clearing, then a delay of sometimes several seconds before the main signal clears. The current Mk2 SSi MPM are running with a 2mhz! processor. compare this with modern PC processing power and you an see that there must be an inherent delay before the diagnostics decide there is a fault. when clearing the fault memory it an be sometimes be as muh as 15-20 seconds before any actual alarms are either regenerated or cleared from the signallers fault indications. In the video that was shown, i would class that as a normal response by the SSI, and is exactly what i would expect it to behave. problems do indeed occur where there are SSI/relay based interlocking adjoining the indications will be longer for the ssi and this in turn can cause problems with approach releasing on occasions. Link to post Share on other sites More sharing options...
RMweb Premium phil-b259 Posted November 3, 2011 RMweb Premium Share Posted November 3, 2011 Liverpool Street was the first IECC in 1989ish and ran three SSIs for the station throat and out to Bethnal Green. Merseyrail was 1994ish and I was involved in developing systems for both. Paddington was indeed later and I didn't have much to do with that. At some point the SSI was upgraded from Mk1 to Mk2 but I don't know the details of when, but I would suggest that the original system would have the same or older kit. IIRC Lemington Spa had the honor of being the first place controlled by a SSI installation with the Oxted - East Grinstead / Uckfield line following on close behind. Liverpool St was however an early recipant of SSI though due to its rebuilding and rearangement of the station throat as part of the stations redevelopment and may well have been the first SSI to be installed in a complex situation Link to post Share on other sites More sharing options...
ForestPines Posted November 3, 2011 Share Posted November 3, 2011 Those SSI installations were not IECCs, though. Link to post Share on other sites More sharing options...
Edwin_m Posted November 3, 2011 Share Posted November 3, 2011 I did not offer an explanation other than the tongue in cheek one (for the third time of saying) - are you reading the same topic as me ? - could you try quoting where I gave the explanation... How about this one? SSI checks in cycles, if the processor is not free to check the theatre is lit the one second you mention can be a lot longer, I've seen over 30 seconds for a "feather", from feather lit to aspect stepping up. Link to post Share on other sites More sharing options...
RMweb Gold The Stationmaster Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 Those SSI installations were not IECCs, though. Liverpool St is an IECC and according to at least one internet source was the first to be commissioned (in 1989) and it's listed by another source as incorporating 4 IECCs. Another source lists the following IECCs - Ashford, Edinburgh, Liverpool St, Marylebone, Merseyrail (Sandhills), Slough New, Swindon B, Didcot (Thames Valley Signalling Centre), Tyneside, Upminster, Yoker, and York. While I can't vouch for the provenance of the source I do know that some of the p[laces in that list definitely are IECCs several of them being installed in the early/mid 1990s but I'm not sure if Didcot actually uses wholly BR IECC technology or something else (from the Westinghouse stable). Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 How about this one? So SSI doesn't check in cycles then ? FF(lips)S EVEN YOU SAY IT DOES. AND I QUOTE Panel requests may be queued when the interlocking is busy but responding to changes at the trackside is done on a fixed cycle which as explained above shouldn't go over one second and if it does by much then other things will stop working. There is only so much that a processor can handle in a fixed cycle, no matter how fast it runs, by definition a fixed cycle is fixed so if the processor has say 1 second of "cpu" (lets call the units cpu, it makes no odds) available, and the current load requires 3 then something(s) will queue up, it's not rocket science - or are you saying that its not a fixed cycle and you were wrong in your statement ? If I'm wrong then perhaps you can explain how, in a fixed cycle, the processor can handle more than it's physically capable of ? - I know a lot of hardware engineers who will be ready to pay a lot of money for that information. Link to post Share on other sites More sharing options...
ForestPines Posted November 3, 2011 Share Posted November 3, 2011 Liverpool St is an IECC and according to at least one internet source was the first to be commissioned (in 1989) and it's listed by another source as incorporating 4 IECCs. Maybe I wasn't entirely clear there - I meant, the other SSI installations mentioned by phil-b259 there aren't IECCs, but Liverpool St is, so regardless of Leamington et al potentially predating it, Liverpool St is still the first IECC. Does that make sense? Link to post Share on other sites More sharing options...
RMweb Gold TheSignalEngineer Posted November 3, 2011 RMweb Gold Share Posted November 3, 2011 Liverpool St IECC was commissioned at Easter 1989. York followed in May 1989 and Yoker in July 1989 Link to post Share on other sites More sharing options...
Edwin_m Posted November 3, 2011 Share Posted November 3, 2011 So SSI doesn't check in cycles then ? FF(lips)S EVEN YOU SAY IT DOES. AND I QUOTE There is only so much that a processor can handle in a fixed cycle, no matter how fast it runs, by definition a fixed cycle is fixed so if the processor has say 1 second of "cpu" (lets call the units cpu, it makes no odds) available, and the current load requires 3 then something(s) will queue up, it's not rocket science - or are you saying that its not a fixed cycle and you were wrong in your statement ? If I'm wrong then perhaps you can explain how, in a fixed cycle, the processor can handle more than it's physically capable of ? - I know a lot of hardware engineers who will be ready to pay a lot of money for that information. It's the other way round. The CPU takes as long as it needs to, to complete the tasks it has allocated in a particular minor cycle. 64 minor cycles add up to a major cycle. If the major cycle goes over 1s then the clocks run slow, and if it gets much longer than that then the TFMs start shutting down because they assume they have lost communication from the interlocking. "Fixed" may be the wrong word to describe this, but I did explain it back in post #25. In the days when I had a lot to do with these systems it was down to the data preparer to make sure the data didn't exceed the limits set out in the data preparation guide, and I presume the testing would have included a check on cycle time. There may now be more automation, and I guess the newer and much more powerful computer-based interlockings which also run SSI data may have less severe limits of this type. Link to post Share on other sites More sharing options...
RMweb Gold beast66606 Posted November 4, 2011 RMweb Gold Share Posted November 4, 2011 Thanks (see I can do it) for the explanation - I've been chatting with a signal engineer who described the minor and major cycles and how the interlocking will shunt off requests from it's cycle to slave units to actually handle that request - at a level that I understand His suggestion, based on nothing other than speculation, is that on the occasion in question the feather lit but when asked to prove it, it temporarily said "not lit", this was transient so after a few retries (hence the longer than expected time) it coughed up to the fact that it was lit after all, and all continued as normal, this would have been reported on the technicians panel but was probably not "worried" about as it was transient - this is all speculation of course. Link to post Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.