We have four gas turbines at or site, three of them are operated via Mark-V and one of them is operated via Mark-VI.
All gas turbines are frame-5 machines of with capacities of 24.6MW (Mark-VI), 13.8MW, 13.8MW and 11.2MW.

The turbine operating on Mark-VI indicated a difference in its MW reading in two megawatt transducers. Both transducers were reading 14.9MW on their local display but in Mark-VI dwatt_1 was reading as 17.2MW and dwatt_2 was reading as 14.9MW. Now due to high selector logic of Mark-VI, dwatt was reading as 17.9 MW. The range of both megwatt transducers is -1 to 35 MW.

This difference was gradually increasing. So it was decided to check the mA signals coming from the transducers to Mark-VI termination boards. To check the current in these transducers loop, we had to disconnect the loop and check the loop current. For this activity the value of dwatt_1 was forced to 17.2 MW. After the checks, the signal dwatt_1 was unforced but suddenly the value of dwatt_1 jumped to 41.72MW, causing the gas turbine to suddenly shed its load to as low as 0.5MW. The logic was forced back in order to avoid the tripping.

So after experiencing the above explained scenario, there are a few questions that need to be answered:

1. As mentioned above, there is a HIGH SELECTOR to select the high MW value. Logically speaking, if one of the transducers failed, its value should go down rather than going higher so that it is ruled out from the calculations. Is there any logic in Mark-VI which identifies failed MW transducers & rule them out from the calculations. Furthermore, if the transducer failed, why did the value jumped up to 41.72MW, 20% above the maximum limit. Is it a fail safe?

2. When the transducer value was read as 41.72 by Mark-VI, why did gas turbine shed the load so rapidly? (Trends show the load was shed in about 9 seconds). Since the gas turbines are running in droop mode, why the FSR was not controlled by the speed control block?

3. Since it is now known that one of the transducers has failed and considering that the turbine is running at a load of 17.2MW, at what value should the unhealthy transducer be forced to avoid any undesirable consequences?

Kindly also comment the role of dwatt signal in FSR calculation during normal operation of the gas turbine.

Any help would be appreciated!

 

RameezAbrar,

Is the Mark VI SIMPLEX or TMR?

What are the Diagnostic Alarms being annunciated for the dwatt_1 input card on the Mark VI? (These are checked using Toolbox.)

What other Diagnostic Alarms are being annunciated on the Mark VI?

Does the Mark VI-controlled unit have DLN or conventional combustors?

Do the two MW transducer devices have the same kind of output (mA; VDC)? If they are not the same, which device has which type of output?

Was the Mark VI-controlled unit operating on Pre-Selected Load Control or some other kind of external load control (from a PMS (Power Management System), or DCS, or ?) during the time the mysterious unloading occurred?

How did you resolve the problem--by disconnecting, and leaving disconnected, the input to dwatt_1?

It's not clear from your post exactly how many MW the Mark VI-controlled unit was actually producing at the time of the MW transducer input difference. Was it actually producing 17.2 MW or 14.9 MW?

And, you said that when you unforced the feedback from dwatt_1 and its value went to 41.72 MW, you somehow knew the load went to 0.5 MW--was that from dwatt_2, or some other meter/transducer feedback?

GE heavy duty gas turbine control systems generally one of two types of Droop speed control: "straight" Droop speed control, and, the poorly-named Constant Settable Droop speed control. In the first, the difference between the turbine speed reference and the actual load determines FSR (FSRN, specifically; and this is straight proportional control, in complex terms).

In the second, the turbine speed reference is converted to a load signal and the algorithm adjusts FSR to make the actual load equal to a load-based speed reference (in more complicated terms, there is integral control in addition to the proportional control). So, in this case, if the load feedback is higher than the actual load then the Speedtronic is going to reduce FSR to reduce load.

In <b>BOTH</b> types of Droop speed control, when operating with Pre-Selected Load Control, or Remote Load Control, the turbine speed reference is proportional to the Load Setpoint. So, when the load feedback exceeds the load setpoint, Droop speed control is going to reduce load.

Yes; there is a HIGH SELect block, and that's because, as you rightly noted, the typical failure mode for these types of transducers is to fail low--hence that's why the high value of two values is chosen as DWATT for control purposes.

The Mark VI analog inputs do have high- and low-signal Diagnostic Alarm setpoints, but those are rarely configured.

What was the result of your check of dwatt_1 while it was disconnected from the Mark VI? (We presume you disconnected the output of the transducer (96GW-1?) from the Mark VI to check the signal.) Why was it decided to reconnect it to the Mark VI?

To answer the numbered questions:

1) Yes; the Mark VI can be configured to check the health of incoming signals and then use that status to rule them out from calculations--but it's rarely used except on MUCH bigger turbines for critical inputs (not that this isn't a critical input; it's just that sometimes the methods employed on some machines don't get used on all machines, especially since now different geopgraphical locations are producing GE-design heavy duty gas turbines and each have responsibility for the control and protection of the units they produce--and one site in particular doesn't really do anything any other division of GE does, because they are allowed to be loose cannons).

There's no way, based on the information provided, to say with any degree of certainty, why the signal jumped--except to say that it is possible, I believe, to look at the Pre-Voted Value of signals in a Mark VI (using Toolbox) to see what the value would be before unforcing it.

2. See above.

3. I would say the unhealthy transducer should be disconnected and repaired as soon as possible. But, we don't know if the transducer is unhealthy or not--because you didn't tell us what the results of the check were when it was forced and disconnected from the Mark VI. Forcing signals is not a recommended way to operate a gas turbine--it's a last resort, and forcing/unforcing without understanding all of the implications and how to check signals before unforcing them is really just asking for trouble (like this).

So, it would be great if you could answer all of the questions above; we might be able to offer some more information. And it would be great to know how the transducer driving dwatt_1 was determined to be unhealthy, and why, it if was determined to be unhealthy it was reconnected to the Mark VI and dwatt_1 unforced?

The intent of the HIGH SELect block/logic is to choose the more commonly correct value in the event of a failure in the most common manner--a open circuit or loss of signal output which would result in a low or negative MW value. (This type of logic, using the predominant failure modes of redundant devices is used extensively in GE-design heavy duty gas turbine control and protection. It's one of the things that makes Speedtronic turbine controls so reliable--but it doesn't protect against every type of possible failure; again, it's used for predominant failure modes--not every possible type of failure mode. And, enabling the "healthy status" bit of inputs and using that status to reject values has also been known to cause other unintended problems, which is probably one reason why it's not commonly used.

In this case, forcing the higher of two inputs to a HIGH SELect block probably wasn't a good choice--and neither should it be for the interim while the "unhealthy" transducer is repaired.

From the information provided, it may not even be the transducer output that's bad--it may be the input channel on the analog input card the transducer driving dwatt_1 is bad. There may be a problem with the card, or it's input resistor or something.

Another question which is always very important to ask when things like this happen to units which have been running without problems for some time: When did this problem start? Was some work or configuration done to this transducer's inputs, or the output wiring, or a terminal board in the Mark VI replaced, or a cable in the Mark VI replaced? Have you checked all of the "brown/black" cable connectors between the analog input terminal boards for these signals and the Mark VI processor rack(s)? (This SHOULDN'T be done while the unit is running, and great care should be used if power is applied to the Mark VI when checking these cables--especially if one comes loose and has to be plugged back in. It's very easy to short pins in those D-sub connectors on the cables used to connect the I/O terminal boards to the processor rack(s).)

Hope this helps--again, if you can write back with the answers to the questions above (all of them--even if they don't seem applicable to you, they are important to helping understand the problem for the rest of us), we can probably be of more help. But, without the answers (to all of the questions) we can't be of much more help. Remember, a LOT of people read these posts and learn from them, so the more information you provide the better it is for others. We try to help the original poster--the person with the problem--but we also try to help others as they are learning and maybe experiencing the same or similar problems.

Also, there are more than 12 years of Speedtronic-related issues on control.com--all of them accessible using the 'Search' feature!

 

Dear CSA,

Let me first summarize the event again and then I'll respond to all your queries.

Incident:
We experienced load shedding of our Frame-5 Gas Turbine (GT-604) on 14-June-16 at 14:00:51. There are currently two transducers on the turbine and high selection logic is used for DWATT calculation. It was observed that there existed a difference in the MW readings of these two transducers and the difference had an increasing trend. At the time of incident, the values read were:<pre>
dwatt_1: 17.8 MW
(abnormal value & it was increasing)
dwatt_2: 14.9 MW</pre>
The value from another system (Intelligent load management system - ILMS, Schneider Electric) was also noted as 14.9MW which verified the correctness of transducer#2. It was decided to check the 4-20mA current of transducer # 1 (Make: Dief). For the activity, the value of dwatt_1 was forced. Current output of transducer # 1 was checked and it was found to be okay. The local display of transducer # 1 was fine as well, so there was no issue with the transducer. When the circuit was reconnected and the value was unforced, dwatt_1 value jumped to 41.443MW. Because of the high selector logic, the FSR value decreased and the turbine shed load very rapidly. The value was again forced and turbine regained the load. This could have resulted in complete site black-out.

1. It is to be noted here that the range set in Mark-VI logic for this input is -1MW to 35MW. Even if the channel fails, (only R core diagnostics, out of the RST cores shows the channel as unhealthy) it is supposed to be considered unhealthy and disregarded as per our understanding. Kindly explain how it jumped to 41MW. Furthermore, shouldn't a high limit also be configured for this critical input so it is considered unhealthy if the value exceeds 35MW.

2. For now, transducer# 1 value has been forced to 1MW to ensure a good margin for Operations to control GT-604 load. If the other transducer fails in this scenario, the high selection logic will cause a very high FSR value and this will result in immediate load gain. Please guide as to what should be done in this situation. We aren't unforcing the dwatt transducer again because of high risk.

Response to your queries:

1. Mark-VI is configured for our frame 5 single shaft turbine in TMR configuration. There are no diagnostic alarms on S core and T core but on R core, the following appears:<pre>
" fault code 50
Status 1
Analog Input 19 unhealthy 6.516205"</pre>
Analog input 19 is transducer # 1. No other diagnostic alarms are currently appearing on the system.

2. Mark-VI unit has conventional combustors

3. The turbine operates on Droop mode. We have an intelligent load management system (ILMS) which basically distributes load among the four turbines. The turbine is on Auto-Droop mode.

4. Currently the issue hasn't been resolved and we have had to force the value to 1MW for dwatt_1. This will give the operations department a good margin to control the load. We considered the option of a new channel configuration but that would require minor online downloading and we have had hanging issues with the VCMI cards earlier so we can't risk that either. It is to be noted here that this turbine is the most critical one because its shutdown would translate to production losses.

5. The Mark-VI controller was producing 14.9MW originally.

6. The load went to 0.5MW. This can be seen from the trends extracted from ILMS (reliable). Its not visible on Mark-VI because the trends only get plotted for voted value DWATT. The boardmen however also confirmed seeing the value on the other HMI.

7. The high failure set-point wasn't configured, as has been rightly pointed out by you. This is one of our concerns since if what happened is possible upon channel failure, there should be high limits set for the critical IOs.

8. The issue started on 13th and the activity was performed on 14th June. No work was done prior to this and even during the job, only the termination board was touched. Also, the higher value wasn forced but it was brought lower so the healthy transducer was in fact in control. When unforced, the value jumped to 41.5MW and so dwatt_1 became in control.

I hope these answer the queries. Kindly let me know if any further data is required.

Best regards,
HS

 

Hira/RameezAbrar10,

>1. It is to be noted here that the range set in Mark-VI
>logic for this input is -1MW to 35MW. Even if the channel
>fails, (only R core diagnostics, out of the RST cores shows
>the channel as unhealthy) it is supposed to be considered
>unhealthy and disregarded as per our understanding. Kindly
>explain how it jumped to 41MW. Furthermore, shouldn't a high
>limit also be configured for this critical input so it is
>considered unhealthy if the value exceeds 35MW.

As Speedtronic panels have evolved over the decades, more and more and more features have been added. The division of GE that makes the Speedtronic turbine control systems doesn't always communicate all of the features, their usefulness and their configuration to the divisions of GE that purchase, configure and sell the Speedtronic turbine control systems with their turbines. The organization of the company doesn't lend itself well to communication, and lots of features go unused. Some divisions that buy and use the Speedtronic turbine control panels discover the features and use them; some don't. Some of the features do not really work as intended, and aren't applied as intended--meaning they "don't work."

It's understandable that Customers would feel that all of the features should be--and are--used in their Speedtronic turbine control panel. But, it's not always the case. And, it appears to be the case that the 'health bits' aren't used in your application. (And all features aren't intended to be used in every application--which is one of the detractors of Speedtronic turbine control systems: they have too many features that can be misapplied if not properly analyzed and thought through and configured. And even then, sometimes the intent isn't always achievable.)

Without being able to see exactly how things are configured in your Mark VI, it's impossible to say what was or wasn't done. 35 MW is a pretty high value for a Frame 5, but, I've seen them hit 35 on transient conditions--and that's because the Mark VI was able to record the values from the transducers.

But I have other questions below which may prove helpful--if you'll indulge me.

>2. For now, transducer# 1 value has been forced to 1MW to
>ensure a good margin for Operations to control GT-604 load.
>If the other transducer fails in this scenario, the high
>selection logic will cause a very high FSR value and this
>will result in immediate load gain. Please guide as to what
>should be done in this situation. We aren't unforcing the
>dwatt transducer again because of high risk.

The HIGH SELect block chooses the higher of the two signals--if you disconnect a 4-20 mA signal from the input to the block scaled at -1 to 35 MW, the signal will go to -10 MW (-25% of full range, subtracted from the minimum range value), and that will certainly be less than dwatt_2. There's no need to force anything--just disconnect the two wires from the transducer driving dwatt_1. That will solve that problem.

Without being able to see the configuration of your ILMS and the Mark VI, it seems there MUST be an external load control signal input to the Mark VI from the ILMS for the load setpoint. In this scenario, the Mark V would indeed have chosen the abnormally high signal and unloaded the unit.

<b>OR</b> the ILMS seems the HIGH SELected DWATT signal from the Mark VI and the ILMS uses discrete raise and lower signals to the Mark VI to raise/lower load and when it saw the abnormally high signal the ILMS sent a lower signal (or a series of lower signals) to the Mark VI which drove the load down. It's difficult to imagine it's not one or the other--but we just don't have enough information to know which it is, or what it is that caused the Mark VI to lower load. You say the Mark VI is in Auto-Droop mode--but that doesn't mean that some kind of external load control signal (4-20 mA) or signals (discrete raise- and lower signals) are driving the load of the Mark VI. I believe you're saying that Pre-Selected Load Control isn't being used--but you did not respond to that specific question. In re-reading the past posts, I'll bet it's discrete outputs from the ILMS to all of the GTs--but that's just a SWAG (Scientific Wild-Arsed Guess).

Now for the REAL crux of this issue:

>It was decided to check the 4-20mA current of transducer # 1
>(Make: Dief). For the activity, the value of dwatt_1 was forced.
>Current output of transducer # 1 was checked and it was
>found to be okay.

Exactly HOW was the output of the Dief transducer checked and determined to be okay? What test equipment and devices were used to check the output of the Dief and decide it was okay?

When you are looking at the dwatt_2 input (or any input to the Mark VI), there IS a way to see the prevoted value of the input (I don't have access to Toolbox at this writing, and I don't recall exactly how to do it--but there IS a way to do it). And after reconnecting the input and before unforcing it someone should have looked the prevoted value of dwatt_1 and seen it was abnormally high--and then NOT unforced it.

There's either:

1) something wrong with the way the output of the Dief transmitter was checked;

2) something wrong with the way the output of the Dief transmitter was reconnected to the Mark VI;

3) something wrong with the Mark VI input channels (at least two of them);

4) something about the circuit of the dwatt_1 input we don't know (is the output from the dwatt_1 transducer connected in series with some other device?);

5) something amiss with the hardware jumper position on the TBAI--you said dwatt_1 is assigned to Analog Input 19. That means it's one of two circuits that can be either a +/-1 mA input or a 20 mA input; the other 18 Analog Inputs can be either VDC or 4-20 mA inputs. The choice of whether Analog Input 19 is a +/-1 mA or 20 mA input is dependent on BOTH the configuration of the input in Toolbox <b>AND</b> the position of hardware jumper J9A on the respective TBAI.

Has anyone confirmed BOTH the Toolbox configuration of Analog Input 19 <b>AND</b> J9A on the respective TBAI as both being set for 20 mA input? Is it possible that someone moved J9A before or after reconnecting the Dief transducer input to the TBAI?

There's also hardware jumper J9B, which generally should be IN, but some transducers which are self-powered require the hardware jumper J9B to be out (if the output signal is grounded at the transducer end--not the shield drain wire, but the output signal itself--some transducer outputs are grounded at the transducer; some are not; refer to the manufacturer's instructions).

6) the Dief transducer input was not reconnected to the proper terminals of the TBAI after it was "checked" and found to be okay.

7) something is wrong with the VAIC Analog Input channel 19, or the cables that connect the TBAI to the VAIC(s). (This not very likely, but it is a possibility that is relatively easy to rule out.)

8) something is amiss with the twisted, shielded pair cable or it's shielding that connects the output of the Dief to the Mark VI; either the shield drain wire is grounded at both ends (and it should be grounded at one end only), or there's a cable integrity issue (nicked insulation; etc.). This is because it was said in the original post, I believe, that dwatt_1 had been seen increasing over some time prior to the incident--which generally means noise on the input wiring or some degradation of the input channel on the Mark VI.

There are just too many things we don't know about the configuration of the systems (ILMS and Mark VI) and how they are interconnected, and what was done during the testing of the Dief output and the re-connection of the wires to the TBAI.

If the site has a 4-20 mA simulator (and many of the better VOMs (Volt-Ohm-Meter) have 4-20 mA output simulators) you can disconnect the Dief wires and connect the output of the simulator to the input of the Mark VI (making sure the J9A and J9B jumpers are in the proper positions, and the wires are connected to the proper terminals!), and slowly raise the output of the simulator and watch the dwatt_1 signal to see if it follows the simulator output. This would help to determine if it's a VAIC/TBAI problem, but it does have some risk if you're going to do this with the unit running.

As for whether or not there should be more error-checking on this mA input, again--the predominant failure mode of transducer inputs is to fail in the low (zero mA ouput) direction. And, the use of the HIGH SELect block prevents against the predominant failure mode--not against every failure mode, but the predominant failure mode.

A lot of minor downloads are done by selecting 'Download to all three processors' and that seems to cause problems. It's always recommended to download to one processor at a time when doing on-line downloads. And, simply reassigning a mA input shouldn't be very disruptive. You could even try enabling another input, setting the hardware jumpers on the TBAI correctly, downloading the configuration changes individually to each controller, then connecting a simulator to the inputs to see if it works correctly. The problem with moving dwatt_1 to another input is that dwatt_1 is probably on the EGD, and that may cause a major difference.... Sometimes it does; sometimes it doesn't.

So, the questions for this go-round are:

1) What are the positions of J9A and J9B for Analog Input 19--now, and what were they before the troubleshooting incident? If they were changed, why were they changed?

2) How is load controlled on the Mark VI--by what kind of signal from the ILMS (mA setpoint, or discrete RAISE/LOWER inputs)?

3) How does the ILMS know what the load on the Mark VI is? Does it have its own mA input, or does it share one or both with the Mark VI by connecting it in series with the mA inputs for DWATT?

4) Exactly HOW was the mA output of the Dief checked and determined to be okay? The display of the transducer can be okay, but the output isn't necessarily okay. What test equipment was used, and what were the results?

5) Has anyone checked the twisted, shielded pair cable and its shield drain wire between the output of the Dief and the input to the Mark VI to be sure it's good?

Also, if you simply disconnect the input to the Mark VI the signal is going to go negative, which to the HIGH SELect block makes it unusable.

Please write back with the answers to the above questions. Or use the list of possibilities to systematically eliminate them until the root cause is found. We are very curious to get to the bottom of this problem. After that we can discuss the 'health bit' and how it might be used to give you the protection you believe the input should have.