Mark-V trip during fuel changeover

H

Thread Starter

HANY SALEH

We are facing a problem when making change-over from Gas to Oil. First we start with fuel gas smooth operation till we reach full speed and GT was loaded to about 5 MWatts. Then we select from DCS fuel change over to Oil (our Bailey DCS connected by serial link to MarkV system). At this time we start priming for fuel oil lines. After about 6 seconds the turbine trip and next 3 alarms came at the same time:
Q 72 TRUE PALARM PROTECTIVE MODULE OVERSPEED TRIP

Q 73 TRUE PALARM PROTECTIVE SPEED SIGNAL TROUBLE

Q 512 TRUE PALARM EXTERNAL TRIP TO (P) 4 RELAY CIRCUIT

We checked all operating conditions before the trip from the trip log display and it was OK, even the speed did not increase to overspeed and it was normal.

Our system is Simplex, Mark-V Frame V GE GT, we have 3 TCEA cards so we do not expect the problem in it as turbine is working good with fuel gas, only this problem during fuel changeover from gas to oil. We do not know what is the relation.

We replaced the trip relay (TCTG) but the problem is not solved.

Can anyone help us to solve this problem?
 
R

Radhakrishnan

Will you please some additional information? Please answer the following questions:

1. When did this problem start?
2. Did you modify configuration or replace any cards, before the problem started?
3. What type of Mark V panel is used - TMR or Simplex?
 
H
The problem started when we trying to test fuel changeover afetr about 3 monthes of not testing it.No modification was done for H/W or S/W before problem starts, our system is simplex.
the strange thing is that The trip occures direct after about 5 seconds from giving the order for changeover.
 
B
Do you have a historian that you can look at? If so, does the MWATT increase significantly before the trip? I'm not sure how you could overspeed while synchronized to the grid? If you put a lot of extra fuel to the machine, it seems that the load would go high. I've seen a unit trip on high exhaust temperature due to excessive fuel, but overspeeding a sychronized machine would take a lot. Are you isolated from the grid (Island Mode) when this happens? Have you checked your liquid fuel supply system to make sure it is controlling fuel oil flow properly? I've seen the servo valve on the fuel valve break. I've only worked frame 7's so I'm not sure of the similarities. The servo valve failed and drove our fuel supply valve wide open causing a tremendous load swing and then a trip on high exhaust temperature.
 
From the second alarm you noted, there appears to be a difference between the speed pick-up inputs to <R> and <P>, that's what the second alarm means.

An "overspeed" trip from <P> can occur on a excessive rate of change of speed inputs to <P>, and that can be an excessive rate of increase or decrease. So, I wonder if somehow there is some problem with Liquid Fuel Flow Divider speed pickup wiring and turbine speed pickup wiring, causing some kind of cross-talk.

What Diagnostic- and Process Alarms are present before the transfer is selected?

But it just seems like there is some kind of "linkage" between turbine speed pick-ups and flow divider speed pick-ups for this to be occurring, like when the Liq. Fuel Stop Valve opens there is some kind of "spike" in flow divider flow-rate sensing which is being picked up by the turbine speed sensing circuit?

There have been lots of reported cases of the Mark V detecting Liq. Fuel Flow when running on gas fuel, which have been traced to wiring problems. This may be a case of leaking check valves allowing combustion pressure to cause air to collect in the piping from the Liq. Fuel Stop valve to the fuel nozzle, and when the Stop Valve is opened and Liq. Fuel Forwarding Pump pressure causes a sudden flow-rate increase through the bypass valve and the flow-divider up to the check valve that the spike is somehow being detected by the shaft speed sensing circuitry, since they all usually come back to the Speedtronic via the same main junction box and multi twisted-shielded pair cable. It's a guess, since we're not there--but stranger things have happened.

This illustrates the great need to perform frequent, periodic fuel transfers to keep the system reliable and detect problems before they adversely affect reliability.

Have you recorded and VIEW tool data during these failed attempts?

Have you looked at the Trip Log data to see if there is anything noticeable in that data?

But, let's not overlook the last alarm you cited, the external trip input. This is one of those really cryptic alarm messages that you should really take the time to understand, and modify if necessary. You really need to understand everything that can cause this alarm to be annunciated, even if it's only one condition, but in my experience it's usually more than one. It's not easy, but you need to understand what causes this alarm to really understand the whole sequence of events. It may be related; it may not. But you need to understand what causes this alarm on your unit. Unfortunately, it's kind of a "catch-all" alarm indication and can be caused by one or more conditions in my experience.

Finally, there is one little "quirk" of alarm annunciation that this case is a good illustration of. You say that all three alarms came in at the same time, which I presume to mean at the same instant in time (down to the millisecond). Note that the alarms are annunciated in order of alarm drop number (72, 73, 512). When more than one alarm (Process or Diagnostic) alarm occurs during the same scan of the CSP, the alarms are reported to the display and the printer by order of the drop numbers--not necessarily which alarm occurred first during the scan, because it doesn't make any "difference" which alarm occurred first during a scan. All Process Alarms which occur during a scan are reported (annunciated) at the end of the scan in order by their drop number, as you have shown (or we think you have shown, since it's presumed you reported them in order as on the printout, *and* that they occurred at the same millisecond). In any case, multiple Process Alarms occurring during the same scan of the CSP are reported in order of drop number.
 
Top