We have MS6001 dual fuel Gas Turbine for Generator drive controlled by original Mark V TMR.

Strange phenomena occurred in successive 3 days (GT running in Gas Fuel)

#1. Day 1 : There is Trip Alarm L71GHH1 <QD1> ("gas scrubber liquid level High Trip"),But the unit still running normally. This contact logic is one of input trip for L4PSTX2 .

#2. Day 2 : Unit is trip without any trip alarm. In the Trip log data shows that L4 is drop by it self even L4T & L94T still in "false/0"
Trip Log ,Time ; L4 ; L4T ; L94T
10:15:29 ; 1 ; 0 ;0
10:15:30 ; 0 ; 0 ;0
10:15:31 ; 0 ; 0 ;0

#3. Day 3 : Unit is trip without any trip alarm. In the trip log data shows that L4 is dropped by : L4T <-- L4PST <-- L4PSTX2.
Trip Log ,Time ; L4 ; L4T ; L4PST ; L4PSTX2
07:51:01.00; 1 ; 0 ; 0; 1
07:51:02.00; 0 ; 1 ; 1; 0
07:51:03.00; 0 ; 0 ; 0; 1.

R,S,T, C condition after trip in A7 state, & no diagnostic alarm at trip timing.
Check to all trip input logic cross reference to alarm.dat , all trip input have its own Alarm ID.

The only action that we've done is change 71GHH1 Switch due to intermittent open of contact & Reboot all computer R,S,T,C due to strange phenomena #1,#2,#3

Test trip was done to check 71GHH1 ==> Unit was trip & Alarm as #1 appear("gas scrubber liquid level High Trip")& trip logic data is same as#3.

Appreciate for any opinion of possible cause for this problem.

 

I have seen this kind of problem occur when there is a discrepancy between the information that has been downloaded to the Mark V and that in the operator interface.

One has to remember that when changes are made to sequencing (CSP) and signal names, etc., they are done on the operator interface (<I> or GE Mark V HMI) and then downloaded to the Mark V processors. For those changes to become effective, the processors must be re-booted.

If one has made changes to the CSP, then one needs to run the CSP Documentor on the operator interface to be able to see the changes in the CSP.PRN file, and when using Dynamic rung Display.

And, when such changes are made to files that are downloaded to the Mark V, the operator interface used to make the changes needs to be "re-started" also, to load the new Global Data Dictionary into the operator interface CPU's RAM.

Then and only then will the operator interface properly display any changes which were made.

And, lastly, if there are multiple operator interfaces being used to communicate with the Mark V, the files that were changed on the operator interface used to make the changes and download them to the Mark V must be copied to other operator interfaces, and they must be re-started to load that information into RAM.

This is necessary (re-starting the operator interface to load the new Global Data Dictionary files into RAM) because the Mark V doesn't use signal names (L4, L71GHH1, etc.) it only uses the memory location associated with those signals (1BE0, or 13F7, as examples). The data values for those locations are sent across the StageLink to the operator interfaces, which then have to "translate" them using the information loaded in RAM.

I'm not saying this is exactly what happened at your site; that's impossible. This is just the most likely scenario. Either you are using an operator interface which doesn't "match" the information which was downloaded to and is running in the Mark V, or the operator interface was not re-started after changes were made and downloaded to the Mark V and they processors were re-booted.

There may be some kind of time delay on the high-high scrubber level trip signal, and it may be that something happened to the timer setpoint, such as during a PROM upgrade, that has caused it to not function properly (this is, unfortunately, more common than it should be).

But, if all the operator interfaces and the Mark V are all "synchronized" (have the same Global Data Dictionary files and CSP files), then problems like you are describing should not happen. Unfortunately, most sites don't understand how important it is to keep all files up-to-date, and how everything works to display information and alarms and events. So, problems like this do occur, but they're not very common.

I hope this helps! But, it's really difficult to say exactly what happened without being able to be on site and look at all the files and operator interfaces. But if properly configured the Mark V and operator interface(s) should never produce this kind of misleading information.

It's possible that by re-booting the processors, you have "resolved" the problem, but, again, without being able to be on site and examine the relevant information it's very difficult to explain exactly what might have happened.

I/O Status A7 doesn't mean that the files in Mark V EEPROM, the files in Mark V RAM, and the files on any operator interface being used to communicate with the Mark V are all in agreement. There's no indication of that anywhere.

 

Thanks CSA for your opinion, I talk with GE guy also have same opinion same as yours.
Anyway , so far the unit is running well.

 

Thanks CSA, we too learned.