7EA gas turbine dropping out of base load


Thread Starter


We have noticed that our gas turbine sometimes drops out of base load. Most of the time we see this there is a disturbance on line and TTRXS drops below TTRXP and the unit backs down for a few seconds.

We set up a VIEW2T trend to look at some parameters to verify this with L60TTRX to be the trigger. Here is what we are seeing:

25:00.0 1 0 1 1026 1057 1026 1025 77.9 77 78.5 78 59.7 83.8 159.9
25:00.0 1 0 1 1026 1057 1026 1025 77.9 77 78.5 78 59.68 83.8 159.9
25:00.1 0 0 0 0 2048 1599 1019 256.4 256.4 256.3 256.4 64.09 3.4 124.9
25:00.1 1 0 1 1026 1057 1026 1025 77.9 77 78.5 78 59.68 83.8 159.9
25:00.1 1 0 1 1026 1057 1026 1025 77.9 77 78.5 78 59.68 83.8 159.9

It almost looks like communications were lost momentarily. Has anyone else seen this or have any thoughts to the cause?

Have you noticed what Diagnostic Alarms are annunciated prior to and during these events? Please list them.

Are there any error messages/counts being shown on any of the LCC/SLCC displays? If so, please list them--for each of the procesors (<C>, and <R>, <S>, and <T>).

The numbers are not believable, which is what I think you are referring to when you are saying there is a loss of communications. 3.4 DGA for the IGVs is not possible, usually not even if the IGV LVDT circuit is open does it indicate IGV angles that low (the mechanical closed stop should be about 32 DGA). And we can't see the whole time stamp so we don't know what the resolution is (though with VIEW2T it should be relatively fast, on the order or multiple times per second if it was set up correctly).

But, what kind of "line disturbance" are you referring to? Voltage spikes? Frequency excursions? VAr spikes? Gas fuel pressure/flow upsets?

What Process Alarms are annunciated during these events?

What Process Alarms are active and unresolved prior to these events?

What is the 125 VDC power supply voltage split prior to the event?

Does the unit use a DACA for AC-DC power conversion? If so, is the AC input clean--because the DACA does *NO* filtering of any kind and is actually known for making voltage spikes worse (by "amplifying" dirty AC signals into DC spikes which, if they exceed approximately 140 VAC can be problematic for the Mark V power supplies).

When the gas turbine drops out of Base Load does it load up again automatically or does an operator have to take action to get it to go back to Base Load?
When we set up the trend, we expected to see it last for a few seconds. Usually this "disturbance" would be accompanied by watt transducer alarms and we would also see line current oscillations. From talking to the utility it would normally be due to another generator coming online or a lightning strike.

The original intent was to see what was going on with the gas turbine during these disturbances. Once we set the trend, we started seeing these spurious and quick acting transients with no other process or diagnostic alarms. We don't see any errors on the processor displays. The data that was posted earlier had time stamps that were milliseconds apart.

We haven't seen any DC voltage diagnostic alarms but we will try to watch this closer.

When we see the longer (more than 1 second) transients, it looks like the GT sheds 5-10 MWs and then over corrects about 5 MWs then goes right back to base load without any operator action.
>What was the line frequency when the problem triggered?<

Our historian didn't see any changes with line frequency.
This is really odd. I forgot to ask the standard question:

<b>When did this problem start?</b>

There is usually some impedance between the generator and the utility and other generators (Main Step-up Transformers; utility transformers; etc.) so one would think there wouldn't be large "disturbances" on the grid. I suppose the exception would be on high-demand days if large generators tripped off or large blocks of load tripped off. Also, some utilities switch in and switch out capacitor banks for power factor correction. I wonder if something like that could be affecting the power system at your site.

It would be necessary to look at the sequencing running in the Mark V to know what happens when the watt transducer alarms are active, perhaps some unloading or runback. As for why it over-shoots, well, if the loading is fast enough sometimes a machine will load slightly past Base Load (exhaust temperature control) and then when things stabilize it will come back to Base Load (exhaust temperature control).

The problem could also be if the unit has load-biased exhaust temperature control for back-up (secondary) exhaust temperature control that the line disturbances are causing, as you said previously, to take over.

But, still, I've been at sites just a few hundred meters away from a switchyard with power factor correction capacitors that were being switched in and out and there was a palpable "thud" felt in the ground when that happened, and sometimes the overhead power lines even shuddered a little (swayed back and forth a few cm a little for a few seconds). But, we never experienced anything like what you're reporting and the units were at Base Load or Peak Load. The system voltage would change very quickly and the VAr and Power Factor readings would jump, but that would be the extent of the reaction.

You did not answer the question about the use of a DACA to provide back-up power to the battery. Again, they are famous around the world for making any voltage spikes on the incoming AC power to the DACA even worse on the DC output, causing processor re-boots in some cases. They provide NO filtering whatsoever, and the <CPF> Conditioning Power Filter in the bottom of most Mark V panels is really there to try to prevent electrical noise from the Mark V from getting outside of the panel to other equipment. It really is very small, and does very little filter incoming power.

I'm afraid I don't have anything more to offer, based on the information provided.
We don't have a DACA.

This issue may have been going on since the beginning of time. The only reason we noticed it was that in an effort to minimize spurious DCS alarms during startups and shutdowns, we inhibited some alarms based on the base load status of the GT. This signal comes into the DCS via modbus. When the GT drops out of base load, these alarms get momentarily inhibited and we see an alarm. Realistically, if we wouldn't have done that we would never have known.

One other thing to note is that occasionally when using the VIEW2T command, we'll see an odd date/time for the period that the event occurred. For instance, the date/time would be true for the entire period except for the few milliseconds where the GT was out of base. For those few milliseconds it will show a date/time that is a month/time/year off.
The only times I've ever heard of this happening is when there is a voltage spike on the DC supply (could be from the battery charger; output filter capacitors do go bad), or when the DACA gets dirty input power, or when there was a recommended PROM upgrade that wasn't done (usually per a TIL, Technical Information Letter).

In this case I would recommend you write down all of the card information and the PROM information from the cards in your panel. The DCC/SDCC, the LCC/SLCC, the TCQA, the TCQB (if present), the TCQC, the TCEAs, the TCDAs, the TCCA, the TCCB (if present)--in short, all of the cards that have PROMs on them. Write down the card number that is silkscreened on the cards as well as the PROM information. (For the PROM information, all you need is the DS200DENCF1BA, for example (I'm pulling that number out of thin air, just as an example). Do this for all of the cards, even though there are three TCQAs in each of <R>, <S>, and <T>. I'm including the TCQCs even though they don't have PROMs because sometimes there can be a mismatch in cards that cause weird problems because the IONETs run "through" the TCQCs.

[Sometimes, GE, in their infinite wisdom, used some adhesive labels to "change" the card designation. So, be sure to look the card over well, and if you see a card designation silk-screened on the card AND a thin, narrow, white adhesive label with another, similar designation, write them both down and include that in the list you are preparing.]

Once you have all of this information, you should go to the much-touted GE Controls Connect website (there are lots of threads with the link to the site), and if you haven't already signed up, do so. Then ask your question there, posting all of the information you have, including all of the PROM and card info as well. There are only a couple of people remaining in GE who can really look at a set of cards and PROMs and tell if they are all compatible, and up to the most recent revisions to cover all of the TILs and recommended PROM upgrades.

You have said this only seems to happen when there is a "line disturbance", and we still really don't know exactly what you mean by that. Have you asked the utility if they are switching out capacitor banks during these "line disturbances"?

Again, my money's on some power supply problem that's made worse by the "line disturbances".

But, those are only my best guesses based on the information provided. You say this has been going on since commissioning; that's a shame. It <b>IS</b> possible to have a completely alarm-free start-up to Base Load and shutdown to cooldown on a GE-design heavy duty gas turbine--it just takes some effort and tweaking to eliminate nuisance alarms. This is one of the things that gives Speedtronic panels a bad name: the number of nuisance and intermittent alarms. The overwhelming majority of them can be eliminated, even the Diagnostic Alarms (yes--even the Diagnostic Alarms!)--with some work, and, yes, it does on occasion require a PROM upgrade.

Please, if you pursue this through GE Controls Connect, write back to let us know what your experience was. We are all curious to know. I believe you can get good information and assistance from them, but you need to supply good information, and the sooner the better (such as in the original posting).


Further clarification...
Have your GT ever come across split phase/ loss of synchronism/ Out of step alarm or protection operated?
>Have your GT ever come across split
>phase/ loss of synchronism/ Out of step
>alarm or protection operated?

I have never seen any of those alarms.
Is there anyway to use VIEW2T and capture the P125/N125 and P15/N15 voltages or display them in other places than the diagnostic screens? I don't see them as points anywhere. What are their tagnames?

Those signals are not available to the CDB (Control Signal Database)....

I gotta believe there would be Diagnostic Alarms if these signals exceeded limits.

Unless someone masked them.


>> Have your GT ever come across split phase/ loss of synchronism/ Out of step
>> alarm or protection operated?

> I have never seen any of those alarms.

I will provide you with a hypothesis and I let you to accept or reject it via your available data and information.

The hypothesis...

You have power surge. Due to some reasons such power surge effected the speed signal that is used by the GT controllers. Two controllers require speed signal namely secondary response for frequency control and regulation, and primary response via speed droop. I would say at this point of time it was the signal for the speed droop that caused such problem.

If the speed droop had lost its signal, then one of the possible scenarios is the speed droop signal logic assumes maximum possible GT frequency. Since the droop mechanism was fed with very high frequency, it responded by reducing the GT output according to its percentage set point in and attempt to provide damping to system frequency rise. This is true since the speed droop control logic was designed to take over temperature limiter if GT frequency falls outside the certain frequency boundary.

Once the the speed signal recovered the droop made appropriate correction since the actual frequency is lower than the previous frequency, i.e. to increase GT load. You may see one or two freq oscillation after that. That is expected scenario.

The above hypothesis is not the only possible explanation. I have another one to share. But it has to go through illumination process before you can pin point the actual problem..