SB,

It's really difficult to troubleshoot a Speedtronic turbine control panel from the CIMPLICITY displays; they just don't update very fast (faster than many HMI applications, but still not really good for troubleshooting), they are quite often configured incorrectly or lack sufficient decimal places, and CIMPLICITY is not very consistent when rounding numbers.

I agree that it should be possible for two seemingly similar turbines, both with the same turbine control system (actually, we don't know if both the Mark VIs were installed at the same time, or if both are SIMPLEX or both are TMR or one of each) would theoretically be capable of nearly identical control parameters. But, again, the differences here are negligible. If you were looking at analog meters you would barely be able to discern any difference at all--and that's one of the knocks on digital control systems and digital metering: sometimes there's too much data and too much resolution.

Without being able to get meaningful data from Toolbox with consistent decimal places it's really difficult to tell exactly what the cause of this "difference" is. I would venture that 49.9 HZ is better regulation than the national or local grid in your area on a good day--especially if it's a consistent 49.9 Hz.

Operators should be allowed access to Toolbox for familiarization and troubleshooting. If Toolbox is marked with a Read-Only attribute--<b>which it should ALWAYS be <i>except when making modifications to configuration or calibration</i></b> then when it's opened no one can make or save any changes to the file/configuration. And most changes--including forcing logic and such--require knowledge of the appropriate password (and a Toolbox file that is marked Read-Write). So, there should be no issues with operators opening a Read-Only version of Toolbox for information, familiarization and understanding. I would recommend that after any modifications or changes, a copy of the most recent Toolbox file be created with a unique name the operators can remember and the file attribute should be marked Read-Only. Then, operators can open "their" file and surf to their heart's content without interrupting or causing any issues. (I know--this is a stretch for most Maintenance Managers and even for Operations Managers, allowing operators to have access to Toolbox; but with the proper precautions as mentioned there should be no issues as long as no operator goes rogue and decides to force logic (which is a multi-step process requiring a password)) or make changes to Control Constants, which <b>no one</b> should do without understanding the effects of making such a change.

I applaud you for trying to understand why this minute difference exists, and I even concur there should be a discernible reason and resolution to the issue--or at least a reasonable explanation. But, if you're beholden to the I&C or Maintenance Department for assistance and access to Toolbox then this is going to take a long time and probably will not be resolved in our lifetime--or even before the Mark VI is replaced with the Mark VIII (NO; there's no Mark VIII yet, though there is new Chinese-made/programmed GE control system hardware out on the market for turbine control retrofits...).

I suggest you work with your supervisors and the I&C/Maintenance Dept. supervisors to allow access to Toolbox, and then we can try to troubleshoot this issue. Without such access it's going to be extremely difficult to continue.

Hope this helps!

 

CSA,
Thank you for the reply.

Both our units are running TMR Mark6, both are commissioned at different times. Unit 2 was upgraded from Mark4 to Mark6 followed by Unit 1.

In your replies to other threads I read your advice of making a copy of <b>m6b</b> file and marking it Read Only and using it for learning purposes. And also I came to know of different privilege levels and passwords for using Toolbox from reading your posts on the forum. Once I tried to explain all this to our I&C personnel and requested him to let me allow access to Toolbox, but for some reasons beyond my comprehension they didn't. I'll try again.

Recently Unit 2 has tripped due to some <b>"mysterious control system fault"</b>, everybody is busy analyzing it(Expert has also been called in) and I'll have to wait till they sort out the things. I've not posted a new thread for discussing this tripping cause I know that I'll have to provide lot of information which I'll not be able to do in a timely manner. 3 cards(VPRO,VCMI and UCVE) has been changed so far(I'm reading GEH6421_vol_ii to get a better idea of all this cards) and still everything's not alright. Processor "S" is unable to communicate with other processors. I read lot of threads regarding this and other similar issues on the forum.

There was an alarm <b>ALMARM XMIT SUSPENDED. CPU SWITCHED</b> prior to tripping. I've also read 4-5 threads related to this.I got some idea but I'm not able to understand it fully. It'll be good if you share your knowledge regarding this alarm here or may be I can post a new thread if you prefer so.

And yes, there's also a serious battery ground issue on this Unit.

Thank you for helping me learn GE heavy duty gas turbine control system.

 

CSA,

This is a very old thread but as it seems that our problem is solved now, I'm posting here.

Last week one GE TA came to our site (to resolve some other issue), we checked the value of TNRI and it was 100%. TNH was 99.8%. As per my knowledge TNH should also be 100% as it follows TNRI, but it is not. The GE TA told me about FSKRN3, which is 3.13%/%. Further he said that this much error is allowed in TNH and that is the reason TNH is less than TNRI. But if this error is allowed then TNH should also be more than 100% sometimes, but that is not happening. I'm not fully satisfied by his explanation. I'll be very thankful to you if you take the time to explain this. I'll provide any data in timely manner if required.

CSA, I'm waiting for your valuable reply.

 

SB,

Hmmm....

I've re-read the entire thread, a couple of times, and I'm not really sure about a lot of things.

Does the plant operate sometimes in parallel with the grid, and other times independently of the grid?

Was the machine operating in Isoch speed control when the GE TA was on site?

What is the value of FSKRN3 on the other machine at your site?

What was the load on the machine at the time you were observing TNH?

I don't have access to my archives of past jobs to look specifically at other jobs to see what the value of FSKRN3 was, nor to look at the algorithm to see exactly what FSKRN3 does. Can you tell us which algorithm FSKRN3 is used in--I suspect it might be a version of FSRNVn, where "n" is the version number (2, or 3, most likely), but that's just a guess on my part.

If I remember correctly, when a GE-design heavy duty gas turbine-generator with a Speedtronic turbine control system is operating in Isoch speed control independent of a grid (so, in "island mode") the typical value for the speed/frequency deadband is 0.13%--so the frequency is allowed to vary between 99.87% and 100.13%. So, the frequency won't always be exactly 100.0%, but it should be less than approximately 99.87% (unless there is a sudden, big increase in load) nor more than approximately 100.13% (unless there is a sudden, big decrease in load). And, if the load is not very stable then it's possible for the speed/frequency to be constantly varying between 99.87% and 100.13%.

I seem to recall that the typical value of FSKRN3 is usually 1.00%/% (since it's a gain), and so it would seem someone has tried to "tune" Isoch speed control at your site. But, this is also just a SWAG (Scientific Wild-Arsed Guess) since I don't have access to any old files/drawings at this writing.

Isoch speed control shouldn't be used when operating in parallel with a grid, and unless Isoch Load Sharing is used on two or more machines operating in parallel <i>independently of a larger grid</i> then only one machine should be operating in Isoch speed control if two or more machines are operating in parallel. There's a lot we don't know about the configuration of your site, so it's really difficult to say for certain.

 

CSA,

>Does the plant operate sometimes in parallel with the grid, and
> other times independently of the grid?
the plant operates on Island mode always.

> Was the machine operating in Isoch speed control when the GE TA was on site?
yes,the machine was operating in Isoch mode

> What is the value of FSKRN3 on the other machine at your site?
FSKRN3 is 3.13%/% (percent/percent) on both machines.
<b>Moderator's note:</b> the special characters in the above fraction are now displayed correctly.

> What was the load on the machine at the time you were observing TNH?
TNH was same when load was 17MW or 20MW.

Can you tell us which algorithm FSKRN3 is used in?
FSRNV4

 

sb,

The question:

>>Does the plant operate sometimes in parallel with the grid, and
>>other times independently of the grid?

Your answer:

>the plant operates on Island mode always.

The snippet below is from the original post of this thread:

>GT#1 is not able to attain 100% rated RPM (5105) when run in
>Isochronous mode. While it runs at 100% rated RPM when run
>in Droop mode and synchronized with the greed [sic].

I interpreted "greed" to be "grid"--so it would seem the units sometimes operate in parallel with the Indian grid. Yet, now you say it doesn't.... By "greed" do you mean the isolated transmission and distribution system the two generators are supplying--the "island"?

Is there some kind of external "PMS" (Power Management System) controlling the load of the two GTs when operating in parallel to supply the island load independent of the grid?

I imagine 20 MW is probably pretty close to Base Load for these machines.?.?.? If so, then operating an Isoch machine at or very close to Base Load is going to result in low frequency. When the unit reaches Base Load it can't increase it's power output any more in response to increases in system ("greed") load. So, the frequency decreases in this case.

And, the ONLY way to change the load on the Isoch machine is to change the load on the Droop machine--<b>YES</b>, you read that correctly. To change the load on the Isoch machine one has to change the load on the Droop machine. So, if the Isoch machine is running at 20 MW and it's at or very near Base Load and the system ("greed") load is expected to increase, the operator (or the PMS) needs to increase the load on the Droop machine--which will decrease the load on the Isoch machine. So, if the load on the Droop machines is 10 MW when the load on the Isoch machine is 20 MW, if the load on the Droop machine is increased to 14 MW, the load on the Isoch machine will decrease to 16 MW--the same amount of load that was "moved" to the Droop machine by increasing it's load. Then the Isoch machine is free to respond to any system ("greed") increase to maintain frequency.

The above supposes there is a PMS doing the load balancing, or that there is an operator doing the load balancing. But, something--or someone--needs to keep the load on the Isoch machine below Base Load, and above 0 MW, to keep the Isoch machine capable of responding to changes in system ("greed") load.

Now, it would also seem that someone has been mucking with the FSKRN3 value to try to affect either stability or load-carrying/load response characteristics of the two machines. I don't have access to my old files at this writing, so I can't look at a FSRNV4 block to see exactly how and where FSKRN3 is used--it it's active during Isoch or Droop, or both. So, I have to reserve comment for a time when I can examine a FSRNV4 block to see how FSKRN3 is used.

A governor running in Isoch--without Isoch load sharing or some kind of external PMS--will automatically change it's load in response to system ("greed") load changes. If a large motor is started and adds 1 MW of load to the "greed" the Isoch machine will increase its load by 1 MW--to keep the grid frequency constant. And, this will happen until the unit reaches Base Load--and then it can't increase its load any more, and if the "greed" load increases then the "greed" frequency will go down.

In the case where there's a Droop machine operating in parallel with--synchronized to--the Isoch machine, someone--or something--should monitor the load on the Isoch machine, and when it approaches Base Load then the load on the Droop machine should be increased, which will decrease the load on the Isoch machine by the same amount.

Or, if the load on the Isoch machine approaches 0 MW, someone-or something--monitoring the load on the Isoch machine should decrease the load on the Droop machine which will increase the load on the Isoch machine by the same amount. This will keep the Isoch machine from tripping on reverse power should the load decrease below 0 MW.

Now, some sites try to use an external control system, sometimes called a PMS or something similar, to monitor the system load and the loads on the two machines and shift load to keep the Isoch machine from running near 0 MW or near Base Load. This allows the Isoch machine to automatically respond to "greed" load changes and maintain frequency (assuming the governor has been tuned properly, or not "de-tuned"). Some of these systems actually work pretty well--but most do not. And, many sites don't have these systems--and rely on human operators to monitor the loads on the two machines and shift load as necessary to allow the Isoch machine (when properly tuned) to respond to load changes in order to maintain frequency. Some operators understand what is happening and what their role is--many do not. And, this goes for their supervisors, also--many of which ascended to supervisory roles from operator roles.

I doubt, given your other posts, that you--as an operator--are going to ever solve this problem at your site. All you can do is hope to understand how you should be operating the machines and operate them in accordance with the standard operating procedures at your site. You may, at some point, be able to amend or modify the procedures as appropriate to make operation better--but I suspect that will take years, maybe decades. Power plant operators are loathe to do anything differently than "the way we've always done it" because they are so afraid of losing their job. Tribal "knowledge" isn't always correct, and there is a definite lack of training at most site--everyone ass-u-me-s the control systems are omniscient and will operate and control everything properly. But, most don't have the level of programming and sophistication it's ass-u-me-d they do, and never will. There is no substitute for training and experience--that's what SOPs (Standard Operating Procedures) try to act as a substitute for.

Best of luck--hope this helps!

 

CSA,
Your answers always help, technically and otherwise.

Now, coming to the reply. We have two identical Frame 5 GTs with 25MW rating to supply our plant load ONLY. What I was referring to as "greed" (grid) earlier is not Indian grid, but only the plant load. My bad for that. Sorry!

One machine runs on ISO and the other on Droop mode. There is no external load management system. The operator increases/decreases load on the Droop machine as per the requirement.

Nobody has ever changed ANY constant since 2008 (when the site upgraded from MKIV to MKVI).

When one machine was running at 20MW on ISO,the other machine was in tripped condition. We were sure that NO extra load will be added to the system at the time.

And finally, talking about Base load of the ISO machine: From reading your posts on the forum I've learned that at base load the IGV will be 84° open. That was not the case. IGV position was 58°, so, I ass-u-me that the machine was not running on base load.

And, I can see your frustration in answering my (stupid) questions.There is definitely lack of training and experience and resources. But still I'm trying to learn. Solving this (or other problems) is not expected from me. What is expect from me is to run the plant as "they've been running it for 26 years".

It will be very good for me if I can get ONLY 10% of knowledge you have acquired.

Your response is always welcome (and helpful in many ways).

Thank you.

 

sb,

There's no such thing as a dumb (or stupid) question--just a dumb (or stupid) answer. A former colleague of mine used to say that all the time, and it's true. (There may be a bad time to ask a question.... like when the unit is being started for the first or second time, or being started after a maintenance outage. Sometimes it's not the question--but when it's being asked. And, oftentimes "questions" are questions, but really statements, like, "It's never done THAT before!" which is my LEAST FAVORITE question of ALL time--no matter when it's asked.)

I realize that most operators of GE-design heavy duty gas turbines get very little formal training, if any--and believe it or not that includes first-world countries in North America and Europe. It's really amazing that more machines aren't wrecked and more people aren't hurt or worse, because most owners and managers believe the turbine control systems will take appropriate action in every instance, and that operators are just there to "push" the START and STOP buttons, and technicians only need to know how the turbine control system works--not how the turbine is supposed to operate. That's my frustration--not the questions. I've been to developing countries where a 25 MW gas turbine is 25% or 50% of the grid supply--and the operators have had zero formal training. And, the units trip--a lot. And get very little in the way of planned maintenance--something only gets looked at or fixed or replaced when it breaks. And, that's often sometimes. (And, of course--the turbine control system gets blamed for being "unreliable.") That's my frustration, not questions.

And, just as bad is the fact that the documentation provided by the OEM is so lacking, and in some cases, just plain wrong. It's not like the OEM can't produce good documentation--they do, for the equipment they sell to Armies and Navies and Air Forces and airlines. So, it's not an impossible task--it's just that no Customers buying heavy duty gas turbines hold the OEM accountable for documentation.

Anyway, back to the question(s). I'm not suggesting anyone changed any Control Constant after the Mark VIs were commissioned. I AM suggesting that commissioning personnel (who get minimal training) changed the values during commissioning.

Load on a prime mover and generator (any prime mover and generator) tries to slow the unit down. So, whenever there's a load on the unit (whenever the generator breaker is closed and the MWATT value is positive) the Speedtronic is trying to maintain speed. For an Isoch machine (ISO means something VERY different from Isoch!), it's continually trying to maintain speed to a very tight tolerance (USUALLY; unfortunately, I can't seem to help with the problem of why it can't maintain 100% TNH (or at least something between 99.83% and 100.17%) at your site).

The Droop machine--it's a "slave" to the Isoch machine. The magnetic fields of the two synchronous generators keep them spinning at the same speed--and the Droop governor allows for some speed error, in fact, it RELIES on a speed error to operate correctly (TNR-TNH, where it's presumed TNH is usually stable and constant at approximately 100%).

Yes; the "definition" of Base Load is that it only occurs when the IGVs are maximum operating angle (CSKGVMAX), which is usually 84 DGA, or 86 DGA for some machines, and I'm hearing as much as 90 DGA for some of the newer heavy duty gas turbines (F-class and newer).