We are not sure how this initially happened, but somehow some constants for water control were changed in the <R> core. This caused a misoperation of the unit when we tried to quickly ramp down its MW output (controller kept applying full water at all times and not regulating as it should for emission control, we had to trip the unit offline to remain compliant).
We identified the changed constants, and attempted to perform a reboot so that it pulls the configuration from the EEPROM, and this did not work. We had to manually change the values in <R>. The EEPROM appears to have the correct information, so the problem is that this information is not successfully getting to <R>. Any ideas where we can look to help identify our problem?
PS: I may have spoken out of terms on some items. I am not an I&E guy, I am in transmission planning and am helping our generation folks try to get to the bottom of this. I was not onsite during troubleshooting, so I am speaking from second-hand information that was relayed to me from the plant.
Control Constants for <R> exist in four (4) places:
CONST_Q.DAT (or, CONST_Q.AP1)
When the Mark V is controlling and protecting a turbine it uses the RAM values. RAM is volatile memory, and whenever <R> is re-booted or powered up the RAM is empty. So, during the boot process it goes to EEPROM to get the values it needs, loads them into RAM, and doesn'€™t "look"€ť at EEPROM again until it is powered up or re-started.
When someone changes a Control Constant using the Control Constant Adjust Display, that person is changing the RAM value. Depending on the type of operator interface the RAM value can be modified from the Control Constant Adjust Display. So, if someone changed a Control Constant using the Control Constant Adjust Display AND performed a procedure to write the RAM values to EEPROM that would explain why it doesn't seem like the correct information is getting to RAM.
The values in CONST_Q.SRC (an ASCII text file in the unit-specific directory on the operator interface) are the "€śstarting point"€ť for the values in EEPROM. Those values are compiled using the Table Compiler (one of the programs executed when the batch file MKVMAKE.BAT (also known as the Total Job Compiler) into either CONST_Q.DAT (if the operator interface is an <I>) or CONST_Q.AP1 (if the operator interface is a GE Mark V HMI). The compiled Control Constant file is then downloaded to EEPROM using the EEPROM Downloader.
My recommendation is to check CONST_Q.S RC to see what the values of the suspect Control Constants are, change them if necessary, and if you made changes save the file when exiting the editor.
Then, whether you made changes or not, go to the command line in the unit-specific directory (usually F:\UNIT1), and run the following command:
EEPROM DOWN T1 R CONST
Then re-boot <R> and use the Control Constant Adjust Display to check the RAM values of the suspect Control Constants. You should find all is good.
Please write back to let us know how you fare! Please write down every step you perform, and the results if there are errors!!! So that we can help if necessary.
Hope this helps!
Thank you for your detailed response. We will have a call with the plant to discuss some of these action items that can help us try to resolve this issue. It is a bit difficult for me because I am remote from the plant site, but this information is very valuable in helping us troubleshoot the issue.
What is very strange to us is that there is no record of these control constants being changed from the operator interface. As far as I understand, every change that is made by the operator is logged. So, we have no idea how the constants changed to begin with. There was a power outage at the plant recently, but our DC system kept the Mark V running. Some have suggested that some type of surge may have caused the initial change.
As of now, we manually corrected these constants in <R> and the plant has been operating just fine. But, as soon as we reboot <R>, it goes to EEPROM and reloads the incorrect constants. I am not quite sure how they verified this, but plant personnel tells us that they are certain that the values are correct in EEPROM. For some reason when it gets to <R> these values are different. In addition, only these specific constants are changing (they all begin with W).
We will have the plant go through the exercise that you suggested, and hopefully this will correct our issue. Thanks again for your help.
If the unit has one of the "newer" GE Mark V HMIs (which run some version of MS-Windows and CIMPLICITY or PROFICY Machine Edition) I believe (though I can't recall the name of the executable) there is an executable that can be used to look at the values of Control Constants in EEPROM and in RAM. I think it was called something like CONSTCHK.EXE, and it can be run from a command prompt window. Sometimes I think the unit number has to be supplied (T1, for example--and it might be different at the site! the unit number is defined in another ASCII text file, CONFIG.DAT, if I recall correctly).
It might even be possible in newer versions of the Control Constants Adjust Display to look at the values of various Control Constants in EEPROM as well as RAM. It would be very interesting to know how the plant personnel are so certain the EEPROM values are correct....
GE does have a very poor habit of overwriting Control Constant values in the CSP (Control Sequence Program). To know if that is happening it would be necessary to get the unit-specific configuration files to analyze. Not sure this is happening, but it does cause a LOT of confusion as it is an extremely poor programming practice.
I have never seen a Control Constant value get changed "by magic" (that would be like a virgin giving birth)--not even by a surge. That just doesn't make any sense at all.
It is also possible that some of the sequencing has been shifted to <C> by the factory to try to reduce the load on the <R> processor, and that the water injection sequencing was part of that. <C> has EEPROM and RAM just like <R>. I have only worked on a couple of Mark V SIMPLEX panels, and I do recall that some sequencing was moved to <C>.
Lastly, some information about water injection (for emissions control). If the rate of water injection was held constant during unloading or the rate was higher than normal during normal operation the emissions will be lower than normal--and if the fuel is reduced further during unloading while the water injection rate was not being reduced the water will eventually extinguish the flame. Same can happen (the water will extinguish the flame) if the rate of water injection gets too high under normal operation. Usually, before the flame gets extinguished the unit will begin to "rumble" much more than normal. That's caused by high combustion dynamics in the combustion can, and also flame "flickering" as it is being extinguished. Neither (high combustion dynamics or flame flickering) is very good for the unit, and sometimes the bearing vibration sensors will also register a higher-than-normal reading when water is being over-injected. But, over-injection will usually cause lower-than-normal NOx, though with some CEMS monitors it can take 5-15 minutes to see a change in reading. I know this isn't your thing, but I just wanted to be clear about what the effects of over-injection are (lower-than-normal emissions (not higher), and high combustion dynamics, flame flickering and even loss of flame due to water extinguishing the flame).
Anyway, thank you for the information. It would be great to know what the site personnel find when they check CONST_Q.SRC, and if they don't find the Control Constants they are looking for in that file they might be in CONST_B.SRC, which is the Control Constant definition file for <C>. Again, please have the site personnel write down every step they take and command they enter, and the results of any command. Read the result of any command carefully, because just running the command doesn't always guarantee perfect results.
It would also be helpful to know how they are so certain the EEPROM values are correct....
Best of luck!