Today is...
Tuesday, October 22, 2019
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Site Power Outage Due to Underfrequency
Recently we had a complete power outage at our site, and I want to share the events to conclude the RCA of said outage
1 out of 1 members thought this post was helpful...

Hello again.

Basically, I work at a petrochemical site which has two 25MW Hitachi H25 Gas Turbines (GT 1 & 2), one Alstom Tornado Gas Turbine of 4MW and a Steam Turbine (STG) of 15MW. We are not connected to any grid and we operate in island mode. GT-2 is normally running on Isoch mode maintaining system frequency at 50 Hz, while all other generators are on droop mode. However, it is to be noted that both GT-1 & GT-2 generators are of same capacity.

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 after creating margin in GT-2 and bringing it down to 17MW. However, due to some fault, Tornado tripped and suddenly there was an additional 4MW load on the system. Ideally, GT-2 should have taken the entire load and nothing should have happened, but what happened in reality was that both GT-1 and GT-2 took equal load i.e. 2MW each. GT-1 load went to 21.6MW, and it tripped on exhaust temperature. At that time IGVs were 78% open. GT-2 (Iso) went up to 19.6MW after which its speed started to decrease. Exhaust temperatures also began to rise and finally GT-2 generator breaker also tripped on under frequency. IGVs of GT-2 were only 68% open when it tripped. The load on GT-2 was 20.6MW at that instant. This resulted in site total power outage and an emergency situation. The tripping time of both GTs is virtually the same only separated by milliseconds with GT-1 believed to have tripped first. The time difference between Tornado tripping and both GTs tripping is 15 seconds.

In all this scenario, I am unable to understand following:

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?

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%?

3) Both GTs were running fine at 20MW and 21MW before respectively, but when sudden load came, both gave away. Why?

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?

The event and alarm list can be found at the following link for additional info. Any sort of help would be greatly appreciated.

https://drive.google.com/open?id=1DLPulAapA7H06hfzZr-M2R6wxWbjFXSv

https://drive.google.com/open?id=1bqfD9wq8f1lSXE8h1ZciVpYEbbIC6DuW

Hi,

I am joining the discussion out of interest and because i believe i have some contribution to make.

1) So why did GT-2 trip?

If GT_1 droop setting was 1% instead of typically 4% it could cause it to take load faster. See my comment for 3)&4)

2) Why did GT_2 IGV not open to max?

Either there is a problem with IGV reference logic or there is some problem with the IGV controls -because it did not open, GT_2 would have gone into temperature control and prevented from taking more load.

If IGV control was not manual or in temperature matching mode it should have opened as soon as load and temperature increased.

Presuming IGV reference did go to maximum then there should be an alarm indicating demand and feedback error. If this alarm came out then IGV control is the problem.

3)&4) Why the system cannot handle sudden load swings?

Gas turbines are supposed to be best able to take load instantaneously but still expect some time lag - some due to inherent machine characteristic but some avoidable ones are: fuel control set up, MW/Hz setting...

I will take a closer look at GE control software to see what other settings can affect load swing handling.

Best Regards,
Moses

Dear Moses,
Thanks for the reply.

> If GT_1 droop setting was 1% instead of typically 4% it
>could cause it to take load faster. See my comment for
>3)&4)

Where I can find this exact setting in Mark VI? Can you tell me the name of the signal that is supposed to let us know that droop setting is this much?

>Either there is a problem with IGV reference logic or there
>is some problem with the IGV controls -because it did not
>open, GT_2 would have gone into temperature control and
>prevented from taking more load.
>
>If IGV control was not manual or in temperature matching
>mode it should have opened as soon as load and temperature
>increased.
>
>Presuming IGV reference did go to maximum then there should
>be an alarm indicating demand and feedback error. If this
>alarm came out then IGV control is the problem.

There was no command and feedback error. The output and feedback of IGVs, GCV and SRV were perfectly matching. When sudden load came, FSR changed from 39 to 43% instantly but IGVs command did not change from 60.8%.

I can share the dcast files of the trends. Let me know if you can take a look at those.

1 out of 1 members thought this post was helpful...

Moses/Makster,

>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 normal, typical 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 after creating margin in GT-2 and
>bringing it down to 17MW.

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).

2 out of 2 members thought this post was helpful...

Dear Makster,

Very nice job in providing details of your plant and the event. It makes it so much easier to comment. I am not going to be able to give you a definite answer, but only some ideas and comments.

Before the event your plant load was around 55 megawatts. It is assumed GT's #1 and #2 are the only machines that could have responded to a loss in load since the Tornado was coming offline and the Steam Turbine can't contribute much if it is operating in some sort of inlet pressure control.

GT#1 operating in droop control most likely did pick up load since frequency dropped.

GT#2 operating in ISO control most likely did pick up load since frequency dropped.

Something to remember about any axial style turbine is that as frequency declines so does turbine speed. Loss in speed of the compressor means less airflow through the compressor which will increase exhaust temperature.

Your island system instantaneously lost approximately 7% of total system generation when the Tornado tripped. Units #1 and #2 responding by attempting to increase load, but due to underfrequency both the turbines lost speed, which increased exhaust temperature and resulted in a trip of the machines.

In this type of scenario it would be interesting to see what type of load shedding scheme you have in place since load shedding is often needed in this scenario to protect the generating assets. I think in your event the machines were attempting to pickup the loss of generation but it does take time for the IGV's and fuel valves to respond. Any trends you have with fast data, at the millisecond level, would be very interesting to analyze.

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? It had margin based on it being at rated speed, but the loss in frequency it was not operating at rated speed when it tripped on exhaust overtemperature.

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%? I would suspect it is a timing issue. It takes time for the actuators to move the IGV's and gas valves. The loss of frequency and machine speed may have been too fast.

3) Both GTs were running fine at 20MW and 21MW before
respectively, but when sudden load came, both gave away.
Why? I would suspect the drop of frequency caused exhaust temperature to rise VERY quickly. High speed trends if available would be something to analyze.

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? I suspect the same as noted above.

Hi MikeVI,

>Before the event your plant load was around 55 megawatts.
>It is assumed GT's #1 and #2 are the only machines that
>could have responded to a loss in load since the Tornado was
>coming offline and the Steam Turbine can't contribute much
>if it is operating in some sort of inlet pressure control.

Yes Steam Turbine and GTs are connected in combined cycle with both GTs HRSGs providing steam to steam turbine.

>GT#1 operating in droop control most likely did pick up load
>since frequency dropped.
>
>GT#2 operating in ISO control most likely did pick up load
>since frequency dropped.

My question is that why did the frequency drop in the first place? Isoch GT (GT-2) should have taken all the load without affecting its frequency since it was running before on 21 MW

>Your island system instantaneously lost approximately 7% of
>total system generation when the Tornado tripped. Units #1
>and #2 responding by attempting to increase load, but due to
>underfrequency both the turbines lost speed, which increased
>exhaust temperature and resulted in a trip of the machines.

Understandable but again, why did the frequency drop in the first place. Interestingly, before turbine tripping, its generator breaker opened first as you can see from the events. Generator breaker opening should have caused the turbine to go to FSNL. We still cannot solidly determine what caused the turbine to trip. If you can extract something from the events, that'll be great!

>In this type of scenario it would be interesting to see what
>type of load shedding scheme you have in place since load
>shedding is often needed in this scenario to protect the
>generating assets. I think in your event the machines were
>attempting to pickup the loss of generation but it does take
>time for the IGV's and fuel valves to respond. Any trends
>you have with fast data, at the millisecond level, would be
>very interesting to analyze.

We do have an LMS installed with different priorities set but its only associated with a GT tripping and not on Tornado. The time taken by LMS to act is 200ms. But it did not trigger in this event. Apparently the time difference between both GTs tripping was too short.

>3) Both GTs were running fine at 20MW and 21MW before
>respectively, but when sudden load came, both gave away.
>Why? I would suspect the drop of frequency caused exhaust
>temperature to rise VERY quickly. High speed trends if
>available would be something to analyze.

I can share the dcast or csv files of the trends. Let me know if you can work with them.

Hi Makster,

I would prefer the .dcaST files if you can find an easy way to share them. I will be glad to look at them and comment. If the capture blocks were properly configured and produce data at the millisecond level we should be able to see better what occurred and at least discuss it further.

Below is the link for both dcast and csv files. Event happened on 3rd September and you can see it in following file: g1_triploglivedata_20190903_100000
g2_triploglivedata_20190903_100000

https://drive.google.com/drive/folders/1EvjMkmV6W5gKCjt8YSNCFXbeGHSscpc3?usp=sharing

https://drive.google.com/drive/folders/1e_1SgCN_RPHBZpdecvDh9RIxxrji1XzC?usp=sharing

1 out of 1 members thought this post was helpful...

Dear Makster,

I was able to download the TripLogLive file for GT#2 at the time of the event. Based on what I see from the trend so far GT#2 was not in Isoch mode. I see the machine pickup ~2 mw of load at 13:45:41, frequency at that time was 49.6hz. Frequency continued to decline and the machine did not pick up any more load like it would if it was in Isoch mode. The breaker tripped at ~13:45:53 when turbine speed fell below 95% speed, frequency at 47.6hz. Gas valves and IGV's were following reference as commanded.

I will download and look at the same file for GT#1. I would ask if you could share the actual triplog files for each unit. What you shared was the TripLogLive files which are files collected and saved at each hour. The sample rate for these is 1 second which is very slow when trying to analyze and event like this. The triplog files should be stored in the same general area you found the TripLogLive files. There will be a folder in the Triplog file folder for each time the unit tripped or breaker opened. If you are able to share the Triplog files for each unit they should also have the alarms and events in the file in the proper time range. The capture blocks setup for your unit are quite good in my opinion, most needed signals are available.

But from what I see so far GT#2 was not in Isoch mode like it should have been. If that is the case then it will be another investigation to determine if some logic issue is to blame or if it was an operational error.

Dear MikeVI,

How can I confirm whether GT-2 was on Isoch mode or not? Is there any signal which I can see?

Hi Makster,

I don't know about your site. But from a typical MkV to MkVIe site now in operation, I found that the GE logic has a serious ERROR.

Isoch is de-selected by L90LL as soon as difference between load set point and actual differs by more than 0.5MW - default setting of LK90DB2.

The logic should have disabled this signal when L83PS is False which it is when Isoch is selected.

I suggest you raise this issue with GE!

Best Regards,
Moses

Couldn't find any of these signals. Maybe their name is changed in my system. If you give me some description of these signals I'll be able to locate those.

>Isoch is de-selected by L90LL as soon as difference between
>load set point and actual differs by more than 0.5MW -
>default setting of LK90DB2.
>
>The logic should have disabled this signal when L83PS is
>False which it is when Isoch is selected.

Makster,

The typical logic signal for Isochronous Speed Control selected and active is L83SCI, but it's NOT usually included in the Data Capture blocks for Trip History data. If you have a GE Historian, it might be in that historical database. It might also be an EVENT, but not always. If it was an EVENT, you could filter the Alarms for EVENTs and see if if changed during the situation.

But, MIKEVI is correct--neither unit was on Isoch at the time they tripped. The very fact they both took half the 4 MW load says both units were on Droop Speed Control. You should be looking for what canceled Isoch Speed Control before the trip occurred, because neither unit was in Isoch when the trip occurred--whatever it was that cause the "trip." GE has an extremely bad programming practice of not blocking trip alarms AFTER something has tripped the unit. Again, as has been said repeatedly--when axial compressor speed decreases when frequency decreases the air flow through the unit decreases. If the fuel flow remains the same--or increases because the unit is sensing the speed decrease and is increasing the fuel because it was (THEY WERE) on Droop Speed Control--the combination of decreased air flow AND increased fuel flow will cause the exhaust temperature to increase, resulting in the Exhaust Temperature High alarm. (DLN combustor-equipped units usually operate VERY CLOSE to the exhaust temperature control limit when they are at Part Load, and even if the unit doesn't have DLN combustors but is exhausting into an HRSG the IGVs are usually kept closed to maximize exhaust temperature to maximize steam production at Part Load.

You can't MAKE the cause of the trip be something it isn't--and we really don't know exactly what caused the trip. The Alarm Displays you provided were not complete, and the Trip Log Live data doesn't include alarms. You need to provide the Trip History data for someone to be able to analyze the full alarm list. If you provide the full and complete alarm information and the Trip History data then someone might be able to provide more detail than has already been provided.

The Mark VIe has some excellent tools, and sometimes they are configured well enough to provide very good data and information. In this case, it's necessary to know all of the alarms and EVENTS, and it certainly seems like there was a WHOLE LOT going on with the underfrequency and and underspeed and other DCS stuff going on. Single-shaft heavy duty gas turbines don't always behave as one thinks they should when underfrequency and underspeed is occurring. GE has some poor programming practices that don't block trip alarms after the unit has been tripped--so the Customer Trips (L4CT) may not have been the actual reason for the trip, something else may have already tripped the turbine, but GE's poor programming practices make it difficult to analyze. Not impossible, but difficult.

There are also breaker-open events that don't trip the turbine but do open the generator breaker (such as reverse power). It's possible the generator protective relay(s) tripped the breaker and the unit tripped on exhaust overtemperature. Or the units were tripped by the DCS (L4CT) after the generator breaker tripped.

Help us help you!

1 out of 1 members thought this post was helpful...

Makster,

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.

>Hi Makster,

I sent below message on 13Sept - is this a possible cause of dropping out of Isoch on your site?

"
>I don't know about your site. But from a typical MkV to
>MkVIe site now in operation, I found that the GE logic has a
>serious ERROR.
>
>Isoch is de-selected by L90LL as soon as difference between
>load set point and actual differs by more than 0.5MW -
>default setting of LK90DB2.
>
>The logic should have disabled this signal when L83PS is
>False which it is when Isoch is selected.
>
>I suggest you raise this issue with GE!
"
Best Regards,
Moses

Makster,

I'm first looking at the GT-B 5.png document (Alarm List). At 15:29:23.632 the Turbine Underspeed Process Alarm went to NORMAL; we can't see when it went to ALARM. At 15:29:23.362 (the same time) the Generator Breaker Tripped Process Alarm went to NORMAL; again, we can't see when it went to ALARM. At 15:29:25.383 And Exhaust Temperature High Process Alarm went to NORMAL, and we can't see when it went to ALARM.... Finally, at 15:29:25.384 the Process Alarm CUSTOMER TRIP went to ALARM--which is probably what tripped the turbine (from the alarms we can see in the screenshot).

Looking at the 1.png for GT-A, almost the exact same thing happens--except it's 2 seconds different--15:31:43:534 for the CUSTOMER TRIP. But many of the same alarms occurred--and we can't seem much before that. There was an underspeed that cleared, just like GT-B, and an Exhaust Temp High Alarm, and Backup Exhaust Temperature Reference Active Process Alarm(s). The difference here is that the Generator Breaker Tripped Process Alarm occurred AFTER the Customer Trip Process Alarm.

So, I'm going with MIKEVI in that both turbines had a drop in speed because they BOTH accepted load, and the fact that they both took 2 MW says to me that the unit you think was in Isoch wasn't....

If you can post the exported .csv value files from the .dcast files when the trip occurred, we could probably be more helpful. But the files that were provided pretty much say what was above.

Hope this helps!

Hi CSA,
I really value your inputs and was hoping for your reply. I have posted the links for both dcast and csv files in another reply. Event happened on 3rd September and you can see it in following file: g1_triploglivedata_20190903_100000
g2_triploglivedata_20190903_100000

Makster,

I would have responded earlier, but I have been traveling and don't have great Internet access nor a lot of time these days. I was on a plane when I had a couple of minutes for my last reply.

I think MIKEVI is pretty good and has already pretty much identified the issues. And, surya, too. It seems to me that something caused the unit which was thought to be in Isochronous Speed Control to switch out of Isoch and be in Droop--and that's why the two units "split" the 4 MW (because both units are the same rating and have the same Droop characteristic). And, then the units both experienced an underspeed (because there was NOT an Isoch unit to hold frequency), and then all sorts of things started happening because of the underspeed (underfrequency). I don't know what signals were captured in the Trip Log files, but usually they don't have much of what is needed to really troubleshoot trips.

As MIKEVI said, when the airflow through a unit decreases while the fuel is held constant or increased then the exhaust temperature goes up--probably close to the alarm/trip limits.

BUT, from the Alarm Display screenshots, both units experienced Customer Trips--which means something in the plant issued trip signals to both units a couple of seconds apart, which were displayed in the Alarm Displays. Now, we don't know if that's before or after the units actually tripped.

Troubleshooting trips is not that difficult with WorkstationST Alarm Viewer. Just filter out EVENTS and DIAGnostic Alarms and anything except Process Alarms for a short period before and after when you suspect the trip occurred. Then, with the Alarm Display sorted by Recorded Time, with the earliest time-stamped alarms at the BOTTOM of the window, scroll up through the list and find the first Process Alarm that trips the unit. (If you're not sure, use the list of Trips in the Trip Display to determine which signals cause trips.)

Hope this helps! For the next few days, I'm swamped (literally!) and won't have much time to look over the Trip Log files. Everyone needs to learn how to troubleshoot trips--and now is just as good a time as any to start learning. But, you haven't provided enough information in the first post, and I don't know what's in the Trip Log Live files (hopefully MIKEVI has some time to look them over and share his findings with us!).

Dear Makster,

Use finder to locate DWKDG - it is by default 5%.

Another possible scenario is your isoch selection was cancelled by either exhaust temperature high alarm L30TXA or by an auto load lower from MW control block.

Will check out the auto load lower signal when i get some time later today.

I don't know what is dcast.

Best Regards,
Moses

Hi,

observation based on GT-B & GT-A events & based on your info

GT-A is on droop control. No information regarding GT-B on droop/iso.

Based on time stamps (recorder time) GT-B is tripped on under speed first, and then GT-A tripped on exhaust over temp.

And also it leads to confusing why other unit GT-A is not tripped. Seems to be issue with both unit time stamps are not synchronized or wrong? As it was very small load disturbance so two GT's usually should take care.

But during this disturbance, if any one GT tripped, then situation become complicate then it leads to emergency situation.

I am expecting GT-A tripped on exhaust over temp during load sharing of 4 MW, and the other GT-B not able to maintain required load and it leads to under speed and tripped.

If we have some trend data of both GT-A & B together we can analyze further.

And also can you tell me the reason for 4 MW turbine trip is due to internal or any external trip?

Thanks everyone for the detailed inputs. After many trials and tribulations, I've been able to map out the exact sequence of events which may help you all further. Time stamps shown are our local time but only minutes and seconds should be the matter of concern! So here it goes:

15.28.51 Tornado Tripped
15.28.57 GT-1 Exhaust Temp High Alarm Appeared
15.29.02 GT-2 Exhaust Temp High Alarm Appeared
15.29.08.155 GT-1 Tripped on High Exhaust Temp
15.29.08.155 GT-1 & 2 Generator Breakers Opened
15.29.08.669 Fuel Gas Compressor of GT-2 Powered Off Alarm
15.29.09 GT-2 Tripped on Customer Trip

Couple of things I should add:

1) We have a logic configured on our Power Plant DCS that whenever Fuel Gas Compressor of a GT trips, DCS issues a command to Mark-VI to trip the relevant GT which appears as customer trip. In this case, when both GTs breakers opened, blackout at site was initiated due to which Fuel Gas Compressor Running indication turned FALSE on DCS after which it issued the command to GT-2 to trip. We believe GT-2 was still running after its generator breaker opening and only tripped after the DCS command

2) The instant when both GTs generator breaker opened is exactly the same, down to the millisecond. The frequency and speed at GT-1 at that very instant was 47.446Hz and 94.645% respectively. The same at GT-2 was 47.641Hz and 96.741%. I know frequency of both should be exactly same but this is what trend showed me. Its pretty clear that breakers opened due to underfrequency. Interestingly, GT-1 tripped on exhaust temperature at that very instant but I think GT-1 breaker opened independently and was not linked with turbine tripping

3) Further analysis has shown that when the sudden load came at GT-2, it changed its FSR from 39% to 43% almost instantly while keeping IGVs at 60.8%. This should have enabled the GT-2 to take the load but it didn't happen because GT-1 had also started shedding its load. As a result, exhaust temperature of GT-2 also increased and whole system went to underfrequency.

I just want to know whether Mark-VI can issue the command to open Generator Breakers or not because our G60 relays and exciter definitely did not open their breakers as per their event log.
Also, our GT-1 exhaust profile was already on higher side before the event and we were planning for its HGPI. Is it possible that GT-1 screwed up everything by first taking the load, then shedding it on GT-2 resulting in underfrequency of whole system?

1 out of 1 members thought this post was helpful...

Makster, based on the info provided this is what I understand so far.

1) We have a logic configured on our Power Plant DCS that whenever Fuel Gas Compressor of a GT trips, DCS issues a
command to Mark-VI to trip the relevant GT which appears as
customer trip. In this case, when both GTs breakers opened,
blackout at site was initiated due to which Fuel Gas
Compressor Running indication turned FALSE on DCS after
which it issued the command to GT-2 to trip. We believe GT-2
was still running after its generator breaker opening and
only tripped after the DCS command.

I agree and the trend from GT#2 shows the same. GT#2 breaker tripped open when unit speed fell below 95%, but the unit then started to accelerate back towards full speed and then was tripped by the DCS most likely.

2) The instant when both GTs generator breaker opened is
exactly the same, down to the millisecond. The frequency and
speed at GT-1 at that very instant was 47.446Hz and 94.645%
respectively. The same at GT-2 was 47.641Hz and 96.741%. I
know frequency of both should be exactly same but this is
what trend showed me. Its pretty clear that breakers opened
due to underfrequency. Interestingly, GT-1 tripped on
exhaust temperature at that very instant but I think GT-1
breaker opened independently and was not linked with turbine tripping.

From the TripLogLive data the breaker opened when the GT speed decreased below 95%, seeing high speed data might show exactly when it tripped due to high exhaust temperature.

3) Further analysis has shown that when the sudden load came
at GT-2, it changed its FSR from 39% to 43% almost instantly
while keeping IGVs at 60.8%. This should have enabled the
GT-2 to take the load but it didn't happen because GT-1 had
also started shedding its load. As a result, exhaust
temperature of GT-2 also increased and whole system went to
underfrequency.

Data provided shows both units accepted load, but only like they were operating in droop mode. GT#2 did not accept load appropriately like it was in Isoch. With no machines in Isoch mode, there was no way to correct the low frequency.

I just want to know whether Mark-VI can issue the command to
open Generator Breakers or not because our G60 relays and
exciter definitely did not open their breakers as per their
event log.

Yes, if your logic follows standard GE logic then once the signal L14HS(Operating speed 95%) drops out then the MARK system will issue a trip to the breaker 52G.

Also, our GT-1 exhaust profile was already on higher side
before the event and we were planning for its HGPI. Is it
possible that GT-1 screwed up everything by first taking the
load, then shedding it on GT-2 resulting in underfrequency
of whole system?

Based on data provided there was no unit in Isoch mode, GT#1 did not cause the issue. GT#2 did not respond like a unit in Isoch, and it appears it was not in Isoch mode as was assumed.

Makster,

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.

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?

Makster,

>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 by themselves (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 fishier business about null bias current. The topic of null bias current has been addressed many, MANY times on control.com. (You can use the 'Search' feature of control.com 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 control.com 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).

Hi CSA,

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?

Makster,

>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 IS NOT 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). AND, the SRV control loop is a pressure control loop--NOT 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 LOT 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....

Dear CSA,

Your explanation of DROOP mode and how droop machine's actual speed remains the same is very understandable, but for an 'infinite' 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!!

Makster,

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 know 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.

https://drive.google.com/open?id=1Glh1k2f4kz54CJUfT1hgT9wR6JHgC9uF

https://drive.google.com/open?id=1ZsfLhI7wES8JnTOGMRxW234Wox7wNyFO

1 out of 1 members thought this post was helpful...

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.

Dear MIKE-VI,
Hmmmm...
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. Why did both GTs accept load when the Isoch one should only have? 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
>frequency.

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.

1 out of 1 members thought this post was helpful...

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.

By PC Load Letter on 21 September, 2019 - 4:14 pm
1 out of 1 members thought this post was helpful...

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)

FSRN = FSKRN1 + (TNR-TNH)*FSKRN2

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
>10sec).

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.

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! :)

1 out of 1 members thought this post was helpful...

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.

1 out of 1 members thought this post was helpful...

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 “Droop” 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’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, “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.”

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:
* 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.

* Add signals to your capture blocks so they are part of the TripLogLive and Triplog.
a. TNR, TNRI, FSRN, FSRT, L70R, L70L, L30TXA, L83SCI.

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

* 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’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.

Makster,

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.