GT MARK-VI TRIP

B

Thread Starter

BN

The GT HMI screen displayed indications become similar to the condition when Mark VI panel is Power off (i.e #### marks & black colour tabs). It may however be noted that the HMI indication got restored within around 2-3 minutes of the Trip.

The Mark VI panel was inspected within 3-4 minutes of the trip during which the LEDs of all the modules were found synchronised & healthy (I/Os and Processors).

Following are some of our observations:

1) The TripLog file of trip date did not capture any data. The event list in the triplog file are random and it gives all the possible event which is related to the trip.

2) In the TripLogLive file, it was observed that no data was logged between 11:23:24 & 11:25:37 while the trip occured at 11:23:27 hrs.

3)After GT tripping, no command was generated for generator trip

4) No abnormality seen on MK6 panel/processor (to elaborate no processor, power supply, I/O card failed)

5) Trip log at that time of trip didn't capture any data. (Trip log live was logging data before this trip and after GT startup), it seems data was not captured specifically during this trip.

What can be the possible reason for this???
Please give ur views...
 
BN

was there any set of diagnostic alarms annunciation prior to tripping?? or was there any diagnostic alarms already present which wasn't taken care of??

did you check all tightness of cables, its continuity from DCDB and UPS?? after GT tripping was 88-HR (assuming it's power source is from the same 125V DCDB as your MARK VI supply) running smooth??

and what is the current situation in your plant, is it running fine??
 
So, it seems that for some reason UDH communication was lost between the Mark VI and the HMI.

It's going to take some time for communications to resynchronize and all background tasks (such as TripLogLive) to get back up to speed.

Another thing is that when there is a turbine trip a LOT of information is broadcast onto the UDH, especially if there are a lot of signals which were configured as SOEs. Consider there are Process Alarms, Diagnostic Alarms, SOEs, and any other changes of state--plus Trip Log information. It's just a lot of information, and it sounds like there was already some kind of existing network problem that resulted in the lack of communications prior to the turbine trip.

It's pretty clear we don't have all the information or enough information to be able to help with your problem. And it's likely we never will have enough information, especially since most sites ignore Diagnostic Alarms. If you think you can "recover" the missing information, it's lost and gone.

Instead, concentrate on what was happening prior to the trip that caused the loss of UDH communications.
 
but i don't get it how UDH communication failure result to a trip of Mark VI GT and that to in Event list there is no such command from MK-VI to GT for tripping the machine.
 
A UDH communication issue does NOT cause a turbine trip.

I didn't relate the loss of UDH communications to the cause of the trip. All I said was that because there was obviously something amiss with UDH communications prior to the trip that it's likely that during the trip UDH communications hadn't been fully re-established.

And that during a trip there are MANY alarms and events all being broadcast onto the UDH in a very short time. Which can add to the problems of re-establishing UDH communications.
 
Top