Gas Turbine Trip without any alarm

Dear All,

We have a GE Gas Turbine unit with Mark IV+ control system. Recently, unit tripped 2 times without showing any alarm. We have an information system (from ABB) connected with Mark IV+ to work as historian and trender. We observed from there that all the parameters like NG pressure, CPD, Gas control valve (GCV), speed ratio valve (SRV) positions were normal then L4 is suddenly changing from 1 to 0. Then after 2 seconds, flame scanners, GCV, SRV, generator breaker all are going to trip status. However, L4T was zero all the time and didn't change. All the above observation were captured from the mentioned trending system.
Any ideas, what can trip the unit without initiating any alarms. Please advise.
 
I would suggest that you need to create a triggered trend, or a Dynamic Data Recorder to capture the trip. Most likely the historian you have only collects data at 1 second or slower and can't catch the trip. Do you have working data historian Triplogs that you can review? If so then this should help you understand what is tripping the machine. Most likely there is something that should be alarming for the trip that wasn't captured when you migrated from the MKIV to the MKIV+ that needs to be fixed once you figure this out. What frame size machine is this?
 
Dear MIKEVI,

Unfortunately, we don't have such historian triplogs. Actually we didn't migrate from MKIV to MKIV+. MKIV+ is installed from beginning. The machine is frame 9E.
Do you thinks that the failure of some relays like 4X or any other hardware may lead to tripping without alarm?
 
Transporter84, I am not familiar with the MKVI+ then, I was thinking it was a migration, sorry my mistake. Could you post any pictures of the hardware you have just so I can better understand what you have? I will be working on a MKIV migration to a MKVIe migration in the coming months so I assumed that is what you have.
"Do you think that the failure of some relays like 4X or any other hardware may lead to tripping without alarm?" With an older system anything is possible. Without any type of high speed trending or high speed data logging equipment it may take some effort to figure out what is causing the trip.
 
Dear,

Frame 9e there is a GE historian System take all log on real time and check first alarm on History Is this power plant is combined cycle power plant. there could be a trip related to customer which can be generated from HRSG, Or STG. Check Electrical protection system is it configure with Mark VIE. Check History from Switchyard side if there is tigered electrical protection. Share all Trip related alarm and Trends if any picture were taken from Protection panels. Check controller Diagonostic alarm were any of them is active from long time. Check DC system as well if Battery charger has any alarm active on that time,
Looking forward to your response
 
Dear Ghulam,

In our Mark IV system there is no historian system unfortunately. It is a combined cycle plant and yes there are some trips from HRSG but all shall be coming with some alarms, which is not happening in our case. We have no alarms in our DCS and also electrical panels are not having any alarm as well. Same also for DC system no alarm.
 
Unfortunately, without any information makes me unable to suggest any solution. For future consideration Ask Management to engage Historian system to have proper record for units.
 
Dear All,

We have a GE Gas Turbine unit with Mark IV+ control system. Recently, unit tripped 2 times without showing any alarm. We have an information system (from ABB) connected with Mark IV+ to work as historian and trender. We observed from there that all the parameters like NG pressure, CPD, Gas control valve (GCV), speed ratio valve (SRV) positions were normal then L4 is suddenly changing from 1 to 0. Then after 2 seconds, flame scanners, GCV, SRV, generator breaker all are going to trip status. However, L4T was zero all the time and didn't change. All the above observation were captured from the mentioned trending system.
Any ideas, what can trip the unit without initiating any alarms. Please advise.
Good day,

What is the operator interface that is installed at your plant ? Is that the CRT Operator interface ? Is there <I> DOS
 
After sain that.. Can You confirm that before that event, you got alarms annunciated.. And where did you read those alarms (I mean before incident)
I would advise again to troubleshoot the communication protocol..
 
Just wanted to update you guys, that we replaced the suspected components in the external "4" hardware circuit, such as Relays, 4R, 4S, 4T, 4X-1, 4X-2, 4X-3 & 4X-4. We replaced also HRDB & SIXL card along with the trip solenoid valve 20 FG. after that the issue seems to be solved.
 
Thank you for the update.

SO, that means the control system was a Mark* IV turbine control system.

The Mark* IV was GE's first "completely" digital, programmable gas turbine control system. It is a fine control system, BUT it does have one very nasty little "feature." If one of the three control processors detects the turbine should be tripped for some reason (let's say Low Trip Oil pressure) but the other two control processors DO NOT detect Low Trip Oil pressure the turbine will continue to run--BUT there will be Diagnostic Alarms--usually a bevy of Voter/Voting Mismatch Diagnostic Alarms--indicating that one control processor thinks the turbine should be tripped AND the other control processors do not. (One of those Diagnostic Alarms will indicate the respective 4 relay is not energized.)

Because of the way the Mark IV "votes" most things because only one control processor believes the Trip Oil pressure is low enough that the turbine should be tripped the Process Alarm TRIP OIL PRESSURE - LOW will not be annunciated. Two or more control processors must agree that a single trip condition occurs before the Mark* IV will annunciate a Process Alarm to indicate the turbine is/has been tripped. BUT, the Mark* IV is trying to warn a conscious operator there is a problem--by that bevy of Diagnostic Alarms.

Most people just think of Diagnostic Alarms as nuisance alarms, and because there can be so many of them, especially if proper maintenance and troubleshooting and resolution is not performed, they can seem like nuisance alarms. Why? Because if they are pretty much associated with a single control processor the unit continues to run. And, that reinforces most people's belief that Diagnostic Alarms are just nuisance alarms.

Here's where it gets really "interesting." Let's say in our example that a different control processor detects the IGVs are not following the reference and the turbine should be tripped. In this case, only one of the control processors is detecting that condition and it drops out it's 4 relay--meaning that TWO 4 relays are dropped out--meaning the turbine WILL BE tripped. BUT because only one processor detected the IGV problem there will be no Process Alarm to indicate the problem.

And here's the next BUT: There will be another bevy of Diagnostic Alarms indicating one of the control processors detected a problem that should result in the turbine being tripped--meaning there will be two groups of Diagnostic Alarms indicating Voter/Voting Mismatches. BUT NO PROCESS ALARM TO INDICATE PRECISELY WHY THE TURBINE WAS TRIPPED WILL BE ANNUNCIATED. Because TWO or more control processors must agree that a condition exists before a Process Alarm will be annunciated--ANY process alarm, not just those involving trips.

This is where printouts (or digital records) of alarms--Process Alarms AND Diagnostic Alarms--can be VERY useful in troubleshooting. very, Very, VERY useful. Particularly for Mark* IV turbine control systems which have this "interesting" feature and can result in turbine trips with NO Process Alarm to indicate the problemS (because in this case there are multiple problemS, not just one).

This is a very unusual little "feature" of the Mark* IV--but it can be very frustrating. It happens pretty infrequently, but when it does, it's very maddening. Later versions of the Mark* turbine control system had methods to prevent this kind of unannunciated trip, but with the Mark* IV there's no way to retroactively fix this "feature." BUT, again, it doesn't happen very often, but it does happen. And, I'm NOT saying this is precisely what happened at the site, but if there were multiple Diagnostic Alarms present and unresolved prior to the trip, it wouldn't be out of the realm of possibilities--and since there was NO Process Alarm indicating why the turbine was tripped, it is certainly possible this is what happened. Now, if there were other problems with physical electro-mechanical relays and ribbon cables and printed circuit cards that could also result in such a problem (no Process Alarm to indicate the reason for tripping). But, I believe there would have been other Diagnostic Alarms that were warning of issues that weren't being addressed and resolved.

There's another method, using the Auxiliary Display, to troubleshoot problems like this--but most Aux. Displays are unusable because the elements of one or more of the digits don't work properly. So, one really has to rely on properly reading and understanding and troubleshooting and resolving Diagnostic Alarms.

So, if you're new to Control.com, use this opportunity to try to provide as much information in your original post as possible to help us help you. It would have been helpful to know what turbine control system was being used on the unit. It would have been helpful to know what other Process Alarms and Diagnostic Alarms were present BEFORE the trip occurred and AFTER the trip occurred. But, moreso, going forward it will be MORE HELPFUL for you and others at the site to understand problems like this. I know that the printers on Mark* IV are old-school and require ribbons and paper and can get easily disturbed--but, they are the ONLY way to properly troubleshoot problems like this. You may have a third-party control system at the plant that can capture information--but it's slow and probably DOES NOT get alarm information from the Mark* IV. There are some sites which have replaced the printer with an old laptop computer with a hard drive to capture printer information for troubleshooting and analysis. This is a VERY good idea, not the easiest thing to implement and to keep up-to-date, but it doesn't involve replacing ribbons and paper. And people CAN be trained to capture and store the alarm data for use in troubleshooting.

There you have it. This is NOT a reason to disrespect the Mark* IV--it's a FINE turbine control system, that's been around since the early 1980's, a testament to how well-built it was and how with good maintenance (even some not-so-good maintenance) it has lasted decades and still is a very good turbine control system.
 
WTF?

Thanks for your elaborative explanation and useful details. In our case actually, there was neither process alarms nor diagnostic alarms. That's why we were not able to trace anything.
 
Then it's something electrical (relays or printed circuit cards--which you've replaced) or a loose wire or a failed or failing solenoid or solenoid mechanism.

And I hear that ALL the time--when I first arrive at the site. "No. No Diagnostic Alarms. And the printer hasn't worked in decades."

But then someone sidles up at some point in the next couple of days and admits, "There may have been some Diagnostic Alarms which didn't get any attention; there usually are lots of them. Nobody ever pays attention to them because we can't understand what they mean. AND, they never cause the turbine to trip."

Adeus.
 
Just wanted to add one information,

There were couple of process alarms appeared with trip, however, these 2 alarms are not related to turbine protection trip logic L4T.
these 2 alarms are "turbine Inlet Air drop" & "Generator transformer trouble"
we checked the elementary drawing and the above alarms are used for alarm only
 
Top