So did I. I was on the first 365 that came to a halt outside Hitchin, before it was sent back to Biggleswade and taken out of service. Then got onto the next 365 that failed at the same point, before the train eventually making it Stevenage and onwards to London (I gave up at Stevenage).Yes, I managed to get caught up in this mess today,
People have written some total rubbish in this thread. Welshman is about the only post that makes sense. Coasting through Hitchin has been done (during engineering) over the past couple of years, and has been approved by the necessary bodies as a safe method of working.Whilst I have every sympathy with those caught-up in yesterday's fiasco, shouldn't we give NR/EC some credit for even attempting to run a service?
As far as I can see, the alternative would have been a total blockade and bustitution from Stevenage to Biggleswade, or even further north.
Then the complaints would have come rolling in!
cl365's were originally equipped with 2 AWS receivers - one for AC operation and one for DC operation.So to summarise, the root cause of the problem is that 365s have an AWS related issue when coasting with pan(s) down? It causes an unecessary brake application that drivers cannot rectify - have I understood that?
And this is a known problem with history behind it?
How long was the coasting section? From where to where?
Not 100% sure but I would guess its partly to do with the fact that the driver cant override the passcom on a 317 or 321 like they can on 313s and 365s so if someone pulled the chord in the dead section then they would come to a stand.I do seem to remember 365s having this problem coasting in the past (having been on one that kept stopping, and the PIS restarting multiple times). Is there a particular reason they didn't go for 317s/321s this time?
Great - thanks for that. I see the issue now. Sounds like a typical legacy problem to me. Our voltage selection is a different control from the current collector deployment and as a result when a pan is lowered, the train doesn't assume any other mode as you have described here, it simply sits in "neutral" until another voltage is selected before any pantograph circuits are engaged.cl365's were originally equipped with 2 AWS receivers - one for AC operation and one for DC operation.
Same control box, sunflower, push button etc but the voltage selection system set up from pressing the "Pan down/DC select" or "Pan up/AC select" caused different relays to energise and brought the appropriate receiver into use.
When the whole fleet ended up on the AC there was a solid state AWS receiver modification being developed, which did away with the 2 separate receivers for one common one.
It is possible that, as it isn't possible for the cl365's to go back and run on the DC due to certification issues and the fundamental lack of DC current collection equipment, the need for an operational DC AWS receiver was overlooked or discounted.
If this is the case; as the unit is coming out of the live OHL section and the driver presses Pan down/DC select to bring the pan off the dead OHL the unit goes into DC mode. This causes the AWS system to self test, but it will fail self test if there isn't a DC receiver present (or the relays/wiring haven't been modified to use the single receiver) and the brakes will apply and cannot be released without either selecting Pan up/AC select - which can't be done due to the OHL isolation - or isolating the AWS.
As seems to be the case every single time. It seems FCC has a good bunch of people that can help work to get people going again, even laying on bus replacements at fairly short notice on many occasions. They can crack on with all the hard stuff, then let everyone down because they can't provide information to people!And as usual, an utter lack of communication from FCC about what was going on, which was irritating passengers far more than the delays themselves.
Quite. I very rarely use FCC because I am lucky to have viable alternatives, but when I do, any problem is not communicated any further than very brief driver announcements and perhaps a display board showing "Delayed". The website is actually quite confusing and does a relatively poor job of showing information neatly and concisely.As seems to be the case every single time. It seems FCC has a good bunch of people that can help work to get people going again, even laying on bus replacements at fairly short notice on many occasions. They can crack on with all the hard stuff, then let everyone down because they can't provide information to people!
Surely the information provision is the easy bit? Twitter has helped a lot, but not everyone knows about, or uses, Twitter so they're still stuck on platforms or in their offices/homes wondering what's going on. The departure boards also do their very best to convey incorrect information and the 'on time' nonsense.
One bit of information we can be sure to get is that 'FCC takes this very seriously and will investigate what happened to make sure it doesn't happen again'.
I think most displays and announcements can be set with information about delays, but I rather think that Control and on-train staff don't have time to fiddle around with such things.I thought the screens on the 317/1s (as fitted by Wagn) were supposed to be able to convey 'live' information. One ONE single occasion I remember hearing on a FCC service an announcement about the train being late running, but I can't for the life of me remember what the wording was.
Now, the driver might have manually set that - or the software was set to detect the service was late (which means it knew the working timetable) so it might not be the case that it was sent any info from outside of the train (does anyone know if they have any form of data connection to the outside world?). Whatever the case, I'm quite sure that FCC did say once that they expected to provide realtime info onboard - including the tube status. That would have to be fed to the train somehow.
I concur. There are some TOCs - notably Southern - where station display boards only show trains that have manually been confirmed as running, whenever delays exceed a certain chronological point; this may help reduce those annoying problems that you've quite rightly mentioned.As has been suggested many times, FCC (or the industry in general) needs to tie-up services so that a service formed of a delayed inbound train doesn't show as 'on time' simply because it isn't due to leave yet (then immediately switching to Delayed, or worse still - the dreaded Estimated <time> + 1 minute that counts up indefinitely). When it keeps saying a time, people justifiably wait for it when it doesn't actually exist. After a long wait, chances are control will officially cancel it and that delayed train comes off the boards (if it's suitably late) which angers people even more. You've just waited ages for a train and it's gone? Where has it gone? You were lying to us all along. You don't have a clue.. etc.
If they could see the train that is coming in to form that service doesn't exist, more accurate information could be given automatically - leaving the TOC to concentrate on more detailed info on special services etc.