We are operating six GE Frame-VI GT with Mark V control System, TMR, Simple cycle, running on gas fuel.

The following spurious alarms frequently (say once in a month) receiving from all GT (at different time ).All our units are continuously in service last 4-5 months on natural gas fuel.

02:59:36.093 TRUE cooling water temp sensor fault
02:59:36.093 TRUE Compressor Inlet ThermocoupleDisagree
02:59:36.093 TRUE Gas Fuel Temp High Spread
02:59:36.093 TRUE Air AtomisingTempMeasureFault
02:59:36.093 TRUE Lube oil Thermocouple #1 Fault

02:59:36.625 False cooling water temp sensor fault
02:59:36.625 False CompressorInlet ThermocoupleDisagree
02:59:36.625 False Gas Fuel Temp High Spread
02:59:36.750 False Air AtomisingTempMeasureFault
02:59:36.750 False Lube oil Thermocouple #1 Fault

GE was suggested to do the TIL 1480-2 FIRMWARE UPGRADE. TIL is implemented but no change in the spurious alarm scenario.

All the above inputs (Thermocouple) are connected to <R> TBQA terminals and having redundant sensors. All the Exhaust Thermocouple also terminated in the same TBQA terminals. There are three ribbon cables, JAR,JAS and JAT are going to the three processors.'Lube Oil T/C #1 fault' this T/C is connected to the JAR cable terminals in TBQA.

This can happen if the JAR cable loose connection in either TCQA side or TBQA side or both.

This spurious alarms appeared in all GTs.

So this is not hardware problem???

Kindly share your experience

 

Hello,

Interesting problem, made all the more interesting because you say it happens for all six turbines on the site.

Please post the relevant sections from F:\UNITn\IO.ASG for one of the units. It's presumed the sections will be the same for all units; please verify they are the same for all units, and if not, post any sections that are different.

The two sections, each with at least three columns of information, we are interested in are:<pre>
TC01_16_31_V ............. TC ;
TC02_17_32_V ............. TC ;
.
.
.
TC14_29_44_V ............. TC ;
TC15_30_45_v ............. TC ;
<pre>and</pre>R_R_TC01 ............. TC ;
R_R_TC02 ............. TC ;
.
.
.
T_R_TC44 ............. TC ;
T_R_TC45 ............. TC ;
</pre>
We want all the information on each line between the initial entries shown above for each section (we don't care about anything after the semi-colon (";")).

Next, tell us how many T/Cs <b>are physically connected by wires to the Mark V</b> for each of the five groups of inputs. For example, if there are two L.O. Temperature T/Cs, and only one Cooling Water Temp T/C (or three), tell us how many of each of the five groups of sensors are connected to the Mark V.

Lastly, please describe the wiring on the various related terminals for the I/O that's causing the spurious alarms. For example, if the Gas Fuel Temperature T/Cs are connected to TBQA-21 & -22 and -51 & -52, and nothing is connected to -81 & -82, or if there is a jumper connected to -81 & -82, or if one of the T/Cs connected to -21 & -22 or -51 & -52 is jumpered to -81 & -82, let us know.

Now, that's a lot of information but it's all necessary to try to help understand and resolve the problem. Please be as descriptive and concise as possible. Even with this information, it still may not be possible to help you without being able to see the CSP from the site, but it's a start, anyway.

When posting the sections copied from IO.ASG., preface the sections with the 'pre' (in "carat" brackets as shown on the left of the 'Text' field in the response window of control.com). Then when finished with that section end with the '/pre' (in carat brackets). This will put the information in fixed-pitch font format (which is easier for all of us to read!).

 

IO.ASG is same for all six units

TC01_16_31_V TC01_16_31_V TC ;
TC02_17_32_V TC02_17_32_V TC ;
TC03_18_33_V TC03_18_33_V TC ;
TC04_19_34_V TC04_19_34_V TC ;
TC05_20_35_V TC05_20_35_V TC ;
TC06_21_36_V TC06_21_36_V TC ;
TC07_22_37_V TC07_22_37_V TC ;
TC08_23_38_V TC08_23_38_V TC ;
TC09_24_39_V TC09_24_39_V TC ;
TC10_25_40_V FTG TC ;
TC11_26_41_V TC11_26_41_V TC ;
TC12_27_42_V TC12_27_42_V TC ;
TC13_28_43_V TC13_28_43_V TC ;
TC14_29_44_V TC14_29_44_V TC ;
TC15_30_45_V TC15_30_45_V TC ;

--------------------------------------------------
R_R_TC01 TTXD_1 TC
R_R_TC02 TTXD_4 TC
R_R_TC03 TTXD_7 TC
R_R_TC04 TTXD_10 TC
R_R_TC05 TTXD_13 TC
R_R_TC06 TTXD_16 TC
R_R_TC07 WTAD TC
R_R_TC08 LTTH1 TC ;
R_R_TC09 CTDA1 TC ;
R_R_TC10 FTGI1 TC ;
R_R_TC11 AAT1 TC ;
R_R_TC12 CTIF1A TC ;
R_R_TC13 R_R_TC13 CNT15 ;
R_R_TC14 R_R_TC14 CNT15 ;
R_R_TC15 R_R_TC15 CNT15 ;
S_R_TC16 TTXD_2 TC ;
S_R_TC17 TTXD_5 TC ;
S_R_TC18 TTXD_8 TC ;
S_R_TC19 TTXD_11 TC ;
S_R_TC20 TTXD_14 TC ;
S_R_TC21 TTXD_17 TC ;
S_R_TC22 S_R_TC22 CNT15 ;
S_R_TC23 LTTH2 TC ;
S_R_TC24 CTDA2 TC ;
S_R_TC25 FTGI2 TC ;
S_R_TC26 AAT2 TC ;
S_R_TC27 CTIF2A TC ;
S_R_TC28 S_R_TC28 CNT15 ;
S_R_TC29 S_R_TC29 CNT15 ;
S_R_TC30 S_R_TC30 CNT15 ;
T_R_TC31 TTXD_3 TC ;
T_R_TC32 TTXD_6 TC ;
T_R_TC33 TTXD_9 TC ;
T_R_TC34 TTXD_12 TC ;
T_R_TC35 TTXD_15 TC ;
T_R_TC36 TTXD_18 TC ;
T_R_TC37 T_R_TC37 CNT15 ;
T_R_TC38 LTTH3 TC ;
T_R_TC39 T_R_TC39 CNT15 ;
T_R_TC40 FTGI3 TC ;
T_R_TC41 T_R_TC41 CNT15 ;
T_R_TC42 T_R_TC42 CNT15 ;
T_R_TC43 T_R_TC43 CNT15 ;
T_R_TC44 T_R_TC44 CNT15 ;
T_R_TC45 T_R_TC45 CNT15 ;

Following number of T/Cs are physically connected to MarkV (mentioned alarm group)

L.O. temperature T/Cs - LTTH - 3 nos
Gas Fuel Temp T/Cs- FTGI- 3 Nos
Comp Inlet T/C- CTDA – 2Nos
Air Atomizing Temp AAT T/Cs- 2 Nos
Water Cooling –WTAD- 1 No

LTTH is connected to TBQA 15&16 , 45&46 and 75&76
FTGI is connected to TBQA 19&20, 49&50 and 79&80
CTDA is connected to TBQA 17&18 and 47&48 is jumpered to 77&78
AAT is connected to TBQA 21&22 and 51&52 is jumperd to 81&82
WTAD is connected to TBQA 13&14 and jumpered to 43&44 and 73&74

 

Well, this is indeed more interesting all the time.

The alarms you listed are not Diagnostic Alarms, but Process Alarms, generated from blocks in the CSP. Are there any Diagnostic Alarms active at the time of these Process Alarms, or that come and go more or less with the timing of these Process Alarms? Specifically, any TCQA-related Diagnostic Alarms or any power supply-related Diagnostic Alarms?

I would say that if there were three CTD T/Cs, they should have been treated in IO.ASG like the three FTG T/Cs, voted by firmware.

Further, it was always my practice not to jumper T/Cs as you have described, but rather to just put a single copper wire jumper at the open terminals. So, for the open AAT terminals at TBQA-81 & -82, I would have just put a single copper wire between -81 & -82. Same for the open CTDA terminals at TBQA-77 & -78.

Unless there was some kind of control action other than indication or simple alarm (not trip) for the WTAD T/C, I would have connected it to <C> TBQA, or I would have put single copper wire jumpers between <R> TBQA-43 & -44 and another one between -73 & -74. I also would have deleted any error-checking on the WTAD, since there's only one T/C.

It's presumed that all of the signals feed into XPTS00 Parallel Transmitter Selector blocks which generate these Process Alarms. If so, what is the Alarm Differential setpoint for each of the blocks?

I'm really curious about the WTAD signal if it's passed to an XPTS00 block. If so, what are the other signals passed to that block for error-checking? If it's not passed to an XPTS00 block, how is the fault alarm for that signal generated?

From the time-stamps you listed for the alarms, they existed for less than one second. If that's always the case (they are annunciated, a logic "1", for approximately one second or less) I might have added a timer to each Process Alarm to say the fault would have to exist for more than one second. That may already exist, but we don't have access to the CSP.

The configuration you have cited is very curious and seems to be different from the practices used at the time Mark Vs were being supplied and commissioned. I'm not saying it's wrong, just different. It would seem that something common to these signals is causing the Process Alarms you are citing, but we don't know enough about the CSP and any other Diagnostic Alarms (related or unrelated).

I've always had bad luck trying to jumper open T/C terminals on these kinds of inputs with less than three T/Cs that were connected to <Q> (<R>). That's just personal experience, and rather than using XPTS00 blocks to generate fault messages just relied on the firmware to generate Diagnostic Alarms if any of the circuits went open.

 

All the jumpers are with copper wire only.

CTDA ...... 47&48 is jumpered to 77&78 with copper wire
AAT ....... 51&52 is jumperd to 81&82 with copper wire
WTAD ...... 13&14 and jumpered to 43&44 and 73&74 with copper wire

There is one Diagnostic alarm ‘Voter Mismatch <T> FPRG_INT’ persisting in one GT, and we know the reason for the alarm.FPG2 transmitter connected to <T> core is not matching with other two.Already planned for shutdown. There is no other diagnostic alarm persisting or erratically appearing before and after or along with these process alarm.

WTAD:- Two CMP blocks are used for alarm and it is always enabled (TRUE)
Set points are 80 Deg C and Zero Deg C, any one will give sensor fault alarm, no time delay.

LTTH:- Three CMP blocks are used, there is separate fault alarm for each T/C, set point is -8 Deg C , no time delay

FTGI:- XPTS00 parallel Transmitter selector block is used, alarm constant is 10 Deg C, no time delay.

AAT:- XIOCKOO-IO Check Block is used, there is BAD1 ( above or equal 200 Deg C), BAD2 (below 1 Deg C or equal) and spread High (set point is 10 Deg C)any one will give fault alarm, no time delay

CTIF - ISEL_HI Block Select, is used, different limit constant is 13.9 Deg C, no time delay for alarm

NOTE:- Instead of 'CTIF' I was written CTDA, wherever CTDA is there kindly read CTIF. Two CTDA T/C also connected same way in the TBQA.

Thanks for all help