MW Hunting in Fr-6B GT with Mark-VI control

S

Thread Starter

sdbarman

Dear All,

MW Hunting is observed in a Frame 6B Unit with Mark-VI Control. The observation and action taken has been summarized below.
Kindly suggest.

-- Megawatt Load hunting problem was encountered due to hunting of 65FP-1 Liquid Fuel Bypass Valve <T> Processor Servo Coil output Current.

-- Then we removed termination of T processor from Mark VI panel.After Removal of Cable terminal of Servo Valve from TSVO card, observed GT-5 unit Megawatt Load hunting problem was not occurred. It was concluded that, GT-5 Megawatt Load hunting problem is occurred only due to erratic behaviour of <T> Processor Connected TSVO Cable terminal of 65FP-1-Liquid Fuel Bypass MOOG valve.

- During observation, simultaneously checked the GT-5 Inter Connection Diagram (ICD) for the finding spare Pair cable.

- As per GT-5 ICD, it was found that Cable Tag No: GT2S002 - 12 Pair X 0.75 Sq.MM of cable is used/laid for 65FP-1-Liquid Fuel Bypass MOOG valve i.e. 03 No’s of pair for65FP-1-Liquid Fuel Bypass MOOG valve <R>, <S>&<T> processor of TSVO Card , 03 No’s pair for Magnetic pickup Speed 77FD-1,77FD-2 & 77FD-3 (77FD-3 is not used/connected in Mark-VI but at field 77FD-3 is available at Flow Divider), 01 No’s of Pair cable is used/connected for 77S- Diesel Engine Speed that means 05 No’s of spare pair cable is available as per ICD. Detailed Signal Flow path is as under.<pre>
Mark-VI Panel TSVO -2A4 :
JB - 1 JB-01 Moog Valve
--------------------------------------------------</pre>
Detailed Action plan was prepared for further problem rectification.
First Identified the cable Tag No: GT2S002 at Panel Bottom side then tried to remove the spare cable However, the same cable was found laid in between installed Terminal boards (deep inside) it is very congested place where spare cable was laid.

- In between New VSVO spare card has been replaced.

- Measured the Voltage of 65FP-1 LFBV moog Valve Servo voltage at TSVO – 2A4 card terminals.

1 TSVO-2A4 card for <R> Processor 33&34 -0.35VDC (Cable is connected)
2 TSVO-2A4 card for <S> Processor 35&36 -0.40 VDC (Cable is connected)
3 TSVO-2A4 card for <T> Processor 37&38 -12.31 VDC (When Cable is in removed condition)

- Measured the Voltage of 65FP-1 LFBV moog Valve Servo voltage at TSVO – 2A4 card terminals when VSVO Card is OFFLINE mode. <pre>
1 TSVO-2A4 card for <R> Processor 33&34 -0.35VDC (Cable is connected)
2 TSVO-2A4 card for <S> Processor 35&36 -0.40 VDC (Cable is connected)
3 TSVO-2A4 card for <T> Processor 37&38 -12.31 VDC (When Cable is in removed condition)</pre>
-- Now it was suspected that the problem may be in Mark-VI to JB-1 or JB-1 to JB-01.

-- We found Spare Pair Cable & Connection of New Pair cable instead of old pair cable at TSVO 2A4 Card Terminal: 37 & 38.

-- Old Removed pair cable from Mark-VI to JB-1 is ok.

-- In-between, we identified the Spare Pair Cable successfully & all 05 No’s of spare cables of continuity were checked from Mark-VI Panel to JB-1 found normal.

-- Field JB-1, Identified Spare Cable No: 9P& Moog valve cable is connected at new spare TB.

-- We did meggaring of cable laid from Mark VI panel to JB-1 and found 400 ohm. We checked continuity of cable from JB-1 to JB-01 and also found OK.

-- Mark-VI, New Identified Spare Pair cable No: 09 also terminated at panel side.

-- Also we mounted new Termination board (TSVO) at panel side and terminated all six wires of servo coils to it.

-- Servo Coil Resistance on each coil is 1.02 kohm from mark-VI side connection.

-- Voltages across terminals (with servo coils connected) for all three TBs (Mark-VI Side) during running is: 6.3vdc. (In Mark-VI Side TB 2A4: 33, 34: 6.3VDC, 35, 36:6.4VDC, 37, 38: 6.4VDC) while gt is running. While gt is not running then voltage comes 0.324vdc

-- During shutdown of GT-2 we have replaced the cable and megger the replaced cable from:
JB - 01 JB-1

-- Field Side (JB-01) Coil resistance is : white & red (R): 1.08kohm, Green & yellow(S):1.08kohm,Blue & orange(T):1.08kohm

Following Activity also completed:
a. Cut and redo the crimping of lugs for servo coil at all locations, especially the wires from <T> controller

b. Since the servo coil is replaced, check single coil polarity (if not done already)

c. Recorded the servo coil resistances on each coil at control panel end: Same as above

d. Recorded the voltages across terminals (with servo coils connected) for all three TBs before startup: Same as above

e. Record the voltages across terminals (with servo coils connected) for all three TBs during running: Same as above

f. Swapping connector from T- I/O net To S-I/O net In T-Processor. Result is same

g. Replaced Old Connector to new connector in T-Processor in T-I/O net. Result is same

h. Present Status is: Wire Removed from VSVO CARD for T-Connector, Enable Cur Suic: Disable & Enable Fbk Suic: Disable.

The same phenomenon was observed when Unit running in Gas too.
 
A lot of information, but not much actionable data. Thank you, though for providing the results of your troubleshooting!

The liquid fuel bypass valve reference (for all processors) is liquid fuel flow-rate, and the LFBV is positioned to make the feedback from the liquid fuel flow divider speed pickups equal to the reference. So, if the output is erratic it could be because the feedback is erratic.

<b>From the information provided,</b> it seems no troubleshooting was done to attempt to understand what might be causing <T>'s servo output current to fluctuate. And, from the information provided it would also seem that all of the wire changes had no effect.

This is an excellent time to use Trend Recorder--presuming the processor-specific values have been assigned individual signal names so they can be added to a trend. Even if they are not, it should still be possible to observe the Prevoted Values of flow divider feedback each processor is seeing. You want to look at ow divider feedback, as well as references and outputs.

If I understand the post correctly it would seem that <T> is also putting out an erratic output to either the GCV or SRV (it's not clear which) so the TSVO or VSVO for <T> might be suspect.

What Diagnostic Alarms are present on the suspect VSVO? That's always a good indication of possible problems. The Mark VI System Guide is one of the better sources of help for troubleshooting Diagnostic Alarms. Volume II will usually have Diagnostic Alarm help info.

So, from the information provided it seems the problem is NOT outside the panel--unless it's faulty or intermittent feedback. If I understand the post and details.

Please write back to let us know what you find!
 
Dear CSA

Thank you for your feedback. The trend data and diagnostic alarms have also been recorded and i'll post the details.

As a part of troubleshooting exercise the suspect <T> VSVO as well as TSVO cards as well as D-Connector cables have been swapped with the <S> ones (Which are healthy) but no change of problem status has been noted.

Best Regards.
 
sdbarman,

Please list the Diagnostic Alarms which are being annunciated for all the cards in <T>. If you've swapped cards/connectors between <S> & <T>, then the problem might reside in the <T> rack and/or power supply--which would likely be indicated with Diagnostic Alarm(s).

Have you tried putting a 1000 ohm resistor across <T>'s servo output to see if it is the wiring to the servo coil, or possibly the servo coil? You seem to have eliminated the wiring.
 
Dear CSA

The diagnostic alarms recorded are as follows:<pre>
<T> Slot 5 VSVO: Servo current #4 open ckt
Input signal"G5\fal" Voting mismatch

<T> Slot 1 VCMI:Using default input data,Rack T8
IONET-1 communication Failure
Using default input data,Rack R0</pre>
<R> and <S> do not show any diagnostics.
Slot 7 in <T> too do not show any diag. where IGV servo is terminated. Is it possible that a particular slot in the <T> rack can be faulty (In this case slot 5) or the rack Power supply?

We have not connected any 1KOhm resistance.
Please let us know how it helps.

Kindly suggest for further needful.

Thanks.
 
Dear CSA and everybody

Kindly suggest for any other troubleshooting clues

The diagnostic is reported only in the <T> rack as mentioned below.

> The diagnostic alarms recorded are as follows:<pre>
> <T> Slot 5 VSVO: Servo current #4 open ckt
> Input signal"G5\fal" Voting mismatch

> <T> Slot 1 VCMI:Using default input data,Rack T8
> IONET-1 communication Failure
> Using default input data,Rack R0</pre>
> <R> and <S> do not show any diagnostics.
> Slot 7 in <T> too do not show any diag. where IGV servo is terminated. Is it possible that a particular slot in the <T> rack can be faulty (In this case slot 5) or the rack Power supply?

> We have not connected any 1KOhm resistance.
> Please let us know how it helps.

> Kindly suggest for further needful.
 
sdbarman,

Yes; it's entirely possible that a single slot in a processor rack can have been damaged and cause the problem you are experiencing.

The reason I suggested connecting a 1K ohm resistor directly to the TSVx card for <T>'s output was to ensure the wiring was NOT the source of the problem. Since the servo coil resistance is (should be) approximately 1K, connecting a 1K resistor directly to the terminal board will serve as pretty positive proof of whether or not the interconnecting wiring/servo-valve coil is the problem or not.

If you have other ideas you would like to try and wish to have some input on these ideas, please--write them down and send them to us. When you are asking for help troubleshooting a problem and you are not getting the help you desire, it's because we don't understand the problem or there's something about the uniqueness of the installation that we don't know about (such as, maybe, the existence of IS (Intrinsically Safe) barriers in the circuitry that, while it may seem perfectly normal to you and other personnel at your site because that's the way the unit has always been configured, is NOT normal for the majority of heavy duty gas turbine installations around the world.

Because we can't see your site, and the wiring and configuration at your site, and the electrical wiring drawings for your site sometimes there's just not much we can do remotely to help troubleshoot a problem. In this case, you need to try things at site--and if you're not sure about what you want to try then ask about your plans here and perhaps we can help or provide additional information to help you troubleshoot the problem.

We are interested to help--and to learn what you discover the problem to be and how you resolve it--but there is only so much we can do without being on site to help with the problem. It would seem <b>from the information provided</b> that you've pretty much narrowed the problem down to a particular slot in the <T> processor rack. And, yes, they do fail--but usually ONLY when they are subjected to external voltage/current or a short or ground. That's why it's so important to understand what changed or what transpired just before the problem began so that troubleshooting can be narrowed down at the beginning.

As for troubleshooting a problem with a particular slot in a processor rack, well--that's not a simple task. I know of sites that have gone through the trouble of swapping racks to see if the problem followed the slot/rack (and it did), and then it's necessary to purchase a replacement rack. It's a lot of work, but the alternative is just to purchase a "new" rack and install it--and hope the problem was the slot/rack.

Again, it's pretty difficult to damage a slot in a rack without either inadvertently connecting an external source of voltage or current, or unless a serious short or ground occurs in the field wiring of the card in the slot. The processor racks are pretty robust, but can't withstand every kind of fault, unintentional or "natural." Also, we don't know if the site uses IS barriers for field wiring, which have been known to cause problems such as the one you are experiencing. We aren't there and we can't see what you see (you need to tell us as much as possible about the site and the configuration--because every Frame 6B GT site is <b>NOT</b> like every other Frame 6B GT site. Yes; all Frame 6B GTs suck and squeeze and burn and blow (draw air into the compressor; compress it; use the compressed air combust fuel and then expand the hot gases through a turbine; and exhaust to the atmosphere), but the auxiliaries and the wiring and can be VERY different even for exactly the same power output.

Help us to help you! There's only so much we can do, and we can't know everything about your site--only what you tell us.

Please write back with more information as you work towards resolving the problem.
 
sdbarman,

If you connect a 1K resistor to the TSVx card for <T>'s output and you STILL have the open circuit Diagnostic Alarm, then the problem may be the TSVx card.

I believe you have said you have tried replacing the cable between the TSVx card and the VSVO card in <T> (if not, that could be the problem--or maybe just loose D-sub connectors at either end of the cable). I do NOT recommend replacing the cable between the VSVO and the TSVx card without powering-down the processor. Shorting pins by trying to plug the cable in at either end with power on the processor is a very good way to damage the VSVO card--and possibly even the slot in the processor rack.

I believe you have said you have swapped VSVO cards between racks and the problem always seems to stay in <T>. Could be the cable between the VSVO in Slot 5 and the TSVx card, or the TSVx card, or the slot in the processor.

Please write back to let us know the results of your troubleshooting.
 
Top