Today is...
Saturday, August 24, 2019
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A tutorial introduction to programming using the QuickBuilder Programming Environment.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
GE 6FA Machine Trips Frequently Due to Sensor Failure
GE 6FA MarkVIe control System machine tripped frequently due to "L30CPBH1_0" sensor failure.

GE 6FA machine tripped frequently due to "L30CPBH1_0" sensor failure. We have two machines. Previously we found water deposit in the junction box of a_96bh1 and a_96bh2 (upstream and downstream of IBH valve ). Now both sensors are okay and giving correct output.

But still GT tripped due to Sensor fault. Can anybody tell me from where LCPBH1_0_F signal generated?

If anyone could give some information that would be great help.
Thanks

Regards
Shahiideee

0 out of 1 members thought this post was helpful...

LCPBH1_0_F should originate from a FDIA block. Refer to GEH-6810 for some information on the logic. The latest version I have seen is rev B. In some systems you can drill down into the FDIA block and study how it works if you have time and patience. But, I believe that in many systems GE has password protected the block and access to the internals of the block is not possible - you are left to relying on the GEH for any understanding of how it works. IMO, such password protection should never be accepted by the owner - it can make troubleshooting very difficult.

1 out of 1 members thought this post was helpful...

This bit of application code is associated with what GE alternately calls "MBC" (Model-Based Control), or ARES, or ETS (I forget what the last acronyms stand for). And all of that is considered PROPRIETARY information, and trade secrets, and Intellectual Property. Which means,"You don't need to know that, and we don't have to tell you, and you paid a lot of money for it, and you just have to take it on faith that it works."

If you found "water in the junction box" then it's pretty certain that something is still not right with:

1) the junction box terminal boards (there may be corrosion which is causing intermittent grounds/earths),

or

2) the transmitter(s) (if you have a spare transmitter you can try replacing one of them to see if that stops the tripping, but may not stop an associated alarm, in which case you might need to replace both transmitters),

or

3) the wiring into/out of the junction box (moisture may have gotten into the insulation/shielding),

or

4) the Mark VIe input card(s) (which may have been damaged by the ground/short caused by the water).

It's likely the two transmitters are each connected to separate mA input terminal boards (for additional redundancy), so you might try replacing one of the TBs to see if that helps with the problem (eliminates the tripping). If you replaced one of the transmitters but that didn't stop the tripping, you might try replacing the mA input terminal board the new transmitter is connected to. Just be sure to write down each step you take, and what the results were. That's a VERY important part of troubleshooting a difficult problem.

There's not too much else it can be. The Mark VIe application code isn't going to have failed because of the water in the junction box, so it should be a logical process of elimination.

Most of that application code uses a LOT of sensors, and redundant sensors, to check on operation and "performance" versus a standard model. Usually, redundant sensors will alarm when there is a problem with a single sensor, but will trip if both sensors are deemed to have failed--depriving the model of feedback to protect the turbine.

I'm not all that familiar with this MBC stuff (which appears to be evolving over time as GE "improves" the code). But, I think you can try "re-initializing" the algorithms from the associated display. I RECOMMEND YOU READ THE APPLICABLE GE DOCUMENTATION BEFORE ATTEMPTING THIS, AND/OR GET GE OR THE SUPPLIER OF THE TURBINE/CONTROL SYSTEM INVOLVED TO HELP TROUBLESHOOT AND RESOLVE THE ISSUE IF NOT COMFORTABLE WITH FOLLOWING DOCUMENTATION.

Please write back to let us know what you learn and how you resolve the situation. Just use a logical process of elimination (for which "troubleshooting" is another term!) and you should be able to resolve the problem without even understanding precisely how the MBC/ARES/ETS works, since the tripping is caused by inputs to the software (and the software probably hasn't been damaged).

Dear CSA,

Thanks for your quick response. I will follow your instruction when GT trip next time. But I should give you some detail background history regarding this issue.

We have 2 GTS for base load operation, Same configuration. Recently some major logic modification done for both GTs by GE personnel to operate GTs at Free Governor Mood (Mode?) Operation (FGMO). After this modification, when we operate GTs in Baseload mode, it tripped several times with same signal. Although in preselect mode both GT operate nicely. And after this first CPBH1 failure there also some FPGN 2 sensor failure (L30FPGN2_0,L30FPGN2_1) arise in the SOE. We have sent trip trend to GE. After analyzing trend they told:

both trips are loss of flame

* P2 pressure dropped from 324 PSI to ~ 155 PSI, with constant P1 of
365 PSI

* SRV closed up to 4% and 8%, despite having no change in command to
the valve. Servo current increased to 100% and yet no response from the valve.

* Lost flame as pressure reduced to such low levels and tripped.

-
So, they recommend us to calibrate SRV and other 4 fuel servo valve...so after next trip will calibrate those.

... but another issue

After checking 'control consent' of both GTs by consent reconciliation, we have found that there are total 27 Nos control consent which were not like before logic modification. In this 27 NOs constant there are:

CPBH1 normal standard deviation (live value = 0.009275581, Initial Value = 0.122)

CPBH2 normal standard deviation (live value = 0.002275178, Initial Value = 0.072)

CPD Normal Standard Deviation (live value = 0.1194441, Initial Value = 0.1525)

FPGN1 Normal Deviation (live value = 0.08676753, Initial Value = 0.0075)

FPGN2 Normal Deviation (live value = 0.08551104, Initial Value = 0.003)

FPGN3Normal Deviation (live value = 0.08363903, Initial Value = 0.007)

Compressor press ratio bleed heat gain CSKRPRG (live value = -18, Initial Value = -10) etc., etc.

..so, is there any issue with these values?

1 out of 2 members thought this post was helpful...

shaiideee,

Using AutoCalibrate to attempt to correct improper valve response is ... ludicrous. AutoCalibrate ONLY affects the scaling of LVDT feedback. Full stop. Period. AutoCalibrate DOES NOT affect servo stability or gain or valve response. In fact, if there is a valve or actuator problem using AutoCalibrate improperly will exacerbate the problem and could lead to further problems including emissions problems.

So, sorry--that "recommendation" just doesn't make any sense at all. If the servo current is increasing to maximum but the device isn't responding, AutoCalibrate isn't going to fix what is likely either a servo problem (caused by dirty oil) or an actuator or valve problem resulting in a failure to physically move.

GE programmers quite frequently over-write Control Constants during unit operation. It's not good programming practice and it quite often leads to huge fears and questions when first discovered. Unfortunately in their programming methodology there is no way to avoid the practice, but one would think they would devise some method for avoiding the practice, but they have yet to do so. It can really cause issues when first "discovered" but while it's not very good programming practice it is functional.

You have mentioned Free Governor Mode and Pre-Selected Load Control and Base Load operation as if they are all interchangeable. Base Load mode is not speed/load control, which both Pre-Selected Load Control and Free Governor Mode are. If the units at your plant are Base Loaded units and they are operated at Base Load by selecting Base Load from the HMI they will control fuel to optimize firing temperature which means speed (frequency) is not controlled as it is in Pre-Selected Load Control or Free Governor Mode (which is really just Drop Speed Control).

I fall to understand what Free Governor Mode has to do with P2 pressure and loss of flame and valve failure to respond to command. And I fail to understand how "calibrating" LVDT feedback will fix whatever problem your site is experiencing. I suspect there are multiple issues at your site combined with a lack of experience and training as well as unfamiliarity with basic turbine fundamentals and altogether they are leading to all manner of speculation and doubt--including on GE's part.

Based on the information provided and the questions asked it is recommended to get knowledgeable and experienced GE personnel to site to observe and resolve the issues AND to do some on-site training of technicians and site management because people are grasping at straws right now (site personnel AND GE) and the problems are only going to continue and may get worse until GE observes the issues first-hand and provides resolutions and instruction to site personnel so they understand what is supposed to be happening and why it's not happening.

Unfortunately, there is nothing more which can be done via this forum to help resolve or explain what is being experienced at site. In addition, there is obviously a language barrier to communication which is compounding the inability to understand what is happening versus what should be happening.

Best of luck. While it would be great if we could get the results of the investigation and resolution it's very likely that they will be completely unrelated to the original post/questions, and therefore completely confusing.

Get some training.

Please.