Ge gas turbine 9fa Not Reaching Base Load in Remote Mode (DCS Control)

During normal combined cycle operation, the GE 9FA gas turbine was operating under Remote control via DCS. Despite favorable ambient and process conditions, the unit was not reaching base load. However, when switched to Auto (local) and the base load command was issued directly from the turbine HMI, the unit successfully reached full base load and entered temperature control mode.

Observed Behavior:
In Remote (DCS) mode:

Unit remained in Speed/Load control.

IGVs stayed partially open (~85°).

Firing temperature (TTRX) was below its control reference (TTRF).

MW output plateaued below expected base load (~XYZ MW).

In Auto (Local) mode:

Manual Base Load command was initiated from the HMI.

Unit ramped up FSR and MW output.

IGVs opened fully (~88°).

Firing temp approached the control limit.

Unit entered Temperature Control mode.

Full base load was achieved successfully.
 
This also happen at hot day ambient temp 37c we reach base load 219 mw at 85degree of igv status is base load and when start evap cooler mw increase to 225 and igv decrease to 82 degree
When We change mode from Remote to Auto and select load from remote to base load unit start open8ng igv and increase load to 240mw and status is base load
 
@Zikwa,

How old is this unit?

Is this behavior something new or has it just started recently?

When the unit is in REMOTE mode is there a BASE LOAD selection button on the DCS screen(s) to initiate loading to exhaust temperature control? If not, how does the operator try to load the machine to BASE LOAD--by increasing some load reference value (and if so, which load reference value: Pre-Selected Load Control, or some kind of REMOTE load reference)? Or does the operator just keep clicking on RAISE SPEED/LOAD on the DCS until the machine reaches exhaust temperature control (BASE LOAD)?

Is there some kind of "temperature matching" that was active when the unit was running in REMOTE mode? Maybe for the steam turbine (I'm presuming, based on your photo, the machine operates in Combined Cycle mode)?

Can you tell us what the TNR value was when the machine was in REMOTE mode and would not reach BASE LOAD?

Can you tell us what the TNR value was when the machine was in AUTO mode and running on exhaust temperature control (BASE LOAD)?

Did someone try to switch the machine back to REMOTE mode after achieving BASE LOAD in AUTO mode? If so, what happened? If not, why wasn't it attempted (switching back to REMOTE mode after achieving BASE LOAD)?

In general, TTRF is a CALCULATED value of the temperature of the hot combustion gases leaving the first stage turbine nozzle--it IS NOT any kind of control limit or setpoint. It's just a calculated value that is used for determining when to change combustion modes as the machine is loaded or unloaded--a "switch". The value of TTRF is compared to some Control Constants to determine when to change combustion modes as the machine is loaded or unloaded.

TTRX (it stands for Turbine-Temperature Reference eXhaust) is a calculated exhaust temperature reference that is compared to TTXM (the average exhaust temperature value determined from working exhaust thermocouples minus the highest and lowest exhaust thermocouple readings). TTXM should almost never be higher than TTRX, but TTRF has nothing to do with gas turbine exhaust temperature--it's just a calculated value of the temperature of the hot combustion gases leaving the first stage turbine nozzle. (This temperature (the hot gases leaving the first stage turbine nozzles) can't be accurately measured for several reasons. First, it would involve putting some device in the hot gas path between the first stage turbine nozzle and the rotating first stage turbine buckets (blades). It would be what's called a "rake"--a device that has multiple sensors in it. And if it ever broke it could cause serious damage to the turbine buckets and nozzles. Also, the temperature of hot gases flowing through the first stage turbine nozzles is not uniform from top to bottom--it is somewhat stratified, so accurately measuring the hot gas temperature and then taking a median or average value would be difficult. Because of the temperatures of the hot combustion gases it would likely be necessary to use something other than thermocouples (such as an infrared sensor, for example) and measuring multiple locations in the hot gas flow leaving the first stage turbine nozzles would be difficult--and dangerous, again because of possible liberation of parts into the hot gas flows through the turbine section.) Therefore, the temperature is calculated using a proprietary algorithm and decades of empirical data gathered from combustion laboratory testing and actual measurements from running machines (taken for short periods using very expensive equipment). TTRF is a pretty good approximation of the hot gas temperatures flowing into the first stage turbine buckets, but it's still only a calculation (unless GE has developed some kind of extremely high-tech and robust (strong; long-lasting) new sensor).

PLEASE try to answer all the questions above with as much detail as possible. Without more information there's not very much we can offer in the way of concise advice. REMOTE mode of operation is usually very specific to a particular turbine site/location because of the way the owners want the machine to be operated remotely. It can have a lot of conditions (called permissives) and limits based on things like HRSG (boiler) protection; steam temperature matching; auxiliary firing of burners in the HRSG, etc.--things that not all sites/location have or use. If you're not familiar with using the GE Mark* HMI to investigate the logic/sequencing used in the Mark* there is probably some kind of plant operation document the plant designers used to explain how the plant was intended to be operated that might be of some great help to you because it will likely have some details we are aware of that may help you to understand how and why the machine was configured/programmed the way it was.
 
12 years
This started recently
Tnr 3000rbm
No base load button in dcs
There is Remote load reference from dcs we give the maximum load from dcs like 255mw and it is automatically raised by Mark 6
The unit latch base load with igv not fully open at 85degree and when start evap cooler unit raise load due to decrease in inlet temp but not latch base load and igv close to 80 degrees and we are at speed load
We try to switch the machine back to REMOTE mode after achieving BASE LOAD
The unit decrease load and igv close and status is speed load control ,out of base load
We think the problem coming from dcs setpoint of load
 
@Zikwa,

TNR stands for Turbine Speed Reference (N is the common mathematical variable symbol for speed). It's always a number expressed as a percentage of rated speed--for a Frame 9FA GE-design heavy duty gas turbine the rated speed would be 3000 RPM. When the machine is synchronized to a well-regulated grid (I'm presuming the machine is synchronized to a grid of some sort with many other generators and their prime movers) and operating in Droop Speed Control with a Droop regulation setpoint of 4%--the typical Droop regulation setpoint for GE-design heavy duty gas turbines in operation around the world-- and producing 25% of rated power (turbine nameplate rated power, and let's say for example that turbine nameplate rated power is 220 MW) that TNR would be approximately 55 MW (0.25*220) for a value of 101%. (For a machine with a 4% Droop regulation setpoint Base Load would occur when the IGVs were at maximum operating angle and TNR was approximately 104%. 25% of 4% is 1%, added to 100% rated speed equals 101%. So the machine--to produce approximately 25% of rated power would have a TNR of 101%--telling the machine to operate at 101% of rated speed, which it can't do because it's synchronized to a grid with many other machines running at or very near rated grid frequency (50.0 Hz) so it's speed is limited to 100% of rated to produce 50.0 Hz (3000 RPM).

In order to get 50 Hz out of every electrical outlet and at the motor starter for every motor connected to the same grid EVERY generator and its prime mover has to be running at whatever speed is required to make the generator produce 50 Hz--and in the case of a GE-design Frame 9FA heavy duty gas turbine that's 3000 RPM. That 1% extra speed reference causes more fuel than is required to flow into the machine which would normally increase the machine speed above 3000 RPM--but it CAN'T go faster than 3000 RPM because it's SYNCHRONIZED to a grid with many other machines running at rated speed to produce 50.0 Hz in order for the frequency of the grid to be and remain at 50.0 Hz. The extra torque produced by that extra fuel gets converted by the generator to amperes and that means the amperes flowing out of the generator will be at approximately 25% of rated for a machine with 4% Droop regulation setpoint and operating in Droop Speed Control. That's how AC (Alternating Current) power generation works.

If one wants to increase the electrical power output of the machine to approximately 50% of rated one needs to increase TNR (the machine's turbine speed reference) to 102% which will cause more fuel to flow into the machine and the generator will convert the extra torque that would normally cause the machine speed to increase--but it CAN'T because it's synchronized to a grid with many other generators and their prime movers all running at or very near 50.0 Hz--into more amperes.

When TNR reaches approximately 104% and the IGVs are at maximum operating angle and the machine is in a nearly new and clean condition and the ambient pressure and temperature and the HRSG backpressure is within specification and the fuel is as per specification the machine should be at Base Load and producing approximately turbine nameplate rated power, in our example that's 220 MW.

TNH--the machine ACTUAL speed (TNH means Turbine Speed-High-pressure shaft)--should always be at 100% when synchronized to a well-regulated grid. The difference--the ERROR--between the machine's speed reference and the machine's actual speed (TNR and TNH, respectively) is the value that decides how much fuel is to be flowing into the machine. 100% TNR means that only the amount of fuel needed to make the machine run at 3000 RPM should be flowing into the machine (if synchronized this would mean 0 MW). 101% TNR (for a machine that is running in Droop Speed Control and has 4% Droop regulation) would mean approximately 25% of rated load (55MW in our example of a machine rated at 220MW). 102% TNR would mean a load of 50% for the same machine, or 110MW. 103% TNR would mean a load of 75% of rated, or 165MW. And a TNR of 104% (for the conditions previously stated--machine in a new and clean condition (meaning a clean compressor, relatively clean turbine inlet air filters, and hot gas path components in reasonable good conditions (nozzles and buckets) burning fuel within specification and ambient temperature and pressure at turbine machine nameplate conditions and exhaust duct backpressure within specifications the machine load would at or very near to rated load of 220MW (in our example). AT ALL TIMES the machine actual speed would be at or very near to 100% (because the frequency of the grid it was synchronized to was always at or very near 50.0 Hz). This would make TNH approximately 100% (which is normal and desired) and as the ERROR between TNH and TNR increases the amount of fuel flowing into the turbine would increase as would the load the machine is carrying increase, and under these same conditions (stable grid frequency and machine actual speed) a decrease in the ERROR between TNR and TNH would result in less fuel flowing into the machine as would the load being carried by the machine would decrease. This is how normal operation works in AUTO mode.

Your mission, should you choose to accept it, is to monitor TNR, TNH and DWATT when the machine is operating in AUTO mode and at Base Load (with BASE LOAD active through the button on the GE Mark* HMI), and then have the operator switch the machine to REMOTE mode and see what happens to the three values. If possible it would be best to also monitor two logic signals: L70R and L70L to see what is happening to the signals that raise and lower TNR after switching to REMOTE. DO NOT attempt to gather data while the machine is operating with Pre-Selected Load Control in AUTO mode. If there is someone at site who is familiar with Toolbox/ToolboxST they can use Trend Recorder or Trender to capture the data for analysis for these signals. They could also investigate the signal the DCS sends to the Mark* turbine control when the machine is operating in REMOTE mode. There is one more signal which could be monitored, L83AM, which might help understand what's happening when transitioning from AUTO mode to REMOTE mode.

I, too, suspect the problem is something associated with how the load command (load reference) is being generated and sent to the Mark* turbine control system. That's an educated guess--especially since the machine will go to BASE LOAD in AUTO mode when commanded to by enabling the BASE LOAD button on the HMI.

Please let us know what you discover and how you solve the problem.
 
OK you are write I'm sorry for tnr I think thh that my fault.
Tnr get value from dcs when in Remote as we control the rate of load
I think the problem coming from the load set point signal generated in dcs
We will search for the root cause and when reach I will discuss with
Thank you for your interest
 
@Zikwa,

Typically (but not always--especially because this machine was configured using GE Belfort control philosophies and schemes) what happens when REMOTE mode is configured at the factory is that there is a group of "blocks" in the Mark* turbine control application code (the "program") that receive some kind of signal, either two discrete signals or an analog signal; it could even be a digital signal representing a load setpoint (command) using MODBUS or GESM (GE Standard Messaging protocol) to change TNR when REMOTE mode is enabled and active.

If it's two discrete signals, one for raising and one for lowering TNR (using two discrete signals, one to drive L70R and another to drive L70L to raise and lower TNR) that would mean that something in the DCS that is sending the raise or lower machine speed reference somehow doesn't recognize the machine is operating at BASE LOAD when REMOTE mode is selected, and wants to reduce load below the load the machine was operating at before REMOTE mode was selected. (Yes; one of the things may happen when load is reduced is the IGVs may close slightly as fuel flow-rate is reduced). OR some limit on the maximum load of the gas turbine might have been lowered when running in REMOTE mode.

If it's an analog signal or a digital signal using MODBUS or GSM, that gets written into an analog load remote setpoint value then something in the DCS doesn't think the machine should be running at BASE LOAD when REMOTE mode is selected.

It's something like this--but without being able to see the application code running in the Mark* turbine control system it's very difficult to say what is happening. Hopefully there is someone at your site that can review the application code running in the Mark* turbine control system and determine if the problem is the DCS or the Mark*--and then there needs to be someone at the site who can read the program/logic/sequencing running in the DCS to see what might be causing the problem there if it's not in the Mark*. If the system has been running fine for many years and this problem just started, well then something has to have changed--either in the Mark* or the DCS.

The thing about digital control systems is they don't (generally) "drift"--meaning the settings/parameters in digital control systems don't change over time. These things are usually the result of some changes made to the digital control system that resulted in unintended, one-off, unforeseen consequences. So, if someone has been making changes in either, or both, the Mark* and/or the DCS recently (just prior to the start of this problem) THAT is where you need to start looking for some problem or issue.

We look forward to hearing what you discover and how the problem is resolved.
 
@Zikwa,

Typically (but not always--especially because this machine was configured using GE Belfort control philosophies and schemes) what happens when REMOTE mode is configured at the factory is that there is a group of "blocks" in the Mark* turbine control application code (the "program") that receive some kind of signal, either two discrete signals or an analog signal; it could even be a digital signal representing a load setpoint (command) using MODBUS or GESM (GE Standard Messaging protocol) to change TNR when REMOTE mode is enabled and active.

If it's two discrete signals, one for raising and one for lowering TNR (using two discrete signals, one to drive L70R and another to drive L70L to raise and lower TNR) that would mean that something in the DCS that is sending the raise or lower machine speed reference somehow doesn't recognize the machine is operating at BASE LOAD when REMOTE mode is selected, and wants to reduce load below the load the machine was operating at before REMOTE mode was selected. (Yes; one of the things may happen when load is reduced is the IGVs may close slightly as fuel flow-rate is reduced). OR some limit on the maximum load of the gas turbine might have been lowered when running in REMOTE mode.

If it's an analog signal or a digital signal using MODBUS or GSM, that gets written into an analog load remote setpoint value then something in the DCS doesn't think the machine should be running at BASE LOAD when REMOTE mode is selected.

It's something like this--but without being able to see the application code running in the Mark* turbine control system it's very difficult to say what is happening. Hopefully there is someone at your site that can review the application code running in the Mark* turbine control system and determine if the problem is the DCS or the Mark*--and then there needs to be someone at the site who can read the program/logic/sequencing running in the DCS to see what might be causing the problem there if it's not in the Mark*. If the system has been running fine for many years and this problem just started, well then something has to have changed--either in the Mark* or the DCS.

The thing about digital control systems is they don't (generally) "drift"--meaning the settings/parameters in digital control systems don't change over time. These things are usually the result of some changes made to the digital control system that resulted in unintended, one-off, unforeseen consequences. So, if someone has been making changes in either, or both, the Mark* and/or the DCS recently (just prior to the start of this problem) THAT is where you need to start looking for some problem or issue.

We look forward to hearing what you discover and how the problem is resolved.
You know that there is relation between inlet air temp and mwatt and we find in Mark 6 that every temp predict max mwatt allowable from chart and have signal mwatt_mcr and this signal send to dcs and named as max allowable mw from gas turbine
So when we at remote and hot day the setpoint of this value give low value so max mwatt set point for ex. 234 mw send to dcs which depend on chart from Mark 6 at same time gas turbine don't depend only on this set point of max allowalble mwatt and can give more power at this temp
As at 234 mw gas turbine still not reach temp control mode and igv is not fully open so BASE LOAD not reached
So max mwatt setpoint available for gas turbine is higher than max mwatt setpoint allowable send to dcs
And if we change mode from remote to gas turbine base load mode the mark 6 will go to the max mwatt available based on gas turbine conditions not based only inlet temp
This my conclusion of what I find
Ask Allah to be write
 
@Zikwa,

This actually happens more frequently than one would expect it should—choosing a signal from the Mark* database without understanding how it actually works or if it’s the correct signal for the application.

I think you said previously that the machine had started recently, so something must have changed. While ambient air temperature has a lot to do with how much power the gas turbine can produce it’s just one of many factors. I’m presuming the Mark* turbine control system is a Mark* VIe variant or an upgraded Mark* VI (using Mark VIe-compatible components). I believe you have discovered the signal that is causing the DCS to prevent the machine from reaching true Base Load—but I would be surprised if ambient air temperature is the only issue causing the problem with the maximum allowable load calculation—and it IS only a calculation, not a hard and fast value.

I also believe that if the maximum allowable load calculation is not deriving a more meaningful value that the Mark* has at least one Diagnostic Alarm and at least one Process Alarm that is trying to alert a conscious operator, operations supervisor or control engineer of a problem with the calculation. And those alarms are being… “overlooked” by more than one person. The “model” responsible for the calculation of maximum allowable load is fairly sophisticated—but it’s also considered to be proprietary information by GE and as such it’s not well documented. I also suspect that GE has some kind of contractual services agreement which likely includes troubleshooting assistance—especially for these kinds of model issues. They are probably monitoring the machine and should be concerned about the difference in the actual achievable load and the calculated maximum allowable load and one would think they would be keenly interested in resolving the issue as they want the model to be very accurate.

Anyway, congratulations on finding the issue with the DCS calculation, but I strongly suspect it’s more than just ambient air temperature that’s the problem. Unless the value of ambient air temperature (or compressor inlet air temperature) the Mark* is receiving is very inaccurate—and it should be coming from redundant sensors and a significant difference between the sensor values should also produce alarms….

Please let us know what you discover and how you resolve the issue. Again, I would think GE would be very interested to know about this problem and want to help resolve it.
 
Mark 6 e
You are accurate we find also that there is difference in sensors value and it is clear when run evap cooler
26_ 31.2_ 31.4
And system choose 31.2 to make calculation and we see that 26 is real value because the other unit is 26 with evap
I know that will affect the every thing it be ussed in calculation, like firing temp will decrease the operating margin for it and will also decrease the calculation for predicted mw
And that what you mean and may be the reason that predicted mw not the same that the unit are able to reach
 
@Zikwa,

My question--not understanding how the plant is operated and how the DCS wants to control the gas turbine--is, why is the DCS using the calculated maximum allowable load when determining what load signal to send to the Mark*?

It seems from what I think I understood about how you are trying to operated the machine in REMOTE mode from the DCS that when you want the machine to go to maximum allowable load--based on ambient and machine conditions--that the operator enters a value of load which is more than the actual maximum allowable load (maybe more than the gas turbine nameplate rating.?.?.?) and that then gets "conditioned" by the calculated maximum allowable load to prevent exceeding the calculated maximum allowable load. That seems ... odd, to say the least. I don't understand when the DCS needs to know the calculated maximum allowable load to determine what load signal to send to the Mark* after the operator inputs a load setpoint (reference). That just seems so unusual. To me.

This ISN'T the problem, however. The problem IS that the ambient temperature inputs to the Mark* are not equal and the Mark* is miscalculating the maximum allowable load--which really shouldn't be used for control purposes (in my personal opinion--I want to be clear about that, it's just my opinion). The calculated maximum allowable load value is used in the Mark* for what's called "model-based control" (sometimes abbreviated as MBC). GE officially calls it ARES: Adaptive Real-time Engine Simulation. This is a fancy way of monitoring actual turbine operation using a LOT of sensors and comparing the actual operation to that of a model running in the Mark* to check to see if the machine is operating properly and efficiently and to alert operations personnel to a possible problem. The model is considered Company proprietary information by GE and no one really knows exactly how it works and does its magic--because the internal processes and equipment and the model are mostly patented. GE's analogy is that when you buy an automobile with computers running the engine (and transmission) the algorithms and programming of the computers doesn't belong to the purchaser. The manufacturer is allowing you to use the algorithms and programming in the car you purchased from them--but the actual algorithms and programming are the property of the manufacturer. Forever.

This leads to most people taking their automobile to the dealer they purchased the car from or to the shop of a dealer that sells the brand of automobile they own (whether they purchased it new or bought it used). In this way, the automobile manufacturer--and the dealer--make money on service and troubleshooting and repairs (after the warranty period is over), and the guy down the street who is not affiliated with any automobile manufacturer (and is probably less expensive) doesn't get any work because he doesn't have the tools (computers and software and cables) to troubleshoot problems. GE wants to keep as much of the service and maintenance of their machines as possible. GE wants to sell as many parts as possible, and prevent others from copying their designs and algorithms and programming. GE believes they are entitled to sell their parts and service on the machines they designed and built and programmed.

MBC, or ARES, is a great idea that hasn't always been implemented very well. Yes; GE knows very well how to design--and model--heavy duty gas turbines. And documenting MBC, or ARES, means that other manufacturers, parts manufacturers and service providers can see how the machine was designed to operate and copy or even improve the performance and/or longevity of the machines that GE designed. So, the documentation is sparse if it exists at all.

Anyway, I believe there are--or should be--alarms, Process- and Diagnostic Alarms--announcing the fact that there are sensor problems. Yes, it’s true: A single Diagnostic Alarm won’t trip a turbine, HOWEVER there are combinations of Diagnostic Alarms that can trip a turbine. OR, as in this case, Diagnostic Alarms can warn of loss of power if interpreted correctly. Diagnostic Alarms are NOT nuisance alarms (though they can be! if not properly managed and resolved). Yes, Diagnostic Alarm messages can be cryptic and seem odd, but they can also be useful in keeping a machine in good running order, reliable and available. But only if they are not ignored or brushed aside because someone thinks they won’t trip a machine.
 
@Zikwa,

It's good that you're happy. It's odd the other machine seems to have three CTIM T/Cs that all read the same temperature, and yet the three on this one machine don't indicate the same temperature. I have seen similar problems caused by the thermocouple extension wire terminations not being connected properly. T/Cs use two dissimilar metals for the extension wires; GE typically uses Type K (Chromel/Alumel) T/Cs and extension wire. All along the entire length of the wiring between the T/C and the Mark* terminal board the chromel wires have to be connected to each other for each T/C and the alumel wires have to be connected to each other for each T/C. It seems, to some untrained or inexperienced people that since T/Cs are just a two-wire device they don't need to be connected in any special manner--but that's not true with T/Cs and T/C extension wire (the wire used to connect the T/C to the Mark* terminal board, usually a long distance from the T/C).

Usually, the T/C leads and the T/C extension wire have a wire with red insulation and one with yellow insulation. At EVERY junction of the T/C the red wires need to be on opposite sides of the terminal board and the yellow wires also need to be on the opposite sides of the same terminal. (CAUTION: In some parts of the world, Type K T/C extension wire has red and white leads--and the red wire is the opposite polarity of the red wire of the red/yellow configuration. For chromel/alumel Type K T/Cs, one of the leads is magnetic, and the other is not.)

It's pretty easy to check the T/C terminations to make sure the connections are done correctly; it often happens that during a maintenance outage the wires get connected incorrectly and that can cause a difference in the readings of a few degrees for lower temperatures and tens of degrees for much higher temperatures (like wheelspace and exhaust T/Cs).

Finally, sometimes GE uses Type K T/Cs for measuring compressor inlet temperature that don't have physical wires coming out of the T/C assembly--there's just a small brass screw compression connector where T/C extension wire is to be connected. And, sometimes, it's VERY difficult to determine which screw is for the red wire and which is for the yellow wire.... Sometimes there is just a little drop of red paint on the brass barrel and it can get scraped off or lost.

Anyway, again, it's good that you're happy with the root cause analysis. Me, I'm still questioning why the DCS uses the calculated maximum allowable load to "bias" (modify; adjust) the signal going to the Mark*. That just doesn't seem to be an ideal scheme. Not at all. If this scheme limits power production when it shouldn't, then it's not a good situation (because companies, investors and employees get paid based on power production and if it's artificially limited when it shouldn't be, well then ...).

Tchau!
 
CTIM is not a median, its the max comp inlet flange temp. If you want a better compressor inlet temp reference, send the three inlet thermocouples through a median select function and use the output of that. That would allow for a failure high and a failure low to get thrown out. The inlet thermocouples are usually CTIF#; CTIF1A, CTIF2A, and CTIF1B (or similar, GE changes the designation from site to site sometimes).
If you were having an issue with these thermocouples you would also get a corresponding alarm, LCTIF_ALM "comp inlet flange temp high spread". The flange high spread happens when one half of the evap deck is not pumping. IE the west sides pump isn't running but the east side is so only one half of the media is wet.
In my opinion, your DCS shouldn't be doing all of this extra work, just use the CABLE REMOTE function to tell the Mk to go to base and let the Mk do the leg work.
 
This is a common but complex issue. First, verify the DCS is sending the correct and expected load reference signal. Then, systematically check for any active alarms or limits in the Mark VIe that might be restricting output (e.g., temperature spreads, vibration, auxiliary load limits). Often, the root cause is a mismatch in control parameters or a protective limit being tripped in the turbine controller itself, not the DCS command. Coordinating with the control system engineer for a signal trace is the most effective next step.
 
Top