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.
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.
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
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
>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.
>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!)
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).
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.
>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.
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
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.
How can I confirm whether GT-2 was on Isoch mode or not? Is there any signal which I can see?
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!
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.
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!
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.
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
>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!
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!
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
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!).
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.
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?
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
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
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.
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.
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).
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 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).
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 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....
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.
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.