Voting Mismatch of FPRG_INT in Mark-V System

K

Thread Starter

Kiran

We have a Mark-V control system for our GS MS5001 GT. Currently we are facing a FPRG_INT Voting mismatch problem. Already T Computer mismatch (FPRG_INT T COMPUTER VALUE : 128) is existing for the past 2 months. But recently 'S' computer mismatch is occurring and resetting by itself very frequently. I want to know the range or tolerance for getting voting mismatch alarm and tripping of GT. We have also observed that there is mismatch in intervalve pressure. 96FG-2A, B, C are not matching. 96fg-a: 14.8 bar, B :15.09 bar, C:12.39. These transmitters range is 0-21 bar. We are using gas as fuel. We also observed that LVDT feedbacks of GCV and SRV are found normal and identical in all the three computers. Can anyone help me out with this issue and suggest me what will be the effect on operation of my GT if we ignore this alarm?
 
Have you used the 'Search' function of control.com to search for FPRG_INT? It's head and shoulders above most other websites/forums on the Internet. This has been successfully dealt with several times before on control.com.

This alarm *WILL* be caused by differences in the P2 pressure transmitter feedbacks, as you have noted. If you had three people telling you what time it was and they all three disagreed, what would you do? Ignore the problem until it became a real nuisance, or fix it? (Most people would try to understand how three timekeepers could be so different and resolve the problem quickly, especially if their livelihoods depended on timeliness or punctuality, and most of ours do.)

Fix (calibrate; repair; replace) your P2 pressure transducers or you will be experiencing continued nuisance alarms and trips.

Unfortunately the "window" for most every Diagnostic Alarm in the Mark V is not viewable nor adjustable, so the limits of mismatch can't be determined for most applications. The *general* rule is a 5% mismatch will result in a Diag. Alarm, but that's not a hard and fast rule.

But, if you will resolve the condition the Diag. Alarm is annunciating, the Diag. Alarm and resulting problems will go away. (As with most Process Alarms.)

(Asked rhetorically and not directed at any individual or firm: Why do people believe that Diag. Alarms can be ignored? They are supposed to be an indicator of problems which, if left unchecked, could adversely affect reliability and availability. And ain't that why we have redundant (dual, triple, or quad) control systems in the first place: to improve reliability and availability?)
 
Top