Under the GE Mark V ITC First Order Lag function block, more specifically used under FSRNV3 - Speed Control FSR, under RESET: OUT=V, they use what appears to be a Pulse labeled "INIT" to trigger the ITC Reset to make OUT = to the Input (FSR).

Has anyone come across what enables "INIT"? My guess would be that it is short for "initialize" and is only used when a controller comes online and boots to A7. For example, in a TMR system, if <S> faults and has to be restarted, after it comes back online, it would pass the current value of FSR without the LAG to reduce any disturbances/voting between the cores.

If anyone has any GE "tribal Knowledge" and could share, that would be great!

 

@RJSolo,

If I properly understand your "question" you are correct that this is one method of bringing a non-participating control processor back into "agreement" with the Designated Voter as it comes back on-line without introducing a large error into the output to the FSR calculation. And INIT usually is short-hand notation for INITIALIZE/INITIALIZATION.

Can you explain why you need to understand this function?

 

I appreciate the feedback.

Shortly before 2025, the decision was made to replace the GE Mark V controls with an Allen Bradley based control system, using Basler excitation and Woodward SPC controllers for the gas valves and IGVs. I will not disclose the third-party integrator, but they are extremely reputable and knowledgeable within the industry.

From the beginning, I noticed a reduction in MW output across the units. Difficult to prove for quite some time but overtime, we did. The loss was approximately 2 MW during the colder months and 3–3.5 MW during the warmer months.

Over the past year and a half, I have worked through the logic to identify differences between the original Mark V system and the new system. Many differences were found and corrected, but none came remotely close to explaining the full loss in output.

When comparing equivalent operating data—even after correcting the data to our site standard conditions and accounting for historian deviation and compression, the result was consistently about the same. To obtain the same MW output, the new system generally required approximately 8–10°F lower ambient temperature.

When comparing runs at the same MW OUTPUT and disregarding ambient temperatures/pressure, FSR, exhaust temperature, compressor pressure ratio, CPD, and most of the other major operating parameters lined up reasonably well between the two systems.

It was later confirmed that all four units were experiencing the same issue. These are GE 7EA units that originally had Mark V TMR controls Running DLN. They are dual-fuel machines, although they have only ever operated on natural gas. The loss is common across all four units.

The obvious items have already been investigated, including control constants, logic execution order, exhaust-temperature references, compressor pressure-ratio calculations, transmitter scaling, instrument calibrations, IGV measurements, and many other potential causes. Digital Filters, RTS/RPI's, on each AB module have been reviewed. The fact it was seen after the upgrade, points to the upgrade. A water wash is NOT needed (someone will mention this) lol.

Eventually, I went down the dark hole and began “chasing static,”. I began looking into the internal operation of the Mark V to determine whether the difference might not be in the visible logic itself, but in how the Mark V executed that logic internally. I thought maybe there is a BIAS missing somewhere. Havent found it yet lol.

I started comparing Mark V function blocks with their Studio 5000 equivalents. One area I questioned was whether the Mark V ITC first-order lag blocks behaved differently from the Studio 5000 LDLG blocks. That is what led to my original question about what INIT actually does within those blocks. I had developed several theories, but I finally decided it was time to ask people with more direct Mark V experience.

My current theory involves the difference in execution rates between the two systems. Probably wasting my time chasing this "static". The new system uses a 128 ms task for a portion of the logic, compared with the Mark V’s 125 ms execution rate. However, much of the logic associated with FSR, gas valve control, turbine speed, exhaust temperature references and calculations, DLN fuel splits, and related functions was moved into a 32 ms task. In the Mark V, most of this logic executed at 125 ms.

I am far from being a thermodynamics engineer, but I began wondering whether executing this logic four times faster could cause certain references or control responses to advance too quickly during loading. Could this cause the unit to reach temperature control prematurely, effectively heating the machine faster than intended and limiting MW output earlier? It might also help explain why the output loss is more pronounced during warm-weather operation than during colder weather.

Mathematically, the final results should theoretically be the same, but actual machine behavior does not always follow the simplified mathematical expectation, especially when limiters, ramp rates, MIN selects, filters, and interacting control loops are involved.

I also found a reference in the Mark V Notebook files (old files) indicating that, during some Mark IV-to-Mark V conversions, constants were carried over based on the old system’s scan rates rather than being adjusted for the new execution rates. According to the document, this caused a number of control issues. Reading that is what pushed me further toward investigating scan rate dependent behavior.

Since then, I have created parallel “pseudo” logic that executes in the 128 ms task so I can compare it with the equivalent logic running in the 32 ms task. I have captured trends comparing 32ms vs 128 ms versions of FSRN, FSRT, DWATT, and related signals to determine whether the execution rate produces a meaningful difference during loading… It does. What I continue to find, however, is that once the unit settles onto temperature control, the calculated values eventually converge and appear nearly identical. That brings me back to the same question: Is the missing MW the result of something happening dynamically during the loading ramp, even though the steady state control values eventually catch up?

I could probably talk about this investigation for an entire shift. At this point, I may end up writing a book about it—if, and I do mean if, I ever figure it out.

 

@RJSolo,

The search for a root cause you are describing is often called "going down a rabbit hole" (after a famous fairy tale, Alice's Adventures in Wonderland) and can become an obsession.

Using a "generic" PLC (or PAC), Programmable Logic Controller (Programmable Action Controller) for a piece of high-speed rotating equipment control and protection is definitely possible--BUT the person/people doing the programming MUST have a very good knowledge of the process and auxiliaries. I and others on this site have seen some extremely creative and ingenious programming practices implemented for various types of controls simply because PLCs (PACs) have such a large library of functions and possibilities (macros; etc.).

We have also seen some pretty hideous control system implementations where it's obvious after a few hours of head scratching that more than one person has tried their hand at solving a problem (or multiple problems) and have just overwritten previous programmers' logic/sequencing to save time.

In my experience, the hardest part of the fuel control sequencing is the switching/transfer from Droop Speed Control to CPD- (or CPR-) biased exhaust temperature control. Add DLN-I sequencing and control (and protection) on top that and it's extremely difficult to make the transition as smooth as GE has done without some serious long days/weeks of analyzing and discussing with others how GE did it and how it can be accomplished in the PLC (PAC). And when it doesn't work it can, as you described, cause a loss of power generation particularly at "rated" load (Base Load).

A LOT of operators and power plant sites also use Pre-Selected Load Control for changing load AND maintaining stable load--without understanding how simply Droop Speed Control works and that it WILL NOT allow the load to drift when synchronized to a well-regulated grid (of any size). They think if the Mark* doesn't have a specific load reference (like the Pre-Selected Load Control reference/setpoint) that the machine load will just go up and down in an unstable manner--and that's just NOT so. They even believe that when the unit is (properly!) operating on CPD/R-biased exhaust temperature control that the machine load should remain stable. Sure, they have been told the machine responds to ambient temperature changes daily and throughout the week, months and year, but you would be shocked at how many people *(including Plant- and Operations Managers) will say, "Last month the load was 78.9 MW on Base Load and today it's 74.5 MW! The Mark* isn't working correctly!!!" and the ambient temperature is 26 deg F warmer today than it was last month. There are many other variables the turbine responds to: Turbine Air Inlet Filter cleanliness; IGV cleanliness; axial compressor cleanliness; the accuracy of the Axial Compressor Inlet temperature measurements; the accuracy of the Axial Compressor Discharge Pressure transmitters and how their isolation valves are positioned; the accuracy and isolation valve position of the P2 Pressure Transmitters; the exhaust duct back pressure (which can be affected by ammonia injection rates and insulation which has blown out from behind exhaust duct paneling and is caught in a superheater tube section; internal clearances of rotating and stationary turbine components--lots of them). The list goes on and on and on.

One of the things which I have witnessed (AFTER a non-GE turbine control systems upgrade experiencing this and other similar problems) is that during the control changeover there was mechanical work going on on the turbine, and quite often by companies OTHER THAN GE using parts OTHER THAN GE's parts. And WITHOUT FAIL the Plant Manager and Owner and the site Mechanical Department personnel and the third-party service company and the after-market parts supplier will ALL SAY, "There's ABSOLUTELY NOTHING MECHANICALLY WRONG with the work done on the turbine during the outage where the control system was also replaced!!!" Because to prove or disprove that statement the machine has to be shut down and disassembled, inspected, and reassembled--and that costs a LOT of money, as well as lost revenue generation.

Oh, and let's not forget just how COMPLICATED the turbine control system is--no matter WHO made it or configured it or programmed it. Just look at all those wires and all the LEDs, many of them flashing. The problem just MUST be somewhere in the wiring or the control system, because--it's NOT the mechanical work done on the turbine or the parts used on the turbine.

Again, myself and other contributors to this forum have encountered some pretty crafty programming and programming practices TRYING to duplicate what GE did in their PURPOSE-BUILT turbine control system. And, in my personal experience when it comes to lost power generation after a "generic" control system (my definition of generic is a PLC (PAC) like the A-B system...), particularly at Base Load, it usually comes down to the switching/changeover between Droop Speed Control and CPD/R-biased exhaust temperature control. Add to that the DLN-I control function and that is just a recipe for trouble if the people programming the PLC (PAC) don't have a lot of experience with GE controls and GE controls philosophy (which ISN'T documented anywhere--not even in GE) and operating GE turbines and auxiliaries.

[Under the GE turbine control system, the BASE LOAD selection button on the HMI will cause the Turbine Speed Reference to increase at a certain rate (percent speed reference per second or minute, usually--NOT MW/sec or MW/min) which will cause FSRN to increase at the same rate (if synchronized to a stable and well-regulated grid) which feeds into a minimum value selector function. The CPD/R-biased exhaust temperature control fuel stroke reference, FSRT, is continually being calculated and is also being fed into the same minimum value selector function, along with several other FSR values and the minimum value selector function chooses the lowest value of all the inputs to be FSR, which controls the total amount of fuel flowing to the machine (by controlling the position of the Gas Control Valves in a DLN-I equipped system). At some point the value of FSRN and FSRT will be equal to each other, and as TNR and FSRN continue to increase FSRT will become the lowest FSR input value to the minimum selector function. BUT--that's not the end of the control sequence. In order to prevent any "fighting" between the FSRN and FSRT as ambient conditions change TNR continues to increase until the value of FSRN reaches a preset differential from FSRT and then and only then does TNR stop ramping. You can (or could have) seen this on the Mark* V HMI because when FSRT is less than FSRN the RAISE SPEED/LOAD button is still orange/yellow indicating TNR and FSRN are still increasing. Again this is done to prevent any "fighting" between FSRN and FSRT because FSRN might have stopped immediately after exceeding FSRT. It's also the reason that when BASE LOAD is selected and active that the RAISE- and LOWER SPEED/LOAD buttons keeps toggling on the HMI display while operating in CPD/R-biased exhaust temperature control--AND why when the operator clicks on STOP that it takes almost a minute before the actual load on the machine starts decreasing and the LOWER SPEED/LOAD button indicates TNR/FSRN is being decreased. TNR/FSRN has to be decreased until it is less than FSRT to switch back to Droop Speed Control, and because TNR/FSRN was ramped up past FSRN by a present amount before the ramping stops; that differential has to be "undone" during unloading to get FSRN to be less than FSRT in order for the load to start decreasing--because of the FSR minimum select value function. A lot of words, I know, but this is what happens WHEN BASE LOAD IS SELECTED. If the operator just keep raising the Pre-Selected Load Control reference until the HMI indicates TEMPERATURE CONTROL. THAT WILL result in "fighting" between FSRN and FSRT, and the load will usually APPEAR to the untrained eye to drift, but it's just an improper operating method that's to blame. If it's desired for the machine to be operating on CPD/R-biased exhaust temperature, just click on BASE LOAD and let the Mark* do its thing. The load WILL NOT drift because there is no load reference--CPD/R-biased exhaust temperature control is supposed to put as much fuel is a safely possible into the machine at all times, basically the definition of Base Load. It's when operators use Pre-Select Load Control to operate the machine that "weird things" seem to happen, and it's entirely self-inflicted--not caused by the Mark* but by the operators. And it's this transition/changeover from Droop Speed Control to CPD/R-biased exhaust temperature control that can cause problems for people programming PLC (PAC) to use Droop Speed Control (a VERY misunderstood control scheme!) and CPD/R-biased exhaust temperature control. I have such control systems actually reach CPD/R-biased exhaust temperature control and then back down from that load (by reducing fuel) because of the way that the switch/change-over was programmed, sometimes by several percent of rated load! It's not an easy thing to program even for someone with a LOT of experience with PLCs (PACs) for many other, different industries/applications.]

The problem you are describing could very well be entirely unrelated to my experiences; I haven't see everything and don't know everything. But, this has happened and I have been involved with analyzing and troubleshooting the problem (but was not able to help resolve the problem for MANY reasons, most of them starting with LAW and ending with YERS), which put me in some very difficult situations I didn't always handle very well (in hindsight)). I might also suggest looking at the way the TTRF/TTRF1 calculation was implemented and executed; that's something that many control system integrators have had difficulty implementing because GE doesn't want to and hasn't documented what they consider to be proprietary control functionality for DLN systems. TTRF/TTRF1 should only be used as a combustion mode transfer switch, and as a kind of quasi-health indicator of actual turbine firing temperature--and nothing more than that. (I notice you didn't mention scrutiny of the TTRF/TTRF1 calculation--which runs at sequencing scan rate). The only things that don't run at sequencing scan rate are synchronizing functionality, servo-valve outputs (including LVDT functionality),j electronic overspeed(s), and, if I recall correctly on one version of the Mark* V the P2 pressure feedback scaling; those were all done at 128 ms.

The problem could even be the result of multiple issues, not just one. You should be open-minded about this. Including if mechanical work was done on the machines during the outage by non-GE service companies, and using non-GE parts, that could be at least contributing to the MW discrepancy.

And, yes, you will probably be able to write a book about this if you ever resolve the issue. But in the process you have learned a lot that will serve you well in your career. Please keep us informed if you discover something.

 

@RJSolo,

I want to add a couple of things. Using Pre-Selected Load Control to "maintain" stable load at Part Load operation or even at Base Load is highly NOT recommended--for the reasons explained. And that's on a GE Mark* turbine control system. It leads to a false sense of security, and if there is/are frequency disturbances on the grid the machine is synchronized to it will lead to exaggerated load oscillations AND contribute to grid frequency INSTABILITY instead of helping to stabilize the grid. Part of this is because many people (Plant Manager and Owners, Operations Supervisors, instrument technicians, operators and even many field service people don't understand what is supposed to happen during a frequency disturbance on a grid, have never thought about it or researched it in the least, and just have these (false) ideas that when the frequency of the grid the machine is synchronized to is unstable THEIR machine should be stable--and that's the opposite of what happens on an AC power grid, and what's supposed to happen during a frequency disturbance. Which is all for another later date on another thread--I'm just pointing out that operating a GE-design heavy duty gas turbine-generator using Pre-Selected Load Control for anything other than load changes is highly NOT recommended.

Next, it could be that your machine (or machines) is/are getting a load reference from a PMS (Power Management System( made up of another PLC (PAC). All well and good, BUT you didn't tell us that and we can't know unless you tell us. That may or may not be an issue--we simply don't know.

I have re-read your most recent post a couple of times (maybe more... ) and it does seem like whatever is happening may be the result of some programming issue(s) with the new turbine control system--it's certainly common to all four machines. But, again, we don't know a lot about how the machines are/were being operated at your site. It would be helpful to see a screenshot of the trend of one of the machines as it approaches Base Load--and to understand HOW the machine is being loaded (using Pre-Selected Load Control, or some external load command reference, or the BASE LOAD button on the HMI, ???). And what happens for a few minutes AFTER the machine reaches Base Load. AND--BERY IMPORTANTLY--how you know FOR CERTAIN the machine is operating on CPD/R-biased exhaust temperature control. That would mean knowing what TTRX is, that TTXM is, what the IGV angle is, etc.

And would/can you tell us if you've simulated exhaust temperatures using a calibrator which produces a millivolt signal to the turbine control system. So, for example, with the machine shut down, have you disconnected several exhaust T/Cs from the terminal board at the JB closest to the Load Compartment and connected the output of the calibrator to the terminal board for each disconnected T/C one at a time and set a temperature of, say, 1050 deg F, on the calibrator and recorded what was displayed on the HMI of the turbine control system? Are you CERTAIN the T/C wiring is correct at every terminal board, including at the T\C input terminals of the turbine control system? (There are DEFINITE T/C wiring practices which MUST be used for T/C wiring, especially if there is more than one termination point between the T/C and the control system input terminal board... They have been discussed MANY times on Control.com. I've seen multiple machines fail performance tests by 1/2 of 1% or rated power output simply because the exhaust T/C wiring was incorrect for several of the exhaust T/Cs--introducing an error into the TTXM measurement. The turbine control system expects (demands???) the T/C wiring--PARTICULARLY the exhaust T/C wiring for a GE-design heavy duty gas turbine--to be correct, and to always be correct after commissioning, including commissioning of a new turbine control system, GE-made or otherwise. They're pretty particular, actually (the control systems) without being able to dictate the wiring be checked and corrected, if necessary. Yeah; they're just two-wire devices, T/Cs, but those two wires are VERY important and they ways they must be terminated--especially if there are multiple terminal boards between the T/C and the control system!!!--are VERY IMPORTANT. And because the terminal boards in the junction boxes mounted on or near the Load Compartment get VERY HOT many of the terminal boards degrade or become unusable over time or get replaced--and the wiring doesn't always get reconnected properly using proper T/C wiring practices. GE typically uses a different style of terminal board at these Load Compartment junction boxes (67, 68, 69 and 79, if I recall their numbering correctly) and the way in which the wires on each side of the terminal board must be terminated can cause problems if not done correctly. (NO; it's NOT necessary to use Chromel/Alumel terminal boards for Type K terminal boards--but the way the wires are connected to the terminal board MUST be very precise and correct.)

SRV and Gas Control Valve LVDT calibrations are not very critical to turbine operation and/or power output--but can be critical during firing and acceleration. IGV LVDT calibration IS VERY CRITICAL to Base Load power output. And, when verifying/calibrating IGV LVDTs how is the actual IGV angle being determined--by the pointer on the axial compressor casing, or using some type of machinists' protractor on the actual IGV blades/vanes themselves? (If only the pointer on the axial compressor casing is being used, when was the last time it was calibrated.?.?.? or checked against the average of several angle measurements at various IGVs.?.?.?)

Out of curiosity, how are the LVDTs connected to the new turbine control system? Directly, or using some kind of volt-to-mA converter?

Okay. My curiosity is peaked, but there's only so much I can do over this medium/forum. I'm really just trying to suggest things to include in your search. But, I'm done for this morning, and probably this week.

Tchau!

 

I apologize for the delayed response. It has been a busy week around the plant.

I will not post any run data publicly, but I would be willing to send you a trend of a unit ramping to Base Load through a direct message. The data is pulled from PI at two samples per second, with the compression and exception deviations set to zero. Let me know if you would like to review it.

I realize I did not provide much background in my previous post. I was trying not to steer the discussion too far away from my original ITC question. However, since you asked, here is the longer version.

I am no stranger to Control.com, although I am generally a silent reader and rarely post. The amount of gas-turbine knowledge shared by contributors such as CSA has given me a tremendous amount of insight. As he frequently emphasized, a gas turbine operates according to what is programmed in its CSP. The general concepts and operating philosophy discussed here have helped me understand our site-specific logic much more thoroughly.

I have worked in the gas-turbine industry for more than 10 years, with the last six focused heavily on controls. I would consider myself well above average when it comes to reading and understanding turbine-control logic. Our site is also very much a “do-it-all” facility. I operate, repair, wire, troubleshoot, and work directly with the controls. That experience makes it easier to relate the control logic to the unit’s actual operation and mechanical behavior.

I have participated in hot-gas-path inspections, control-system upgrades, protective-relay and function testing, PFR testing, NDC testing, reactive-power testing, and many other turbine-related activities.

Regarding the transfer from Droop Speed Control to exhaust-temperature control, I have always found it interesting that this is often described as the most difficult portion of the conversion. In our CSP, the sequence is well defined. If someone understands GE turbine operation, it appears to be largely a matter of carefully reproducing the CSP.

I can understand the difficulty if someone has significant PLC experience but no gas-turbine experience. In that situation, much of the CSP would probably make very little sense. The information is generally present, but it takes considerable time to read, reread, and cross-reference multiple documents before everything begins to fit together.

Even calculations such as TTRF can be reconstructed by drawing out the blocks and developing the corresponding formulas. I may not fully understand how GE originally derived every equation, but I can reproduce the calculation and obtain the same output.

The only item I have not been able to officially locate is GE’s CPR LIMIT XYZ table. I was able to access and reconstruct the table from the Allen-Bradley system developed by the third-party integrator. Comparisons with historical Mark V data suggest that it is reasonably accurate.

Our site has four GE 7EA units commissioned in 2002 with GE Mark V TMR controls. The units are dual-fuel machines, although liquid fuel has never been operated. Our fuel nozzles require atomizing air continuously, and the liquid-fuel and water-wash purge valves are still required, so portions of the liquid-fuel logic remain in service.

Throughout the life of the site, the required maintenance has been completed at GE’s recommended intervals. Applicable TILs, firmware upgrades, and other updates have been implemented. The units operate in a very clean environment and were equipped with GE’s performance-monitoring package. Before the control-system replacement, they continued to perform with essentially no measurable degradation from their original output.

At our rated site conditions of 60°F, 50% relative humidity, and 14.35 psia, the units historically produced approximately 82–83 MW on natural gas. They also receive annual borescope inspections, and no significant internal damage has been reported. This is a very well-operated and well-maintained site.

The transfer from speed control to CPR-biased exhaust-temperature control appears to function as intended. We do operate using Pre-Selected Load Control. Unfortunately, that is the established operating practice, and changing it would be difficult. We also receive AGC commands from the grid operator.

However, I have tested loading the units using both the BASE LOAD selection and Pre-Selected Load Control. The final result is the same. Even when the Pre-Selected Load setpoint is placed well above the unit’s achievable output, the speed-control reference continues ramping and ultimately maintains approximately a 3% separation above the controlling temperature reference. The logic permits a separation of as much as 6%, although it never reaches that value under normal operation.

I also understand how significantly atmospheric conditions affect turbine output—not only temperature, but atmospheric pressure as well. Our 96AP instruments are calibrated to measure actual absolute pressure, not relative pressure.

Using GE’s Estimated Performance Curves and the curves selected when the units were built, I reconstructed a more usable performance-correction spreadsheet. The spreadsheet matched the historical Mark V performance extremely well. It has not matched the post-upgrade performance nearly as closely.

No mechanical work was performed on the turbines during the control-system outage. I also made certain that the existing field wiring was not altered unnecessarily. The intention was that if a commissioning problem occurred, it would remain isolated to the new control panel rather than introduce additional uncertainty in the field wiring.

When I say that I reviewed nearly all the formulas and logic used in the new system and compared them with the original CSP, I am not exaggerating. That does not mean I could not have missed something, but overall, the implementation appears solid. Most of the significant formulas from both systems were reconstructed in Excel and verified against actual operating data at comparable output.

I found several small discrepancies during the review. Those items were corrected, but none produced a change large enough to explain the complete output loss.

At Base Load, with the unit operating on exhaust-temperature control and the IGVs fully open at 84°, TTRX equals TTXM as expected.

At one point, I suspected that the issue might be associated with the gas-valve or IGV controllers. The Mark V used a high-select of LVDT1 and LVDT2, while the Woodward controller averages the two signals.

To the best of my knowledge, GE intentionally offset the two LVDT calibrations slightly. For example, if LVDT1 indicated 50.3% and LVDT2 indicated 49.7%, averaging the signals would produce 50.0%. However, if the Mark V selected the higher feedback, it would have used 50.3%.

The position difference is extremely small—again, perhaps another example of chasing static—but I questioned whether it could create subtle differences in actual fuel flow. The same question applies to IGV feedback.

I also reviewed a significant amount of data concerning IGV position. Moving from approximately 80° to 84° produces relatively little change compared with moving from 75° to 80°. Even if the indicated IGV position were incorrect by approximately one degree at the fully open end, I do not believe that alone would account for a 2 MW loss.

For the record, we physically measured the IGV angles as accurately as practical using a machinist’s protractor—not the pointer on the compressor casing. We also measured the gas-valve strokes using a dial indicator. Both were acceptable.

The IGV actuator incorporates mechanical stops, making overtravel or significant adjustment unlikely. The turnbuckle used to establish the lower IGV angle also has welded locking tabs and has never been adjusted.

The original AUTOCALIB files for all four units used an IGV range of 32° to 87°. The commissioning paperwork was less consistent: some units were documented at an 88° maximum, others at 87°, and the minimum was recorded as either 31° or 32°. Because AUTOCALIB specified 32° to 87°, I believe the Mark V scaled the LVDT feedback over that range regardless of the exact physical angle.

The LVDTs are connected directly to Woodward SPC Servo Position Controllers, model 8200-226. The controllers provide approximately 7 Vrms at 3,000 Hz for LVDT excitation. No voltage-to-current converters are used.

Regarding the exhaust thermocouples, I followed GE’s procedure by measuring the resistance of each thermocouple circuit and then reversing the meter leads. GE’s rejection criterion is a difference greater than 15 ohms. Most of our circuits showed a difference of approximately 2 ohms, with the lowest near 0.5 ohm and the highest near 3 ohms.

I have also injected temperature signals directly into the input modules using a temperature calibrator, and the readings were essentially exact.

During an operating run at steady load, I recorded the PLC readings from six exhaust thermocouples. I then disconnected those six thermocouples individually and immediately connected each one to the calibrator to compare the actual temperature with the PLC indication. The individual errors varied—approximately +1°F, –1°F, –0.5°F, +2°F, and so forth—but the positive and negative errors largely canceled one another in the calculated average.

Lastly, the field terminal boards are wired and terminated in accordance with GE’s thermocouple-wiring practices, and the conductors are landed correctly.

I am still stuck on the scan rate, I have yet to convince anyone to let me try to change the scan rates to 125 ms, from 32ms. I know mathematically the final outputs would come out the same but I have a feeling that in the real world, they woundnt. I also have suspicion that maybe MKV scaling in 16bit vs. 32bit has something to do with it. Who knows. All I know is something is different!

I appreciate the suggestions. I remain open to the possibility that the lost output is the combined result of several small discrepancies rather than a single major error. However, the fact that all four units developed the same performance difference immediately after receiving the same control-system conversion continues to point strongly toward something common within the new implementation.

 

@RJSolo,

As CSA said many times, the biggest benefit of this forum is that many people can benefit from the questions/problems of one person--so taking this discussion off-line is not something I would want to do, as much as I want to help.

You haven't said what the organization you are working for (I presume the owner/operator of the power plant) is doing to get the control system supplier/installer/commissioning team to do about the problem, and how engaged they have been to help find and resolve the problem. It really is THEIR problem, unless the contract wording is extremely unique.

As mentioned previously, the majority of control, protection and monitoring performed by the Mark* V is done at the 8, 16 or (usually) 32 Hz scan rate--this includes the signals sent to the various servo-valves as setpoint/references. The comparison of the reference to the feedback for the servo-operated devices, for example, a gas control valve positioning with its associated LVDTs, is done at 128 Hz, so the actual current applied to the servo coils may be adjusted as often as 4-8-16 times PER SCAN of the CSP. And the entire Mark* V is a very highly synchronized system (for a multi-controller system with several additional controllers (think about the DCC/SDCC cards with the I/O Master chip, the TCQC cards, and the TCEA cards--performing emergency electrical overspeeds, flame detection, and synchronization functions along with each of the three control processors). And all of this is very tightly synchronized. with the basic scan rate (8, 16 or 32 Hz) and the TCEA and TCQC cards (for the servo-valve outputs). For it's time when it was introduced it was very advanced (not the operator interface--and not the configuration processes--but the real time operating system and the synchronization of all of the controllers and I/O functions and control and protection.

I, personally, have a kind of heartburn about averaging the redundant LVDT feedback--unless there is some kind of "logic" that would use the remaining LVDT signal if one LVDT signal was completely lost. The predominant failure mode of an LVDT is to fail open--meaning the output signal will go to zero. That's why the Mark* systems use the high-selected value of two (or more) redundant LVDT signal, so that a loss of one LVDT signal will cause the machine to trip or experience a sudden load swing or air-flow disturbance.

I also know nothing about the Woodward SPC servo position controllers and am not in a position to download the manual and study it. I suspect it doesn't have the capability to do a high- or low- select on redundant signals, but only averages two or more inputs. And, how fast it does that is probably subject to some discussion. Knowing the input reference signal might change at a 16- or 32 Hz rate fast does the output signal from the SPC change after comparing it to the feedback signal? How integrated is the SPC with the A-B system with regard to the servo-valve outputs and feedback signals? I don't think running the A-B at 32 or 64 or 125 Hz is going to make much of a difference, because the reference outputs to the servo-operated devices will be a little smoother at the same steady state conditions, but to my way of thinking, it's all about how the SPC adjusts the actual servo currents being applied to the servo-valve coils.

Again, I don't know how the system is configured with the A-B and the Woodward stuff, but this is one of the problems with using a "generic" PLC ALONG WITH various converters and "adapters" to control a piece of high-speed rotating equipment. The Mark* turbine control system is a purpose-built turbine control system with I/O capable of all working seamlessly together to control and protect (and monitor) seriously large (and sometimes small) pieces of high-speed rotating equipment and their auxiliaries.

My personal experience with dual redundant LVDTs with Mark* V turbine control systems is that it causes minor, intermittent issues when the zero-stroke voltages are set exactly equal to each for each of a redundant pair of LVDTs which causes the two feedback values to be very close to each other. My theory is that when choosing the higher of the two LVDT feedbacks sometimes the Mark* V gets a little confused if the two calibrated feedback values are very nearly equal to each other. Just setting the zero stroke voltages 0.01 VDC different from each other seems to make that problem disappear (at least in my experience). I doubt very seriously this is an issue for the SPC, but, again I have zero experience with that piece of Woodward kit.

Do you have any historical data from the Mark* V regarding things like TTRX, TTRF/TTRF1, TTXM, CTIM, CTDA, AFPAP, exhaust duct back pressure--at various ambient conditions while operating at Base Load--to compare to the new control system? That you would be willing to share on this public forum, where you've asked for assistance, by the way.

So, that's all I can add based on the information provided. Very interested to hear the resolution, and to know how the provider is helping to get to the root cause of the problem.

 

See attached for some run data. The GE Data was grabbed from the ToolboxST Trender. It was LIVE as is data. You will see some NOX differences between GE and NEW. FSRXSR went from 82% to 82.75%.