Dear all,

We have one problem in our control system Mark IV+ for GE frame 9 Gas turbines in DEWA- Dubai. I hope that somebody is having idea or can advise us.

When turbine is in shutdown condition there was no alarm, but after giving start command the following alarms are appearing:

* Master start up protective lock out.

* diagnostic alarms for <T> controller voting mismatch for so many parameters (L4QA, L4QB, LTN_MAX, L4X1, L20FG1X, L94X1, FQ2, FSRSR, FPRG, FSRS1, DSR2, FSROUT,....) and so many other diagnostic alarms all for <T> controller only.

We replaced already the HMPJ (processor module) of <T> controller with new one, but still problem is persisting. After reaching to FSNL we restarted the <T> controller, and then all alarms are resetting. But during every start-up the same problem is happening.

Waiting for your valuable ideas.

Best regards,

 

Transporter,

When this occurs, you need to review all of the Diagnostic Alarms and you will likely find the "culprit."

Or, and this is a long shot, you can use the Auxiliary Display to review the (Process) Alarm Drop numbers of <T> to see what caused <T> processor to think the turbine should be tripped.

For a Process Alarm to be displayed on the <OPM> and logged to the printer, it has to be detected by two processors (when it's a <Q> alarm). When only one processor sees a trip condition, a lot of Diagnostic Alarms are annunciated, BUT <T> will display the Alarm Drop Number in the Auxiliary Display. You can use the Mark IV manuals and the magnetic plaque above the Auxiliary Display to learn how to view the Process Alarm Drop Numbers. You will need to scroll through all of the Process Alarm Drop Numbers in <T>, writing them down, and this needs to be done before you re-boot <T>. The Alarm Drop Numbers will be in chronological order; I believe the first one you encounter will be the last alarm to be detected/annunciated. Some of them will be the same as what's on the Alarm Display, but some will not. You can find which trip condition occurred first (probably closest to the last Alarm Drop Number) and that will likely match one of the Diagnostic Alarms neat the "bottom" of the display of <T> Voter Mismatches.

Please write back to let us know what you find!

 

Dear CSA

Thanks a lot for your response

I have already all the diagnostic alarm drop numbers for <T> because it is appearing on the alarm list under the diagnostic alarm display.

The point is, the order of alarms is not always the same, some time it is coming first for L4QA and some time for FPRG. so, I am not able to identify what is the root cause for it.

Regards,

 

Transporter,

The Diagnostic Alarm drop numbers are not important. It's the Process Alarm Drop Numbers from the Auxiliary Display for <T> that are important.

And, it's NOT always the first alarm in the list that is the cause of the problem. In some cases it depends on when the problem is caught during the execution of the sequencing scan, but without being able to see the sequencing in the Mark IV+ at your site it's impossible to say for sure.

You mentioned FPRG; does the unit have redundant P2 pressure transducers? If so, are confident of the calibration of all three transducers over the entire range of the calibrated range? In other words, do you know that the output is entirely linear with respect to the sensed pressure over the entire calibrated range of the transmitter? Is it possible that the transmitter connected to <T> has some non-linearity at the low end of the range? Because I believe you have said you are able to re-boot <T> once the unit reaches rated speed, and if (we don't know because you haven't shared ALL of the Diagnostic Alarms with us!) <T>'s P2 pressure input isn't agreeing with <R>'s and <S>'s that could be the problem.

My suggestions would be to <b>carefully</b> vet the Diagnostic Alarm list very carefully and the next time the unit is started have the suspect values on the Logic Forcing Display so you can see the values in all the processors.

Because, I suspect the Auxiliary Display digits are all working (it hasn't been maintained or used for decades), or you don't want to take the time to learn how to scroll through the Alarm List using the Aux. Display. Once you have the Drop Numbers from the Aux. Display (presuming the display is working properly) you need to refer to the 18 sheets of the Mark IV Speedtronic to learn what each drop means, and then use a logical process of elimination until you arrive at the cause.

If you want more assistance, provide the ENTIRE list of Diagnostic Alarms AND Diagnostic Alarm text messages, along with the time (date is not important) that occur when <T> thinks the turbine should be tripped. And, if you can obtain the Process Alarm Drop Numbers from the Auxiliary Display, provide them (denoting the order--from newest to oldest, or oldest to newest, depending on how you scroll through the list) AND the Alarm Text message for each alarm from the 18 Sheets of the Mark IV Speedtronic elementary.

 

Transporter,

I recall using the Trip Display (Data List 10) on the CRT, which lets you see the current values as well as the "frozen" values for numerous pertinent signals, for EACH processor. Since the frozen values were frozen at the time of the trip on that particular processor, it may let you get some clues as to what signals to further explore. You have to look before you re-boot.

CSA may have some additional thoughts on using the Trip Display.

 

Dears

Thanks for your response again
But since I posted last time, the GT was not started again.

Just I want to refer to one point. maybe it can give you some idea.

During start up when this problem is happening, the red LED of the <T> controller HMPJ processor module is not glowing. I believe this is related to the communication between <C> and <T>, so it will be like this until I make restart again for <T> controller at FSNL.

Is there any meaning we can get from this point?

And again really thanks for your help

 

Transporter,

Something else you should have noticed is that when this problem occurs, the 4T relay LED is not lit. This is all to be expected when <T> is trying to trip the turbine for some reason.

As be_anon has suggested, you may be able to use information from the Trip Display (Data List 10) to help you understand or work towards understanding why <T> thinks the turbine should be tripped. The problem I have run into over the years is that sometimes the Trip Display was not properly configured to include all of the conditions that resulted in a trip. But, if I recall correctly, it should point you in the direction of whether the condition is a Pre-Ignition Trip (L4PRE), a Protective Status Trip (L4PST), or a Post-Ignition Trip (L4POST). Then you can go to the appropriate sheets in the Speedtronic elementary, or to Rung Display (Data List 12, if I recall correctly) to try to understand which specific condition is causing one of these groups of trips to try to trip the turbine.

Or, you could learn how to use the Auxiliary Display to scroll through the alarm list of individual processors and when the turbine is started and <T> tries to trip the turbine you can record the Alarm Drop Numbers (Process Alarm Drop Numbers) and use that to isolate the problem to a specific condition.

And, when you do this, if you compare what you find to the list of Diagnostic Alarms it is likely you will find the condition was also alarmed (Voting Mismatch) as a Diagnostic Alarm.

Please write back to let us know what you find. Please include ALL of the Diagnostic Alarms from <T>, and if possible, the list of <T> Process Alarm Drop Numbers from the Auxiliary Display, as well as any information you obtain from the Trip Display. When providing the list of Process Alarm Drop Numbers from the Auxiliary Display, you will need to include the Alarm Text Message for each Drop Number from the 18 sheets of the Speedtronic Elementary.

By the way, using the Auxiliary Display when the turbine is cranking/running <b>WILL NOT</b> cause the turbine to trip. You can practice using the Auxiliary Display when the unit is shut down. The list of Process Alarm Drop Numbers for <R>, <S>, and <T> should be exactly the same when the unit is not running.

 

Transporter,

The red LED that is not lit is probably the "outputs enabled" indicator. If the processor is tripped, that LED would be out.

 

Master protective lock out usually pertains to the fuel or hydraulic systems servo output cards HSAA. and their associated feedback LVDT's. Do a calibration of the fuel control valves, IGV's, and or any other servo actuators and you will most likely find the bad actor.

Alternatively get a different HSAA card, set up the berg jumpers and start swapping them around until you find the bad actor. Be careful, your headed for a shutdown.