Site Power Outage Due to Underfrequency


i have gone through the Trip logs and my analysis also matching with your analysis.

GT-1 is almost near to base load and both GT'S are running in droop mode.Demand after tripping of 3rd unit 4MW the additional demand which needs to be shared by other 2 GT's as they are in droop mode.

Both GT's are shared the load upon trip ,however as there is no frequency control mechanism so system frequency reduced and units ( droop mode) were trying to compensate this by increasing FSR.

Exhaust temperature raised due to frequency drop & FSR increase due to droop error. GT-1 is running near to base load so FSR temperature control hit and unit started unloading and in turn entire unit frequency start reducing further because GT2 also not able to maintain the required additional demand as this also hit the FSRT limit and therefore this disturbance went into closed loop so units are tripped on under frequency.

This will happen when additional demand due to other unit trip/unloading is not able to achieve other units and no frequency control .

i think usually external loads ( usually which are not important to process ) will cut off either from GRP or load dispatch control system in order to safe the plant.

i also observed that IGV was not opened immediately (4to 5sec delay) after load sharing from 60% in GT2 . look into this whether it is due to lag in logic or re- calibration required.

Sorry but I was away at a customer site for the past 2 days. CSA was kind enough to help out.

I do not recall from any of your posts if your units are controlled by a MKVI or a MKVIe. If you want to share your logic in some way, either the .m6b file if a MKVI control, or an archive of your system if a MKVIe we can review your application code.
This is really going to be the only way to understand why unit #2 came out of ISOCH mode which would be important so this does not occur again. My guess is that possibly the signal L30TXA which is the exhaust overtemperature alarm may have been the cause. But without seeing your exact application code it is just a guessing game.

Please let us know if you can provide further data or require more assistance.

>2) Why did GT_2 IGV not open to max?

IGVs and IGV control are very misunderstood are not used to reduce exhaust temperature in the event of high exhaust temperature. For most combined cycle applications (such as our friend Makster's) the IGVs are used to MAXIMIZE exhaust temperature during Part Load (less than Base Load) operation. And, they are not, in my experience, ever used to decrease exhaust temperature if it's too high (meaning it's more than 25 deg F above the normal maximum allowable exhaust temperature reference).

With <i>normal, typical</i> GE sequencing (and Hitachi pretty much follows normal, typical GE sequencing--for the most part!) when a unit is placed into Isochronous Speed Control the operator has NO control of unit load--NONE. The unit responds automatically to load changes in order to maintain the frequency setpoint. Makster said, and I quote:

>Before the event, all the generators were in service. GT-1
>was running at 19.6MW, GT-2 at 21.6 MW (Iso), Tornado at 4MW
>and STG at 10MW. We initiated the shutdown of tornado
>turbine due to maintenance <b><i>after creating margin in GT-2 and
>bringing it down to 17MW.</i></b>

EXACTLY how was the load of GT-2 brought down to 17 MW??? Was load shed somewhere in the plant to do this? Because if Pre-Selected Load Control was used to put the unit at 17 MW from 21.6 MW, then that would have likely canceled Isochronous Speed Control and put GT-2 in Droop Speed Control (Pre-Selected Load Control is an "outer loop" to Droop Speed Control only--it doesn't work in Isochronous Speed Control!). And, in fact, Makster said when the Tornado unit tripped BOTH units accepted the SAME amount of load: 2 MW. Which would mean both units were in Droop Speed Control.

So, the main question here is: How was the margin "created" in GT-2? Because operators are not typically given control of the load when a unit is Isochronous Speed Control.

I AM presuming there is no load/frequency control in the plant that is sending signals to the units to control frequency (these are sometimes called "Power Management Systems" or "Load Control" (when they are really frequency control!) systems). If there is, well, then all bets are off here because we didn't know about that and we don't know how it works or if it was working. We have been presuming the plant is exactly as Makster described: One unit in Isoch; the rest in Droop, and the unit in Isoch was controlling plant/system frequency. And, in a normal, typical GE heavy duty gas turbine control system when a unit is in Isochronous Speed Control operators--and even external control systems--do NOT control the load of the Isoch unit. Now, there are some control schemes used on GE-design heavy duty gas turbine control systems called "isochronous load sharing" systems, and those are rather complicated and requires lots of signal sharing between control systems. But, Makster didn't mention anything about that.

It's just not clear how the margin in GT-2 was created. In a typical, simple system with no PMS or load control system the only way one can change the load of an Isochronous unit is by changing the load of one of the other units operating in Droop Speed Control. (That's NOT a typographical error!) One cannot change the load of the Isoch unit directly with the Isoch unit's control system. If the load is stable (meaning the number of motors and computers and computer monitors and lights and tea kettles) is stable and not changing, if one increases the load on one of the Droop units that has the effect of decreasing the load of the Isoch unit. And, if one decreases the load on one of the Droop unit that has the effect of increasing the load on the Isoch unit. That's the way the load of an Isoch unit is typically changed.

OR, if the number of motors and computers and computer monitors and lights and tea kettles can be reduced (without changing the load of any Droop unit) the load on the Isoch unit will automatically decrease. (And conversely, if the number of motors or lights or computers and computer monitors or tea kettles) increases the load on the Isoch unit will automatically increase (presuming the operators did not change the load of any of the Droop unit(s)). And, this is the way the Isoch unit controls frequency: By responding to changes in either the system load (the number of motors and computers and computer monitors and lights and tea kettles) or changes in the load of one or more of the Droop units--when there is no PMS or load control system.

So, Makster. How was margin "created" for GT-2? Did an operator, or some external control (a PMS, for example) change the load of the system or of GT-2? Because if the Mark VI is a typical Mark VI, then if something tells it to change load while Isoch is selected and active the Mark VI will (normally and typically) automatically de-select Isoch and go to Droop. And, we've all pretty much agreed: Both the GTs were in Droop; neither was in Isoch. (Again, we are presuming a "simple" system with no PMS or external load control.)

By copy to MIKEVI, I believe Makster said in one of his posts the Hitachi units have Mark VI controls. (But we both know that people say Mark VI when they often mean Mark VIe.... Which causes a LOT of confusion for everyone!)
Dear CSA,

Thanks for detailed insight. We create load margins at site by keeping droop load constant, and then periodically switching off non-critical motors in field, thereby reducing load on ISO machine. We do not have any PMS or 'Load Control' at our site, and we do this load shedding manually. We have a Hitachi turbine with Mark-VI control system (not Mark-VIe).
Dear All,

Thanks for your detailed inputs. We have gone through a detailed discussion with GE and seem to have concluded the issue. However, if some of you can still point out something fishy, I am open to it.
As per GE, our normal understanding of Iso and Droop behavior during load pickup (i.e Iso will take up all the load and droop won't) only works when the Droop turbine is running at its base load i.e maximum capacity. If there are still margins left in droop turbine IGVs, Iso and droop machines will share the sudden load. The ratio of load sharing varies and cannot be determined exactly.

So, in our case, when sudden 4MW load was put on the network; GT-1 (droop) went from 19.6MW to 21.4MW. At that time, its exhaust temperature logic took over and turbine tripped on exhaust temperature. This is straight forward!

Now comes the fishy part. During the same time when the 4MW load came, GT-2 (Isoch) tried to take the load by increasing its GCV opening from 39 to 41 suddenly. At the same time, a sudden drop of 1 bar is observed in intervalve fuel pressure (P2) which means SRV did not respond as rapidly as GCV had opened. This resulted in reduced fuel flow at that very instant and GT-2 did not take the load it should have. When GCV saw that still turbine speed was decreasing, it increased its opening to 43%. At that time, P2 was on recovering trend which means fuel flow had returned to normal. This resulted in extra fuel injection in turbine which increased its exhaust temperature. At this time, L30TXA took over and turbine temperature mode was active. Whole system went to underfrequency (47.4Hz normal 50Hz) and both GT-1 and GT-2 Generator breakers opened resulting in site blackout. (Steam Turbine had already tripped after GT-1 tripping on exhaust temperature due to a in-house interlock).

GE Recommendation:
1) It seems the SRV is not able to maintain the P2 pressure and triggered the event. It is recommended to inspect the SRV for mechanical damaged on actuator.

2) The null bias of the SRV servo is set as 3 it is recommended to check same and replace the servo if the calculated null bias is still 3.

3) The IGV could have avoided the event if it was traveling little fast we can increase the IGV gain CSKGVTPG from 0.36 to 0.45 this will help IGV to move little fast to control the exhaust temperature (went from 60 deg to 64 deg in 10sec).

Now I want to know what exactly is the null bias of a GCV/SRV servo and how can I calculate it?

>As per GE, our normal understanding of Iso and Droop
>behavior during load pickup (i.e Iso will take up all the
>load and droop won't) only works when the Droop turbine is
>running at its base load i.e maximum capacity. If there are
>still margins left in droop turbine IGVs, Iso and droop
>machines will share the sudden load. The ratio of load
>sharing varies and cannot be determined exactly.

This is, indeed, extremely fishy. That's not the way a simple system with one unit running in Isoch and one, two or more units running in Droop works. Not at all. The Droop units will ONLY change their load IF the system frequency changes. Otherwise, their load will remain stable. The Isoch unit will pick up as much load as it can until it reaches CPD-biased exhaust temperature control, Base Load, (and the definition of CPD-biased exhaust temperature control means the IGVs are fully open AND the actual exhaust temperature (TTXM) is equal to the calculated exhaust temperature limit (TTRX)). At this point, the Isoch unit can't accept any more load. If this were the case at your plant--the Isoch unit was at Base Load (CPD-biased exhaust temperature control) what would then happen would be the frequency would start to decrease and the Droop unit(s) would start to increase their load to try to stabilize and support the system. The Droop units <i>by themselves</i> (that is, under normal automatic Droop Speed Control--without Pre-Selected Load Control active!) WILL NOT restore grid frequency--the operator would have to manually increase the turbine speed reference(s) of the Droop unit(s) to return the frequency to normal.

What is Base Load for these two machines on a day similar to the day the event occurred? In other words, what would Base Load for each of the two H-25 machines have been on the day when the event occurred? 25 MW? 21.6 MW? 23 MW?

So, shutting off motors to create margin on the Isoch unit was the correct action to take in preparation for taking the Tornado unit off-line. Where I'm having lots of problems in understanding what happened is you said in your original post that GT-2 (which was believed to be in Isochronous Speed Control) was unloaded to 17 MW by shutting off some motors. GT-1 was at 19.6 MW. Then, when the Tornado unit tripped you said BOTH GT-1 and GT-2 went to 21.6 MW--meaning they each took on 2 MW. Which is EXACTLY what would happen if both GT-1 and GT-2 were on Droop Speed Control.

It's possible that fuel supply issues and/or fuel control valve issues caused the units not to behave properly even though GT-1 was on Droop Speed Control and GT-2 was, in fact, on Isochronous Speed Control. Many things are possible, but many things are also unlikely.

Now to address the even <i><b>fishier</i></b> business about null bias current. The topic of null bias current has been addressed many, MANY times on (You can use the 'Search' feature of to look up past threads discussing null bias current.) The typical null bias current value for ALL electro-hydraulic servos used on GE-design heavy duty gas turbines is -2.67%. The null bias current is a field-adjustable value, meaning it can be changed. And, the allowable range of null bias current values is -1.33% to -4.00%. (Some GE turbine control systems automatically invert the null bias current value, so it's not necessary to use the negative sign when entering the value in the null bias field.) A value of 3 seems perfectly fine (it's actually very close to 2.67). There are literally thousands of GE-design turbines running around the world right now with null bias current values of 2.67 which are running perfectly fine. (And, probably many with a null bias value of 3, too.)

There is a "procedure" for calculating null bias currents, but it's extremely questionable AND it can lead to all manner of knock-on problems if not done properly. It's really only necessary to change the null bias value if--and only if--the LVDT calibration is verified to be correct but the actual position of the device (the GCV or the SRV or the IGVs) differs by a large amount from the reference position. And, there are literally hundreds of GE-design heavy duty gas turbines around the world with actual positions that differ by various amounts from the reference position (some by a LOT!) and they all run just fine (they all start and synch and produce power, some a little better than others).

Without knowing a LOT about the condition of the equipment at your site (hydraulic actuators; electro-hydraulic servo-valves; oil cleanliness) it's impossible for us to comment on the null bias current value. I'm also not going to go into how to check the null bias of the SRV or GCV; if you can't find LK90DB2 or other values in Toolbox using Finder, you are going to have a very difficult time stroking valves. You can read other past threads on for that information/learning. Many inexperienced GE field service personnel also recommend either "calibrating" valves or IGVs when something like this happens, or they recommend replacing the electro-hydraulic servo-valve(s). It's expensive to do either, especially without knowledgeable people to do the work, and can lead to other unintended problems (such as with calculating null bias servo currents). And quite often, neither resolves the original problem. Servos and LVDTs and AutoCalibrate are all very misunderstood and there are many widely-shared myths and falsehoods about all three (mostly because GE has never published proper documentation about any of them--nor how they all work together).

I also seriously question the statement that the IGVs could have prevented the problem if they had opened faster. AGAIN, IGVs are NOT used to reduce exhaust temperature when there is a problem. Opening the IGVs will cause the air flow through the turbine to increase--which means the power being produced by the turbine and used to drive the compressor will cause the compressor to draw even MORE of that power from the turbine which will leave even less available to produce amperes in the generator, and less amps means less MW. IGVs are NOT the problem here; not at all. The IGV gain may be a little low, but it's not the purpose, function or job of the IGVs to prevent tripping on exhaust overtemperature.

If the unit is in exhaust overtemperature the Mark VI is NOT going to try to add any more fuel to the unit. If the IGVs were to open further, then the power required by the compressor would increase leaving LESS power to drive the generator and this would also contribute to a decrease in unit speed--which will decrease air flow even more. It's a spiral that should not happen, not by design (meaning the IGVs are not designed to open to decrease exhaust temperature!) and not even by accident. It might seem like the IGVs could be used to reduce exhaust temperature in the event of a high exhaust temperature--but that's not what really happens. Ever. IGVs are used to increase exhaust temperature, up to the calculated CPD-biased exhaust temperature limit. This means that more steam will be made in the HRSG at low loads. The IGVs are also used to control air flow in units with low emissions combustion systems, which it doesn't seem your units have. But, they ARE NOT used to reduce exhaust temperature when the unit exhaust temperature is over the allowable CPD-biased exhaust temperature limit (when the exhaust temperature is in alarm).

This is an extremely insightful post and I thank you for that. I personally suspect that when GT-2 did not take full load (When GCV opened to 41% and P2 dropped by 1 bar), GT-2 speed decreased and consequently frequency of the system decreased. This caused GT-1 to take up the load in droop mode that it did. I will review the data again and come back to you after determining when exactly GT-1 took the load or what was the frequency when GT-1 took the load. This whole game happened in milliseconds and unfortunately we do not have a GE historian to record all the parameters.

Regarding your discussion on null bias, what can then be a factor that caused P2 pressure to decrease (by 1 bar!) if SRV is fine? We have checked the SRV output and feedback and there is no error. The P2 pressure did drop and it dropped exactly when GCV suddenly opened. What do you think can be the reason then for this pressure drop?

>Regarding your discussion on null bias, what can then be a
>factor that caused P2 pressure to decrease (by 1 bar!) if
>SRV is fine? We have checked the SRV output and feedback and
>there is no error. The P2 pressure did drop and it dropped
>exactly when GCV suddenly opened. What do you think can be
>the reason then for this pressure drop?

I haven't seen the data, but the P2 pressure reference is based on turbine speed. If the speed had dropped, then the P2 pressure reference would have also dropped. AND, when the GCV "suddenly" opens it's not uncommon for P2 pressure to decrease slightly for a short period of time as the SRV opens to accommodate the increased fuel flow through the more-open GCV.

But, this is like asking if the dog is wagging the tail or the tail is wagging the dog. Or, which came first: the chicken or the egg?

Changing the null bias current value <b>IS NOT</b> going to make the SRV move any faster. Full stop. Period. Changing the null bias will only make the actual physical position of the device closer to or further from the reference position. That's all the null bias does, no matter what anyone tells you (or what you believe). <i><b>AND,</b></i> the SRV control loop is a pressure control loop--<b>NOT</b> a position control loop. What does that mean? It means the SRV will be moved by the Mark* to WHATEVER position it needs to be in so that the actual P2 pressure equals the P2 pressure reference.

The ability of the SRV to control P2 pressure is also related to the gas fuel supply system. If there isn't enough pressure/flow to maintain P2 pressure when the SRV moves to change the P2 pressure, then P2 pressure will suffer.

Finally, P2 pressure for most GE-design Frame 5-sized heavy duty gas turbines (including the H-25) is usually around 230-250 psi when the turbine shaft is at rated speed. So, a 1 barg drop (!) isn't going to cause much of a reduction in fuel gas flow-rate. The basic formula for the P2 pressure reference is: FPRH (P2 pressure reference)=(TNH*FPKGNG)+FPKGNO. You can look up the values of those two Control Constants and using the speed (TNH) from the data files you can calculate what the P2 pressure should have been. The GCV, if the P2 pressure has fallen (meaning the flow through the SRV has been restricted) will increase to try to maintain load. In your case, there was a <b>LOT</b> happening it's very difficult to say what caused what to happen--without high-speed data (which MIKEVI has asked for).

A GE Historian would NOT provide high-speed data; in fact, the data might be worse than what was in the .dcast files. You need to find the Trip Log file (as MIKEVI recommended) for the event, and you need to do it sooner rather than later, because I think the data is overwritten after some period of time....
I have comments on IGV control and SRV control. The comments apply to a properly tuned system with control devices calibrated to their specifications and with the hydraulic control oil pressure within specifications.

Regarding IGVs:
When the IGVs are operated in temperature control mode (also known as combined cycle mode), they act to control the exhaust temperature to the value shown on the control curve based on the current compressor discharge pressure. Within their control range (54 to 84 degrees was the range for most of GE's gas turbines at the time of my retirement), the IGV control will position the IGVs as required to maintain that temperature. So, when the load increases, the additional fuel flow will tend to raise the exhaust temperature and the IGV control will open the IGVs to reduce it back to the control line. Concurrently, as the IGV's open, the air flow through the compressor will increase, which will also increase compressor discharge pressure, which will lower the exhaust temperature setpoint, but things will settle out at a new operating point. Should the load continue to increase after the IGVs reach their maximum limit, the exhaust temperature will increase above the IGV control line until it reaches the fuel control line, at which point the FSR will no longer increase (base load limit). When load is decreased, the reduced fuel flow decreases exhaust temperature and the IGVs close to increase the temperature, which will reduce the air flow and also the compressor discharge pressure and will thus increase the exhaust temperature setpoint. Again, things will settle out at a new operating point. When the IGVs reach their minimum limit, further reduction in load will reduce the exhaust temperature below the IGV control line.

Regarding SRV control:
The SRV control modulates the position to maintain the P2 pressure at a fixed value determined by the shaft speed. This control loop works very well and is very stable, as long as the equipment is properly calibrated and tuned. As to why the P2 pressure decreased here, I would look closely at the fuel gas supply pressure. Do you have an electric motor driven booster compressor to provide the proper fuel gas supply pressure? With generators going underfrequency and tripping, maybe you lost fuel gas pressure.

PC Load Letter

Its been a interesting thread and I am a long time lurker and would like to share some thoughts on this based on my experience working in India and on GE Speedtronic Controls systems. I am making the following "Ass"sumption.

1. The Machine has leniar standard Droop Speed/Load Control (BP1G) application core running in it. This is the case with most frame V/VI class machines in India.

2. FSR change (by L70L/L70R) is blocked by L30TXA. Again typical in most application cores.

3. The fuel reference is governed on both machines by (This is important; both GT1 and GT2 have the same formula and constants)


4. The isochronous control is governed by two equations

FSRNI(t) = FSRNI(t-1) + (TNRI -TNH(t))*FSRKN3

FSR(t) = (TNR - TNH(t))*FSRKN2 + FSRKN1 + FSRNI(t-1) + (TNRI -TNH(t))*FSRKN3
(if FSRNI is less than FSRKN6 typically its about 0.3-0.5%)

If FSRNI value is more than FSRKN6 then the TNR setpoint is raised or lowered (i.e., raising the droop curve up or down) by L60IR/L60LR logic through L70L/L70R .

What the above equations means is that during small load changes the FSRNI is added to the FSR to control the fuel/speed ; while for large variations the TNR setpoint; hence the droop chara is raised/lowered to control the fuel/speed.

Now with the following assumptions this is what could have happened

1. When the tornado unit tripped and a 4 MW load came on; the system speed would have went down. Based on the equation in assumption 3 ; the TNH would have come down on both GT1 and GT2 and the FSRN raised equally in both machines to take up the 2MW load.

Normally if the machines had a good margin (lets say running at 10 MW and 12 MW) when the machines faced the 4 MW step change, the GT2 running in Isochronous mode will increase the TNR while the machine running in droop will keep it the same. This increase in TNR will then cause GT2 to take up additional load and the machines which were 12 MW and 14MW at the instant the 4MW step load came on will slowly change to 10W and 16MW as the TNR catches up in GT2 unit.

Unfortunately in this scenario - it did not happen the 2 MW step change forced GT1 to go to exhaust temp high tripped the unit. Tripping of both the tornado and GT1 would have put a lot of load on the remaining GT2 unit. At some point due to the lowering frequency the CPD would have come down and the exhaust temp gone up forcing the GT2 temp control to block any further rise in TNR (this will explain why the load never went past 20.6 MW).

One thing to realise is that inlet air temp is high in Indian conditions and even though the machines may be capable of 25MW in ISO conditions the actual machine output is temp dependent and during the time of the fault the actual capability of the machine would probably only have been around 20-21MW.

Now to the GE recommendations

>GE Recommendation:
>1) It seems the SRV is not able to maintain the P2 pressure
>and triggered the event. It is recommended to inspect the
>SRV for mechanical damaged on actuator.

You can take apart the SRV; but I don't think you are going to find any problem with it ; 1 bar drop is minimal and this was probably because of the step increase in the fuel flow due to the 2MW load increase. It would have corrected itself within a few seconds. Personally I believe this is not required.

>2) The null bias of the SRV servo is set as 3 it is
>recommended to check same and replace the servo if the
>calculated null bias is still 3.

Replace the servo (moog) because the null bias is 3??!!; it's within acceptable range. This again is a wasteful activity and flushing money down the drain.

>3) The IGV could have avoided the event if it was traveling
>little fast we can increase the IGV gain CSKGVTPG from 0.36
>to 0.45 this will help IGV to move little fast to control
>the exhaust temperature (went from 60 deg to 64 deg in

This may help ; but there is no guarantee that it would have avoided the trip. The best option would be to disable IGV temp control and let the IGV open fully ( if there is HRSG downstream you will see a reduction in steam temp ) as the exhaust temp will come down. But raising the CSKGVTPG most probably would not help on a similar scenario.

What could have been done ?

1. Know the machine capability on the day. If you have a grid connection - parallel and put the machine in base load this will tell you how much load your machine can take. If you are islanded mode its a bit more tricky. You can put the machine in droop and keep on increasing the droop ref slowly so that the machine takes up more and more load till the temp control becomes active. Again if you have a mix of machines like your plant its a bit more complicated as the other machines will slowly lose their load and you need a experienced operator to bring the system back to where you want. You just may not have any option unfortunately.

2. If the machine is operating close to its full load and you expect a sudden load change then open the IGV's fully to shore up the exhaust temp trip margin.

Having read the incident and your system makeup I would take this as a lesson learnt and move on and leave your SRV and Servo valve alone. They are most probably working fine.

PS - So did you call BGGTS (BHEL GE Gas Turbine Service) or GE-India for analysis ? Just curious to who recommended the above actions. All right bye bye for now.
Dear CSA,

Your explanation of DROOP mode and how droop machine's actual speed remains the same is very understandable, but for an '<b>infinite</b>' grid. What is your opinion on our situation where we are operating in island mode and the GT on droop mode is exactly same as the GT in Isoch mode. Fair enough, our Tornado or ST do not give us any irregular response since the GT on Isoch is more powerful than those so it governs their generator speed. But is it possible that GT-1, the one on droop mode, can change its actual speed since it can match GT-2 (Isoch) in terms of capacity?

You said the behavior (both GT-1 & GT-2 taking 2MW load) can only happen if both GTs were on droop at that point but I have confirmed that GT-2 was indeed on Isoch mode at the time of the event. I also checked system frequency when GT-1 (droop) picked 2MW load and it was 49.95Hz. So we know that it did not pick the load due to frequency disturbance. Interestingly, when GT-1 picked the load there was no fluctuation in P2 pressure and it was smooth throughout. So what is causing the droop turbine to pick up the load, when only Isoch turbine should, is beyond me and I need your help in this regard.

Let me share another instance. We ran a little experiment at our site after power restoration and when both GTs were stable. We suddenly added a 1.5MW load to the system by starting one our cooling water pump. Normally, GT2 the Isoch turbine should have picked the entire load. But in actual, GT-1 (droop) took 700KW and GT-2 (Isoch) took 800KW. After a few seconds, GT-1 did shed the load and GT-2 picked all of it. But at t=0 (when the load came), both GTs picked the load. This was definitely very new for us and not what usually happens (as per our operators)

You need to delve into the sea of your vast experience to help me out here man!!

A 1.5 MW motor is a pretty big motor, and we don't know if it has a soft starter or some kind of wye-delta or some other kind of starter and we don't know what the inrush current is or was and we don't know what starting such a large motor does to the island voltage and power factor during starting.

We also don't know where you are getting your data--and at what rate the data you are referring to was collected. If you have high-speed data (25 Hz or greater) say from a generator protection relay, and you have that same data for both machines and it's synchronized by some kind of master time signal, then please share that data.

When a grid--infinite or islanded--experiences a sudden loss of generation the load doesn't change. The total load of all the motors and computers and computer monitors and televisions and lights and tea kettles doesn't change, it remains the same. The generator(s) supplying that load has to supply the same amount of power even if one of the generators trips off the grid (line). So, at your site both the generators are going to "immediately" see 4 MW of additional load--because that's what was lost when the Tornado tripped. Are they going to take some "time" to show loss of frequency and adjust fuel flow accordingly? Yes. How much depends on LOTS of factors.

And, if there is more than one generator synchronized to the grid--islanded or infinite--they are going to remain operating at the same speed and frequency. Usually, the frequency of the grid--islanded or infinite--is going to go down because of the loss of the generation. If a unit is Isoch mode it should respond faster to the event than a Droop unit--particularly if they are the same size/rating and have similar control systems. We don't know what the Isoch Control Constants (parameters) are, either; we are presuming they are "typical" GE Isoch Control Constants, and that's not always a safe presumption.

Again, if you have high-speed data, from either the Mark VI(s) or some protective relays which record data for future review, and the data for the two units is time-synched, and you can post it in ASCII or CSV format we might be able to look at it and help.

You also haven't shared how you have positively determined one unit was in Isoch.

And, I'm no grid expert--I only know what I've experienced aboard ships, and on land when commissioning GE-design heavy duty gas turbines. And, I've been asked to consult on some sites I didn't personally work on.

When two units are synchronized--that's a VERY powerful word and term--they are both going to experience similar frequencies. It's not possible for one unit to operate at 49.95 Hz and another unit to operate at 48.97 Hz. The two magnetic fields in each of the generators are locked into synchronism because of the current flowing in the generators' stators. The rotors can't run at different speeds because magnetic forces prevent that. If one rotor were to run at a different speed that would be called "slipping a pole"--and it can be mechanically very destructive to the generator, the coupling between the generator and the prime mover, and the prime mover. It RARELY happens, and when it does, it's VERY noticeable--in the damage. You know what happens when two North poles of a pair of magnets are passed by each other: they try to repel each other, and very forcefully. Well, that's what happens when a synchronous generator slips a pole--the North pole of the rotor and the North pole of the field created by the current flowing in the generator stator approach each other--and they pass each other. And you know what happens when you release two magnets with North poles very close to each other--they SNAP together with the North and South poles of the two magnets attracting each other VERY strongly. If this happens when we're talking about MW of power being produced, there are very great mechanical forces occurring that shouldn't be occurring because of the unsynchronized rotation of the rotor, and it's not pretty!

Look, there can be very short transients occurring which can be very mystifying and make one scratch their heads. And it takes a university professor to understand how this happens and the mathematics behind how it happens who also can't usually explain what happened and why--but they <i><b>know</i></b> that it happened and they have the maths to prove it. But, they can't explain it so that us lay people can understand it (unless we are VERY good at maths--which, I, admittedly, am not!).

Share the data you have. Tell us how you're so CERTAIN that one unit was and remained in Isoch during the event (before the generator breaker opened). Share the .m6b file from the Mark VI. Share the Trip History files of the events from the GE Mark VI HMIs (uploaded from the Mark VIs to the HMIs). But, without more data--there's not much more we can do. I've asked for it; MIKEVI has asked for it. We both rely on what we affectionately refer to as "actionable data"--hard data that we can look at and review and analyze. And, even, then, sometimes the data just doesn't have all the information necessary to make more than an educated guess.

Could I be wrong? CERTAINLY! We're talking about a small islanded system which was experiencing an event (the sudden loss of a fairly significant amount of generation), and we don't know much about the load on the system (what the reactive component is) or how the exciters are configured.

There's just so much we don't know, Makster. I can only comment on what I can review and analyze using my past experience and knowledge of equipment and systems and some basic physical principles I have proven to myself over decades. And I HAVE NOT experienced every type of event or scenario. In this case, I'm really speaking about general operation of small islanded systems where one unit runs in Isoch mode to control frequency, and the other units run in Droop mode; not just large infinite grids or systems. Because most of them have ALL the units synchronized together in Droop Speed Control Mode! (Yes. All of them.)

As for what happens when two units have the same rating, well, that would, to me, be the ideal situation. And, it would seem from your description that it's entirely possible that Isoch may be "de-tuned" for some reason (it happens more often than one would think). Again, we don't know what the Isoch control parameters (Control Constants) are. AND, if the fuel control valves were not operating or responding properly (hydraulic system problems; hydraulic actuator problems (leaking piston rings, for example)) or some combination of issues then it's also possible the Isoch machine may not be responding as fast as it has in the past (though I venture to say that most EVERY operator will respond to an unusual "event" by saying, "It's never done THAT before!").

There are just too many unknowns; sorry. I won't even agree with the operators (because they so often really don't have experience with problems/issues, and they usually only have anecdotal data, not hard, actionable data).

Wish I had better news.
Dear CSA and MIKEVI,

I am sorry I've been swamped for the past few days. Below I am providing the link for the trip log files and the individual m6b files for both GTs. One thing is still a mystery and that is the load pick up of 2MW by GT-1 which was on droop. The frequency of the system during GT-1 load pickup was 49.95Hz, and operator did not change the TNR. Maybe you can find something from the files. I am keeping my fingers crossed.
Good morning Makster,

I understand being swamped so no worries. I was able to locate the .m6b files for both units and will start reviewing them when time allows. I did not see the Triplog files there yet so maybe you are still moving them. I will check back later to see. I will work on this when time allows and try to provide additional comments and analysis. As long as this is not a rush hopefully we can all learn a bit more.
Dear Makster, thank you for sharing the data. I was able to retrieve the .m6b files for each unit and the Triplog files for the event.
Based on the Triplog data I make these statements which I believe to be true for the event.

Both units accepted load when turbine speed and system frequency started to decline, assumed due to the tripping of the Tornado. (Time noted on the trends is not synchronized so it is difficult to accurately time out the events of each individual turbine.)

Based on how each machine accepted load it appears that they were both in some sort of Droop control, not Isoch.

The breaker for GT#2 opened due to machine speed falling below 95% speed, it did not trip on exhaust overtemperature. It is assumed the unit was tripped a short time later by the DCS due to some logical interlock as the unit speed was recovering after the breaker opened.

It is difficult to tell if GT#1 tripped on high exhaust temperature first or opened the breaker. In the trend when the unit speed decreased below 95% speed, the average exhaust temperature, TTXM was already 20 degrees Fahrenheit over the speed bias exhaust temperature reference TTRXB. I don't think it really matters at this point because once GT#1 breaker opened, the system was at the point of no return since no load management or load shedding equipment was available to automatically shed load.

Reviewing your logic was very interesting. Your droop logic is nothing like I have seen here in the US. Your machines accepted load but not like they were in Isoch, and the way they accepted load was still not typical of droop logic like here in the US.

Makster, based on what I see at this point I would make these suggestions:

I do not personally believe any of the changes suggested by GE would have made a difference. The drop in P2 pressure was not significant and the IGV's were following reference through the event.

I believe if the droop logic was more typical of what I see here in the US the machines would have responded differently and may have been able to arrest the reduction in frequency.

Your site really needs to look at some sort of controls to shed load when frequency falls. Once turbine speed falls below 95% speed=frequency of 47.5hz, it is over and you will not recover. You need some sort of load management or relay protection to shed load before frequency gets anywhere close to this low. This is absolutely important to protect and keep generation online.

I will continue to look at your logic. I want to better understand the droop logic installed since it is different. The logic I am familiar with here in the US uses a droop equation that is different than what you have. Not saying either is better at this point, just different.
Very interesting comments regarding our droop equation and I would love to know more. I think that this will open new points for discussion and hopefully interesting ones.

>Both units accepted load when turbine speed and system
>frequency started to decline, assumed due to the tripping of
>the Tornado. (Time noted on the trends is not synchronized
>so it is difficult to accurately time out the events of each
>individual turbine.)

That is the big looming unanswered question up till now. <b>Why did both GTs accept load when the Isoch one should only have?</b> I believe that this was due to the slow response of Isoch machine (GT-2) which caused the frequency to decrease initially. This caused the droop machine to pick up 2MW that it did. But I haven't got the data to back me up on that. When I looked at the trend, when Droop machine picked 2MW frequency was 49.95 Hz which is not a significant drop. Maybe you can review it again down to the millisecond and see any sharp drop in frequency to backup my theory.

>Based on how each machine accepted load it appears that they
>were both in some sort of Droop control, not Isoch.

There is an AFR button on our GTs' HMI which determines whether a machine is in Iso or droop mode. When AFR is ON, machine is believed to be in ISO otherwise, it is droop. The thing is that whenever AFR button is toggled (which the operator can do), an event is registered. But I could see none of that in event summary. That is why I believe at least none of the operators changed the speed control mode. If Mark-VI changed the mode due to some logic, please enlighten me. None of the operators can dare change the speed control mode without approval. BTW, this was the first thing we checked after the event.

>The breaker for GT#2 opened due to machine speed falling
>below 95% speed, it did not trip on exhaust overtemperature.
>It is assumed the unit was tripped a short time later by the
>DCS due to some logical interlock as the unit speed was
>recovering after the breaker opened.

This is exactly what happened on GT-2.

>Reviewing your logic was very interesting. Your droop logic
>is nothing like I have seen here in the US. Your machines
>accepted load but not like they were in Isoch, and the way
>they accepted load was still not typical of droop logic like
>here in the US.

I would love to know more about OUR droop logic as compared to the logic used in US and have a detailed discussion on that.

>I believe if the droop logic was more typical of what I see
>here in the US the machines would have responded differently
>and may have been able to arrest the reduction in

How? What's our logic lacking?

>Your site really needs to look at some sort of controls to
>shed load when frequency falls. Once turbine speed falls
>below 95% speed=frequency of 47.5hz, it is over and you will
>not recover. You need some sort of load management or relay
>protection to shed load before frequency gets anywhere close
>to this low. This is absolutely important to protect and
>keep generation online.

Already done that. This was one of the first recommendation after the event.

Furthermore, right now at our side, the Machinery dept (responsible for mechanical maintenance of GTs) and I&E dept (my dept, responsible for control & instrumentation end) are at odds over the behavior of GT-2 (Isoch). As per machinery, poor (slow) response of SRV (P2 pressure drop!) and IGVs is responsible for the slow response of GT-2 on sudden load which caused under-frequency of the system. My take is that SRV and IGVs perfectly followed control system's command and there was no deviation. The control constants and PID parameters have not changed. Can anybody help me to understand this behavior of GT-2? GT works fine when the load is gradually increased and is right now also running at 22MW. But on sudden jump from 17 to 21MW, why did it go to under-frequency? This means we are still operating in vulnerable state and with GT-1 exhaust spread already disturbed, any jump or shock can again lead to power failure.

Therefore, anything from your guys' experiences will be warmly welcomed.
PC Load,

You've just about hit the nail on the head. Based on your understanding of turbine operation in subcontinent conditions, why do you think GT-2 failed to take the load? Machine was operating fine four hours before the event at 21 MW so we knew it was capable of handling this much load. That's why we brought the load to exactly 17MW so that it has the margin to take entire tornado load.

I also agree that GE recommendations are a bit irresponsible and 'rash' if I can say so. I personally think changing these constants could be disastrous and could open new battlefields. I would like to know more of your opinions on this.

Plus I'm waiting for CSA's analysis!!! That would be fun, I hope! :)
Dear Makster, I have not forgotten about this post and want to comment more and share what I can about the different droop logic. But work here has gotten very busy. I will get back to this--just need a little time to catch up.

I, too, am swamped through the middle of next month--outage season has begun (with a vengeance!).

I don't have ready access to a PC with ControlST/WorkstationST/ToolboxST, either, so I'm not able to comment on the application code.

It would not surprise me that Hitachi modified the "standard" GE Droop Speed Control scheme--especially if they understood the application at your site. That's not to say it's bad, just that I wouldn't be surprised they changed the scheme to what they believed would be more applicable for the turbines at your site.

Trust me when I say that learning GE control design and philosophy isn't easy, and so when one encounters something new and unusual (as MIKEVI is with the .m6b file from your site) it can take some time to work through the code to understand it. (Once one learns a few of the "standard" GE control schemes, learning another one isn't too difficult (usually!). But, when other companies make large changes to GE's "standard" schemes it can be very difficult to work through in the beginning; very difficult.

I'm following this thread because I'm interested in hearing all the comments. In my opinion (which I think MIKEVI and I share) neither unit was actually in Isochronous Speed Control Mode--but, there's not enough data to say that for sure; that's just based on the data (values) that has been made available.

Hopefully once MIKEVI completes his review and analysis of the application code in your .m6b file we will all have a better understanding of what the code says should have happened.
Dear Makster,

I have spent hours looking at your logic, trends, logic, trends. Changing time scale, zooming in, zooming out, thinking, thinking and trying to put together a response that doesn't ramble on, but is appropriate. I start this near the end of my work day, and will need come back and finish it tomorrow.

Do I know exactly what happened and have proof-no.

I will take back what I said on September 14th that GT#2 does not appear to be in Isoch mode. It is just too hard to tell from the trends and without certain signals in your capture blocks I can't prove it. And I really want to try and stick to facts if possible, although a lot of this is just discussion.

There are so many others out there with more experience than myself, CSA and Otised to mention only a few, that would be great to get in a room and discuss this with all the data we could ever want. The learning opportunity would be so awesome.
I am going to go back to your first post and try to re-answer those questions, but first I do want to try and give an extremely brief and over simplified description of how I understand &#8220;Droop&#8221; logic to operate.

The GE designed turbines that I am most familiar with typically operate with some design of Droop logic that works proportionally on the error between the speed setpoint (GE term is TNR, Turbine Speed Reference) and the actual turbine rotor speed, TNH. The gain of the proportional error is usually called the droop. A larger droop number results in a machine that is less sensitive to frequency excursions, lower droop number is more responsive. Controlling load from these machines is typically done by raising or lowering the speed setpoint. The larger the error=more fuel (FSR or Fuel Stroke Reference). This oversimplified description is the simple way to control load when on speed control, and your machines are always on speed control, weather the generator breaker is open or closed. Other control modes such as Isoch, temperature limits etc. may influence and limit droop control, but it is always there partially controlling how the machine operates.

Now to your questions.
1) GT-2 was on Iso and running at 17MW. Why didn't it take the additional 4MW load entirely since it had enough margin? Both of your gas turbines accepted load when the Tornado tripped, mostly due to their droop response, since frequency immediately dropped when the Tornado tripped. In your system I would have expected both units to pickup about half the load of the Tornado. The droop response of both units will be the first control to respond to a change in frequency, whether in droop or Isoch. Once the proportional droop response has reacted then the unit in Isoch will Integrally work to bring frequency back to normal. You can&#8217;t expect a smaller system like yours to instantaneously pickup the loss of the 4mw the Tornado was generating. There is going to be a frequency disturbance each time you start and stop a large load, or lose a generating asset suddenly. You need high speed trends to see it, but I guarantee it is there every time. GT#2 accepted load based on droop response, but something else seems to have then started to limit its response. In the trends we would have needed other signals to determine what other limiter may have inhibiting further load increases, but I can say the trend shows FSR dropping, where I would have expected it to be rising.

2) Why didn't GT-2 IGVs respond on additional load and rise in exhaust temperature. During all this scenario, they only went from 62% to 68%? The IGVs were opening as turbine exhaust temperature (TTXM) was nearing the speed biased temperature control reference (TTRXB). They got as high as 65 degrees before starting to close again, I assume because at that point frequency was down to 47.87Hz.

3) Both GTs were running fine at 20MW and 21MW before respectively, but when sudden load came, both gave away. Why? All I can say for sure is that changing load in a controlled manner gives the IGV’s the opportunity to schedule open and control exhaust temperature and not limit droop or Isoch controls. A sudden loss of load like this can limit the machine response if frequency drops. Also the small amount of electrical and mechanical inertia available in your isolated grid limits the ability of the system to counteract the instant loss of generation. With this limited inertia load shedding is really needed to control frequency when generation is suddenly decreased.

4) GT-1 tripped on exhaust temperature but tripping of GT-2 is very queer. There was enough margin in IGVs when frequency began to decrease which should have catered the additional load? This last part of the event occurred in milliseconds so it is very difficult to say with certainty. It appears GT#2 breaker opened as the turbine speed decreased below 95% speed, but it was also nearing an exhaust temperature limit. If trends were time synchronized it might have been possible to see if GT#1 tripped just before or just after. But at this point I don’t really think it mattered, system frequency was too low to recover.

I made a comment, &#8220;Reviewing your logic was very interesting. Your droop logic is nothing like I have seen here in the US. Your machines accepted load but not like they were in Isoch, and the way they accepted load was still not typical of droop logic like here in the US.&#8221;

It appears from reviewing logic that Hitachi or GE is manipulating the turbine speed in logic to create some deadband for the unit in droop. If you look at your logic for macro FSRNV4 instead of using the actual rotor speed signal, TNH, they use signal TNHDX, selected non linear droop speed signal. That signal is generated from a function block that is creating a deadband of + or -.28% around your 100% speed signal. This I have not seem before, but I believe it is specific to your island system, basically to keep the droop machine from fighting the Isoch machine for frequency control. So it is different
than I have seen before, but not anything crazy.

If this was my plant this is what I would like to have done:
<b>*</b> Get a NTP time source on your system to time synchronize all your HMIs and controllers. Use the toolbox function Device/Download/View/Set Time to get the time in the controllers synchronized to your HMIs.

<b>*</b> Add signals to your capture blocks so they are part of the TripLogLive and Triplog.

<b>*</b> It sounds as though you have done this, but if not implement some load shedding logic to shed load as frequency decays.

<b>*</b> Using this event as a learning tool, create or modify procedures for bringing generating assets offline that accounts for generating limitations and new frequency/load shedding logic to best guarantee system reliability during transients.

Furthermore, right now at our side, the Machinery dept (responsible for mechanical maintenance of GTs) and I&E dept (my dept, responsible for control & instrumentation end) are at odds over the behavior of GT-2 (Isoch). As per machinery, poor (slow) response of SRV (P2 pressure drop!) and IGVs is responsible for the slow response of GT-2 on sudden load which caused under-frequency of the system. My take is that SRV and IGVs perfectly followed control system's command and there was no deviation. The control constants and PID parameters have not changed.

I don&#8217;t see anything obviously wrong from the maintenance or controls side. It is possible that if you had more generating overhead when this event occurred, more like 2X the expected loss of mwatts then the system would have recovered. But I do not have the math skills to figure that out. I honestly believe if you have made changes that include load shedding you will not see an event like this again.