Hello friends in CONTROL,

We've a PG9171 gas turbine on-site using the Mark V control system. Now, our Mark V system has been showing a Voter mismatch, <R> FPRG_INT alarm.

After this alarm, we did some checks on-site:

1. Checked 3 FPG2 pressure signals: 18.12 bar, 18.24 bar, 18.35 bar, which are quite balanced.
2. (FPRGOUT=18.14bar).
3. Looked into 2 LVDT signals: 1.74Vrms, 1.77 Vrms, which are pretty similar.
4. Examined SRV feedback FSGR: 45.75%, 45.17%, 45.20%, quite balanced.
5. Checked FPRG_INT: 58.66%, 38.43%, 37.17%.
6. Servo currents FAGR for controllers R, S, T: -42.20%, 15.76%, 20.33%, not balanced.
7. No other diagnostic alarms found on L3GSSRV1 module.

Even though the pressure and SRV feedback didn't show significant differences, the servo current for controller R is way higher than for controllers S and T. This might be because of a faulty coil in the three-coil servo valve of the SRV related to controller R, or it could be an issue with the servo output from controller R itself.

I'm quite new to working with the Mark V system and unsure if my analysis of the fault is correct. I'd really appreciate your help in analyzing this issue. If it's a problem with the servo valve, a direct replacement should fix it. However, if it's a controller issue, which part of the control board needs replacement, and would we need to do a LOAD after replacement?

I hope to get your assistance. Thank you so much!

 

Greetings,

Your analysis seems quite good. I'm presuming the Mark* V is a Mark* V--and NOT a Mark* V Life Extension cob-job. There have been many questions about FPRG_INT voting mismatches on Control.com over the years, and the most common cause is a difference in the P2 pressure inputs from three, redundant transducers. (If you haven't already, you can use the Search feature of Control.com to find them.) Some machines only have a single P2 pressure transducer; others have three (96FG-2A, 96FG-2B & 96FG-2C). Some machines use (or used) Gulton-Statham or AMETEK pressure transducers, and these were, unfortunately, subject to drift--much more so that just about any other brand of pressure transducer (transmitter).

But, from your data it seems the three P2 pressure transmitter inputs are pretty close and one of them has not drifted apart.

Have you used the Pre-Vote Data Display to look at the values of P2 pressure (FPG2, usually) and FPRG_INT? Can you tell us what they are when the machine is running on gas fuel (any load is fine)?

If the three input values are all closely matched at the I/O terminal board, then it's possible there's a problem with the I/O terminal board, or the terminations, or the hardware ("Berg jumpers") on the I/O terminal board. Was the I/O terminal board replaced recently? (It would be on <R>, probably the TBQA or TBQC??? Sorry; I don't have any manuals to look at at this time.)

Mark* V turbine control panels were known to have problems with corrosion of the pins and sockets of ribbon cables. It's strongly recommended to periodically (about every two years or so) put new grease on all of the ribbon cable ends. Conductive grease can usually be found in the boxes of spare cards purchased from reputable provider. TOO MUCH GREASE IS ALMOST AS BAD AS NO GREASE! Prior to putting grease on the cable ends, it's recommended to carefully removed the cable from the card socket and then reinsert the cable end into the socket and then remove it and reinsert it again--at least a couple of time. When you remove the cable end from the socket for the first time, be sure to check for any "extra" grease and wipe it off.

Then wipe a small amount of grease from the tube across the face of the cable end connector--remembering that too much grease is just as bad as no grease. And then insert the cable end back into the socket and remove it and reinsert again--a couple of times--before making sure the cable end is firmly inserted into the socket.

It's recommended to do this with the processor powered down (I prefer to do it with the entire Mark* V powered down, but I know that gives some people the heebie-jeebies and if it's not powered-down properly, and then not powered back up properly there can be some issues--never unrecoverable, but time consuming and aggravating nonetheless.

If I recall correctly the P2 pressure transducer signals went to the TCQA cards in <R>, <S> & <T>. If that's the case, then if you replace the TCQA card you WILL NOT need to do any downloading and rebooting. And, if you replace a TCQA card PLEASE apply conductive grease after wiping off any excess from the ribbon cable ends as you install the new card. The TCQA will get it's I/O configuration parameters from the EEPROM chip on the DCC/SDCC card, so as long as you don't replace that card (with its EEPROM chip) no EEPROM Downloading/rebooting is required. BUT, I may be wrong about where the P2 pressure transducer signals end up in the control processors; use the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195, to be sure (in other words, verify what I'm telling you--it's been a long time since I've worked on a Mark* V).

Replacing the electro-hydraulic servo valve is fairly simple. And there is NO calibration required (because the only thing that gets calibrated is LVDT feedback--and you're not changing LVDTs or adjusting them, you're only replacing the servo and THAT IS NOT AFFECTED by AutoCalibrate. Contrary to (false) popular belief. You WILL need to perform a servo-valve polarity check (that has been documented MANY times on Control.com). DO NOT use the servo polarity check that's described in the Control Specification document--it's BS and DOES NOT test the servo currents individually! (Jerky operation can be caused by MANY things.) It's easy but VERY necessary as even brand new servo's from the manufacturer have been found to have incorrect color coding of the coil wiring--so even if you put red to red and blue to blue, etc., there's a chance one of the coil leadsets is backwards. And, unless YOU performed the servo polarity check on the servo being removed there's NO guarantee that it was done correctly by the person installing that servo.

Hope all goes well for you. If you need more clarification, write back to let us know and someone will get back to you.

 

Greetings,

Your analysis seems quite good. I'm presuming the Mark* V is a Mark* V--and NOT a Mark* V Life Extension cob-job. There have been many questions about FPRG_INT voting mismatches on Control.com over the years, and the most common cause is a difference in the P2 pressure inputs from three, redundant transducers. (If you haven't already, you can use the Search feature of Control.com to find them.) Some machines only have a single P2 pressure transducer; others have three (96FG-2A, 96FG-2B & 96FG-2C). Some machines use (or used) Gulton-Statham or AMETEK pressure transducers, and these were, unfortunately, subject to drift--much more so that just about any other brand of pressure transducer (transmitter).

But, from your data it seems the three P2 pressure transmitter inputs are pretty close and one of them has not drifted apart.

Have you used the Pre-Vote Data Display to look at the values of P2 pressure (FPG2, usually) and FPRG_INT? Can you tell us what they are when the machine is running on gas fuel (any load is fine)?

If the three input values are all closely matched at the I/O terminal board, then it's possible there's a problem with the I/O terminal board, or the terminations, or the hardware ("Berg jumpers") on the I/O terminal board. Was the I/O terminal board replaced recently? (It would be on <R>, probably the TBQA or TBQC??? Sorry; I don't have any manuals to look at at this time.)

Mark* V turbine control panels were known to have problems with corrosion of the pins and sockets of ribbon cables. It's strongly recommended to periodically (about every two years or so) put new grease on all of the ribbon cable ends. Conductive grease can usually be found in the boxes of spare cards purchased from reputable provider. TOO MUCH GREASE IS ALMOST AS BAD AS NO GREASE! Prior to putting grease on the cable ends, it's recommended to carefully removed the cable from the card socket and then reinsert the cable end into the socket and then remove it and reinsert it again--at least a couple of time. When you remove the cable end from the socket for the first time, be sure to check for any "extra" grease and wipe it off.

Then wipe a small amount of grease from the tube across the face of the cable end connector--remembering that too much grease is just as bad as no grease. And then insert the cable end back into the socket and remove it and reinsert again--a couple of times--before making sure the cable end is firmly inserted into the socket.

It's recommended to do this with the processor powered down (I prefer to do it with the entire Mark* V powered down, but I know that gives some people the heebie-jeebies and if it's not powered-down properly, and then not powered back up properly there can be some issues--never unrecoverable, but time consuming and aggravating nonetheless.

If I recall correctly the P2 pressure transducer signals went to the TCQA cards in <R>, <S> & <T>. If that's the case, then if you replace the TCQA card you WILL NOT need to do any downloading and rebooting. And, if you replace a TCQA card PLEASE apply conductive grease after wiping off any excess from the ribbon cable ends as you install the new card. The TCQA will get it's I/O configuration parameters from the EEPROM chip on the DCC/SDCC card, so as long as you don't replace that card (with its EEPROM chip) no EEPROM Downloading/rebooting is required. BUT, I may be wrong about where the P2 pressure transducer signals end up in the control processors; use the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195, to be sure (in other words, verify what I'm telling you--it's been a long time since I've worked on a Mark* V).

Replacing the electro-hydraulic servo valve is fairly simple. And there is NO calibration required (because the only thing that gets calibrated is LVDT feedback--and you're not changing LVDTs or adjusting them, you're only replacing the servo and THAT IS NOT AFFECTED by AutoCalibrate. Contrary to (false) popular belief. You WILL need to perform a servo-valve polarity check (that has been documented MANY times on Control.com). DO NOT use the servo polarity check that's described in the Control Specification document--it's BS and DOES NOT test the servo currents individually! (Jerky operation can be caused by MANY things.) It's easy but VERY necessary as even brand new servo's from the manufacturer have been found to have incorrect color coding of the coil wiring--so even if you put red to red and blue to blue, etc., there's a chance one of the coil leadsets is backwards. And, unless YOU performed the servo polarity check on the servo being removed there's NO guarantee that it was done correctly by the person installing that servo.

Hope all goes well for you. If you need more clarification, write back to let us know and someone will get back to you.

 

Greetings,

Your analysis seems quite good. I'm presuming the Mark* V is a Mark* V--and NOT a Mark* V Life Extension cob-job. There have been many questions about FPRG_INT voting mismatches on Control.com over the years, and the most common cause is a difference in the P2 pressure inputs from three, redundant transducers. (If you haven't already, you can use the Search feature of Control.com to find them.) Some machines only have a single P2 pressure transducer; others have three (96FG-2A, 96FG-2B & 96FG-2C). Some machines use (or used) Gulton-Statham or AMETEK pressure transducers, and these were, unfortunately, subject to drift--much more so that just about any other brand of pressure transducer (transmitter).

But, from your data it seems the three P2 pressure transmitter inputs are pretty close and one of them has not drifted apart.

Have you used the Pre-Vote Data Display to look at the values of P2 pressure (FPG2, usually) and FPRG_INT? Can you tell us what they are when the machine is running on gas fuel (any load is fine)?

If the three input values are all closely matched at the I/O terminal board, then it's possible there's a problem with the I/O terminal board, or the terminations, or the hardware ("Berg jumpers") on the I/O terminal board. Was the I/O terminal board replaced recently? (It would be on <R>, probably the TBQA or TBQC??? Sorry; I don't have any manuals to look at at this time.)

Mark* V turbine control panels were known to have problems with corrosion of the pins and sockets of ribbon cables. It's strongly recommended to periodically (about every two years or so) put new grease on all of the ribbon cable ends. Conductive grease can usually be found in the boxes of spare cards purchased from reputable provider. TOO MUCH GREASE IS ALMOST AS BAD AS NO GREASE! Prior to putting grease on the cable ends, it's recommended to carefully removed the cable from the card socket and then reinsert the cable end into the socket and then remove it and reinsert it again--at least a couple of time. When you remove the cable end from the socket for the first time, be sure to check for any "extra" grease and wipe it off.

Then wipe a small amount of grease from the tube across the face of the cable end connector--remembering that too much grease is just as bad as no grease. And then insert the cable end back into the socket and remove it and reinsert again--a couple of times--before making sure the cable end is firmly inserted into the socket.

It's recommended to do this with the processor powered down (I prefer to do it with the entire Mark* V powered down, but I know that gives some people the heebie-jeebies and if it's not powered-down properly, and then not powered back up properly there can be some issues--never unrecoverable, but time consuming and aggravating nonetheless.

If I recall correctly the P2 pressure transducer signals went to the TCQA cards in <R>, <S> & <T>. If that's the case, then if you replace the TCQA card you WILL NOT need to do any downloading and rebooting. And, if you replace a TCQA card PLEASE apply conductive grease after wiping off any excess from the ribbon cable ends as you install the new card. The TCQA will get it's I/O configuration parameters from the EEPROM chip on the DCC/SDCC card, so as long as you don't replace that card (with its EEPROM chip) no EEPROM Downloading/rebooting is required. BUT, I may be wrong about where the P2 pressure transducer signals end up in the control processors; use the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195, to be sure (in other words, verify what I'm telling you--it's been a long time since I've worked on a Mark* V).

Replacing the electro-hydraulic servo valve is fairly simple. And there is NO calibration required (because the only thing that gets calibrated is LVDT feedback--and you're not changing LVDTs or adjusting them, you're only replacing the servo and THAT IS NOT AFFECTED by AutoCalibrate. Contrary to (false) popular belief. You WILL need to perform a servo-valve polarity check (that has been documented MANY times on Control.com). DO NOT use the servo polarity check that's described in the Control Specification document--it's BS and DOES NOT test the servo currents individually! (Jerky operation can be caused by MANY things.) It's easy but VERY necessary as even brand new servo's from the manufacturer have been found to have incorrect color coding of the coil wiring--so even if you put red to red and blue to blue, etc., there's a chance one of the coil leadsets is backwards. And, unless YOU performed the servo polarity check on the servo being removed there's NO guarantee that it was done correctly by the person installing that servo.

Hope all goes well for you. If you need more clarification, write back to let us know and someone will get back to you.

Thank you very much for your reply.

FPG2: 18.12 bar, 18.24 bar, 18.35 bar
FPRG_INT: 58.66%, 38.43%, 37.17%
FSGR: 45.75%, 45.17%, 45.20%
FAGR: -42.20%, 15.76%, 20.33%

These figures are all from the Pre-Vote Display page, with the gas turbine consistently using natural gas as its fuel. There have been no spare part replacements or upgrades to the SRV or Mark V control system on-site in the past year.
These readings were taken when the site load was 106MW, and FSR was 65.8. However, at a load of 50MW and FSR of 36.7, the data significantly differed:

FPG2: 17.98 bar, 18.34 bar, 18.65 bar (minor deviations from P2 pressure reference value FPRGOUT=18.23 bar).
FSGR: 31.23%, 31.66%, 31.51% (relatively balanced).
FPRG_INT: 32.28%, 31.27%, 30.14% (minor deviations).
FAGR: -5.38%, -1.83%, 0.62% (imbalanced servo currents, closer to normal values compared to 106MW load, with small deviations).

At lower loads, it seems that FPRG_INT and FAGR pre-vote data deviations are smaller. As per my understanding, the three P2 pressures are compared individually with the P2 pressure set value FPRGOUT. Then, after PI calculations, three FPRG_INT values are generated, acting as commands for the SRV's opening. These values are then used in calculations with the SRV's opening feedback, eventually producing three servo commands (FAGR) for the three coil valves. Is my understanding correct? If it is, I'm puzzled as to why at 106MW with balanced P2 pressures and identical set values, there's significant deviation among the three FPRG_INT values in the pre-vote table. Meanwhile, at 50MW, although there's some deviation in the actual P2 pressures (though minor), the FPRG_INT deviations are very small.
Additionally, I believe there's a close link between FPRG_INT and FAGR. Assuming my previous understanding is accurate, deviations in the three FPRG_INT values cause deviations in the three servo currents (FAGR). The root of the problem seems to be why, in the pre-vote table, the three P2 pressures show nearly identical values, but the three FPRG_INT values exhibit significant deviations. Could this be attributed to abnormal PI control by the R controller (though seemingly normal at 50MW load)?

 

I believe you're also correct about the correlation between FPRG_INT and FAGR. And, a difference of 0.3-0.4 barg is not insignificant, and can cause the problem you are seeing. It was always my understanding that FPRG_INT's purpose was to try to eliminate any difference between FPG2 values as P2 pressure is a critical parameter for proper fuel control (hence the three redundant transducers AND the fact that FPRG IS NOT a voted value, and FPRG_OUT is also not voted by the Mark* V (it's voted at the servo valve through the servo currents). This is one of the exceptions to the TMR rule, but an important one. Each control processor does it own thing and the voting occurs at the SRV servo.

BUT, I have also seen some sites with non-standard servo regulator current gains (don't ask me how it happens, because the proper current gains are ALWAYS specified in the Control Specification document that is specific to every machine) but people like to tweak things and rarely tweak them back when they don't work. And, there were a good number of Mark* V turbine control panels who were commissioned by people who had little training, no experience and no mentor or commissioning procedure to tell them to make sure the values in the software provided to the site had the correct Control Constant values AND I/O Configuration Constant values before starting the machine.

How old is the particular machine? Do you know if the SRV has ever been refurbished or replaced? It's a pretty simple thing to perform a servo current polarity check (with proper preparation and a proper procedure). That could also be contributing to the problem you are describing.

 

I believe you're also correct about the correlation between FPRG_INT and FAGR. And, a difference of 0.3-0.4 barg is not insignificant, and can cause the problem you are seeing. It was always my understanding that FPRG_INT's purpose was to try to eliminate any difference between FPG2 values as P2 pressure is a critical parameter for proper fuel control (hence the three redundant transducers AND the fact that FPRG IS NOT a voted value, and FPRG_OUT is also not voted by the Mark* V (it's voted at the servo valve through the servo currents). This is one of the exceptions to the TMR rule, but an important one. Each control processor does it own thing and the voting occurs at the SRV servo.

BUT, I have also seen some sites with non-standard servo regulator current gains (don't ask me how it happens, because the proper current gains are ALWAYS specified in the Control Specification document that is specific to every machine) but people like to tweak things and rarely tweak them back when they don't work. And, there were a good number of Mark* V turbine control panels who were commissioned by people who had little training, no experience and no mentor or commissioning procedure to tell them to make sure the values in the software provided to the site had the correct Control Constant values AND I/O Configuration Constant values before starting the machine.

How old is the particular machine? Do you know if the SRV has ever been refurbished or replaced? It's a pretty simple thing to perform a servo current polarity check (with proper preparation and a proper procedure). That could also be contributing to the problem you are describing.

This gas turbine has been in operation for more than 15 years, and the SRV has not been replaced or refurbished in the past three years.

 

DGY,
Being new to the Mk V, there are high speed data collection tools that you may be unaware of. The VIEW tools can capture data at a rate of up to 32 points per second. I recently had a 7FA getting thrown out of load control due to a single bad P2 Ametek transmitter and the only indication was an FPRG_INT voter mismatch. I put the relevant signals in a VIEW2 and caught the P2 transmitter associated with <T> core going from the normal 400psi when running up to 460, down to 150 and anywhere in between within a fraction of a second. It was happening so fast the HMI didn't detect he change other than the voter mismatch diag alarm and the PI historian couldn't detect the change at 1 data point per second. Look in the Mk V maintenance and application manuals for how to set up VIEW/VIEW2/VIEW2T tools and try to capture the high speed data. They are command line tools so getting set up properly is a bit of a pain, but once you understand them they can be a life saver.

 

@White's reply is why I asked what the data collection rate was, because ANYTHING over MODBUS (especially serial MODBUS, but even MODBUS TCP can be "slow") when trying to troubleshoot high-speed or potential high-speed issues. The VIEW tools (as they are called) are a collection of command line executables (so they have to be run from a DOS prompt command line) which can, as @White says, collect data at up to 32 times per second. Several of the VIEW tools can be configured to collect data from a specific processor, if I recall correctly (say <R> in this case).

Open a DOS prompt (if the operator interface is a GE Mark* V HMI running some version of MS-Windows) and change to the F:\USER directory (which is a folder/directory which was created primarily for gathering data files). Then type DIR G:\EXEC\VIEW*.EXE and press ENTER to get a list of all of the VIEW executables. (I suggest making a screen capture or a photo of the display or writing the names down for future reference.) The pick one (VIEW2.EXE is the most commonly used data gathering executable) and just type the file name followed by one of the Help/Information switches/options, VIEW2 /? or VIEW2 /HELP, and press ENTER. Often, there is more than one display of information and you can scroll "down" by pressing the space bar several times. Again, I suggest screen captures or photos of the individual Help/Information screens to have the configuration information to use to run the executable. The best thing to do is to create a blank text file and put the CDB (Control Signal Database) signal names you want to capture in the file (one signal name per line, up to a maximum of 29 or 32 total, if I recall correctly) and save the file with a filename and extension you write down (such as TESTFPRG.LST (the .DAT for "list" file). Then create another blank text file with a filename such TESTFPRG.DAT (for "data" file) and close and save the empty file. Do this in the F:|USER directory/folder. Then pass the "list" file to the executable as the list of points for which data is to be collected, and pass the "data" file to the executable as the name of the file where the data collected will be stored. There will be several other options and "switches" you have to use on the command line. DOING THIS WILL NOT TRIP THE TURBINE WHILE IT IS RUNNING!!! I would make a few tests, and look at the results in the "data" file to see if you're getting the data you want.

The data will be in ASCII text format and you will have some "fun" scrolling around and through the file (use MS-Windows Notepad). I believe Notepad will also export the data in the file to a .CSV file (comma-separated value file) which can then be imported into MS-Excel and plotted or otherwise analyzed. (I'm NOT a spreadsheet fan, but sometimes it's useful. Some people are HUGE spreadsheet fans; I've even heard of people (one was a former colleague) who couldn't use MS-Word to write a simple report, but he was a WHIZ at using MS-Excel to write reports and format them and do all sorts of fancy crap. Just a LITTLE BIT over the top.)

Anyway, there's a VERY good chance you are missing a LOT of data using the DCS to graph the goings on.

A little about the Mark* V and servo regulators (used to drive the mA outputs to servo valves). In this case the CDB signal name for the SRV servo current would probably be FAGR. And the way the TCQA card works is it gets a P2 pressure reference from the CSP (Control Sequence Program) every eighth of a second and then adjusts the servo current out to the SRV 16 times to try to make the actual P2 pressure equal to the P2 pressure reference before it receives another P2 pressure reference (even if the P2 pressure reference hasn't changed since the last time). So, this means the TCQA adjusts the SRV servo output current 128 times per second to make the actual P2 pressure equal to the P2 pressure reference. And this happens for EACH of the three control processors, and they are all three doing this at the same time 128 times per second. (Pretty cool, huh?)

Now--before you go off thinking, "GREAT! I can add FAGR to the list of data points and see the current changing 32 times per second (because that's the fastest rate at which the VIEW tools can collect data)!" WRONG! That data won't even be captured at 32 times per second, because the value of FAGR is only written to the CDB (Control Signal Database) at the rate of 8 times per second. So, even if you're collecting data at 32 Hz, you will only see FAGR change 4 times in that period. Sorry; that's the best they could back then. BUT, it's not really FAGR you're interested in--it's FPG2 (per @White's post), and you WILL see that change as fast as 32 times per second.

Anyway, again, using data obtained via MODBUS for high-speed troubleshooting isn't worth the effort--and a LOT of what happens in the Mark* V happens a LOT faster than once per second. Even if the HMI is getting data faster if it's only going to the DCS at a 1 Hz rate (once per second) it's NOT reflective of the actual conditions and the values will likely appear to be really squirrely or not changing very fast at all (if the range of variance is relatively small).

I've have been screamed at by plant managers and owners because they refuse to use the VIEW tools and they INSIST that something be done to force the Mark* V to send data to the DCS which can graph it for them for troubleshooting. And when told that isn't possible (several times) they just fall back to the widely popular (and false!) belief that the Mark* V is a piece of shite.

Anyway, if you're going to be working on Mark* V(s) you should learn to use the VIEW tools. Because that's the ONLY way (unless you buy a third-party HMI, such as IBECS) which can get the data "natively" and plot it straight away. Anything else using a GE <I> or GE Mark* V HMI is somewhat limited--but it can still be used to troubleshoot effectively and quickly.

I think there is something in the Mark* V Maintenance Manual, GEH-5980, about the VIEW tools which may be useful if you've never used them before.

Go forth and conquer!

And thanks, @White.