• Our booking engine at tickets.railforums.co.uk (powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!

Breakdown (or more?) on ECML

Status
Not open for further replies.

elementalpat

Member
Joined
7 Nov 2011
Messages
81
This seems to have been a problem all day!

Seems to be taking ages to fix a broken down train, so I was wondering if it was much worse (like a fire).

Surely, they would have moved it ASAP.

Anyone got any further details?
 
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R

RailUK Forums

91101

Member
Joined
25 Oct 2007
Messages
439
Its like this:

There is a line block from Stevenage to Biggleswade on both up lines.

Up trains are doing a double shunt to access the down fast, and thats being worked under SLW to allow moves in the up direction. Adding complication is the fact that trains are coasting under Hitchin OHNS in the up direction (obviously for those not paying attention, this is still on the down fast). Obviously, its one train in section on the DF from BIW to SVG.

The story about a broken down train is actually incorrect, there seems to be a problem with 365's doing both SLW and COASTING, causing a problem with the AWS, but thats where it all started. An FCC train was stuck in the coasting/SLW section for about an hour. With a back up of 6 trains by the end of that incident, including another two FCC. The second FCC went through and had the same fault as the first , job stopped for another hour whilst it tried to go back so by this point its just a mess.

When you consider that there is a double shunt, and then a hell of a long section to be gone through its just meant that everything for both FCC and EC has been totally out of kilter, stock and crew.

The service for both is still on its knees, and I doubt it will be fully back to normal till tomorrow.
 

elementalpat

Member
Joined
7 Nov 2011
Messages
81
Wow... wonder if they should have anticipated this or not? (Sorry, I don't have a lot of tech knowledge about the railway, just a fan! :lol:)

Sounds like there will be some serious questions to be asked whenever the big guys meet about this incident.
 

91101

Member
Joined
25 Oct 2007
Messages
439
I think its the combination of two degraded modes of working, both the SLW and the coasting.
 

Dr.iver

Member
Joined
19 Feb 2011
Messages
62
Well I predicted the chaos in advance and i'm mightily glad I'm not working today. IMHO coasting with pans down is a recipe for disaster and needs removing from the rule book, their are far too many variables that can stop a train and when this happens in a dead section the job is royally screwed.
It doesn't help that with a 365 you are not just putting the pan down but putting it into DC mode which has its own problems .
Absolutely crazy trying to run a service through engineering works like this, buses should have been used alongside pbo to Biggleswade and Stevenage to kings cross shuttle services.
I dread to think what will happen tomorrow with fans heading to the football at the Emirates
 

91101

Member
Joined
25 Oct 2007
Messages
439
EC Seem to have increased the number of HST's down south today, but that could have been my imagination?

I think coasting has its place, but that place is to mitigate against service disruption, a minor dewirement, or a few droppers off to avoid stopping the job, but not something like this, not planned engineering works!
 

A-driver

Established Member
Joined
9 May 2011
Messages
4,482
365s are having problems coasting-when they lower the pans the AWS goes off and they were not cancelling causing a break demand within the dead section. On one occasion (think it was the 2nd of the 3 trains to fail) the back pan was still on live wire so they could isolate the front one and set back but the other 2 needed a thunderbird to rescue them (which needs an emergancy coupler).

After the 3rd Failiure they started instructing 365 drivers to isolate AWS before coasting through the dead section and provided a fitter at stevanage to re-instate it.

Funnily enough this happened a few years back when they last had coasting through a dead section. Interesting to see if they try and run FCC services through the single line section on the next 2 weekend closures coming up.

Obviously dosnt help that they don't leave enough time for any trains to realistically clear the single line section.

Plus didn't help Hitchin to Cambridge being closed as prevented east coast from running via march, but then again the reason for the block was to replace the points at Cambridge branch junction.

Think I saw this evening live departures saying 1 train every 3 hours to peterbourgh from FCC!
 

stut

Established Member
Joined
25 Jun 2008
Messages
1,899
Yes, I managed to get caught up in this mess today, took 2 hours from BIW to KGX, but the FCC side seemed to be sorted by about 8pm.

The return was interesting - the 2318 was a stopper, effectively replacing 3 services and crammed into a 4-car. Plenty fragrant by the time I left.

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?

(Also, it would be nice if the EC services waiting to shunt at BIW could pick up stranded passengers. I assume there's a good reason why not, but it's rather annoying having to wait much longer only for a stopping service to appear!)
 

91101

Member
Joined
25 Oct 2007
Messages
439
No FCC train was rescued with a Thunderbird.

All three of the ones that had AWS issues were able to roll back into live sections of OHLE.

The thunderbird, which had been sat at WGC was deployed to Stevenage for 2P09, but never used, it remained at SVG platform 3 for the remainder of the day.
 

PTF62

Member
Joined
26 Jun 2008
Messages
192
Yes, I managed to get caught up in this mess today,

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).

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. Topped off by the station staff at Stevenage giving out wrong and misleading information to the delayed passengers.
 

NSEFAN

Established Member
Joined
17 Jun 2007
Messages
3,504
Location
Southampton
There was also a signal failure at Newcastle yesterday. I was on 1S15 KGX - INV. After waiting 20 minutes for a route into the station, we were told that we had to reverse and use the High Level bridge, and then reverse again at Newcastle in order to continue our journey.

We were nearly an hour late leaving Newcastle, but it was a nice suprise diversion. :D
 

Schnellzug

Established Member
Joined
22 Aug 2011
Messages
2,926
Location
Evercreech Junction
has anyone yet come up with a plausible explanation as to why the premier main line in the country is such a fiasco? Yes, it's very busy. Surely, therefore, that should mean that they should take extra special care to make sure that it runs properly. The Mallingford to Titfield branch seems to be better run.
 

Mike C

Member
Joined
18 Nov 2011
Messages
161
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?
 

Whistler40145

Established Member
Joined
30 Apr 2010
Messages
5,911
Location
Lancashire
Is it my imagination, but I haven't heard of trains in other parts of the country coasting through a dead section of OHLE, usually the blockade would be long enough for rail replacement transport.

Also, on a matter of safety, I would have thought the Rail Unions wouldn't have been very happy at the thought of disabling the AWS during coasting.


---
I am here: http://tapatalk.com/map.php?3igvap
 

Schnellzug

Established Member
Joined
22 Aug 2011
Messages
2,926
Location
Evercreech Junction
i suppose if they're running wrong line, the AWS wouldn't be operative anyway; So is this dead section significantly longer than neutral sections usually are? It rather sounds as if it's a case of 'hope you're going fast enough to get to the other end'.
 

Welshman

Established Member
Joined
11 Mar 2010
Messages
3,017
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! :)
 

34D

Established Member
Joined
9 Feb 2011
Messages
6,042
Location
Yorkshire
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! :)

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.

Well done to FCC for trying to do their best and not just simply resorting to buses.
 

Schnellzug

Established Member
Joined
22 Aug 2011
Messages
2,926
Location
Evercreech Junction
But honestly, and i do apoligise for talking Total Rubbish, these fiascos happen every single day on this benighted railway line in some way or another. What's wrong with it? Why does it go wrong so often?
 

millemille

Member
Joined
28 Jul 2011
Messages
353
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?

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.
 

A-driver

Established Member
Joined
9 May 2011
Messages
4,482
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?

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.

Also on 317s when you go through a neutral the headlight goes out and so technically by the rule book you have to proceed at 20mph with no headlight. I know it's stupid during the daytime but they are not too keen on bending rules. I doubt you would get all the way through the dead section at 20 (although they were only doing 40 through it anyway).
 

Mike C

Member
Joined
18 Nov 2011
Messages
161
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.

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.

Do you know how long the coasting section was in this case?
 

jon0844

Veteran Member
Joined
1 Feb 2009
Messages
28,013
Location
UK
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.

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'.
 

tsr

Established Member
Joined
15 Nov 2011
Messages
7,400
Location
Between the parallel lines
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'.

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.

It's a great pity that the people who run the Twitter feed cannot type two or three lines of explanatory text into platform displays and onto the front page of their website, all at the same time. In addition, I'd be interested in a trial of remote announcements broadcast to affected trains - like an on-board radio station for emergencies, similar to the one in operation on the Dartford Crossing for road vehicles - in all situations where a delay of more than 20 minutes (or thereabouts) occurs.

I think the real root of the problem is the fact that often no reliable estimate can be given of the magnitude of delay to each train, so passengers often wait fruitlessly. Where a precise arrival/departure time isn't known, I don't think the word "Delayed" should be shown - instead, a simple line of text saying "Timetabled: --.--; Expected: --.--; Delay: Up to -- minutes" could be implemented, with "Expected --.--" and "Delay: Up to -- minutes" added as needed, and numbers replacing "-", of course.
 

jon0844

Veteran Member
Joined
1 Feb 2009
Messages
28,013
Location
UK
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.

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.
 

tsr

Established Member
Joined
15 Nov 2011
Messages
7,400
Location
Between the parallel lines
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 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.

FCC 377s can probably display the most information, but the MiTrac computer might be a bit complicated to set up to handle anything more than the most basic tasks.

Some 377s have built-in internet connections, but no FCC ones have this functionality enabled, as far as I am aware.

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.

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.

FCC do seem to resort to the word "Delayed" an awful lot. Sometimes I think that "DOO" stands for "Delayed Only Operation"...
 
Status
Not open for further replies.

Top