Mark VIe tracing out the trip trigger

I am fairly new to the gas turbine control system. so pre-apology for any stupidity that may come out.
I want to know how the trip trigger can be traced out from trip log that is saved after trip. All of the personnel at site are fairly new to the Mark VIE systems so usually there is a difference of opinion among people why the turbine tripped.
As i understand from trip log- events page - the alarm after recorder trigger is the trip. or is it the alarm before the recorder trigger.
Is it always necessary to use trend to find out what happened?
why some times the alarms not listed in the alarm viewer and we have to go back to trip log to find out the reason.
We have frame-5 gas turbine with MARK VIe. Our HMI doesn't have access to toolbox ST
Good day Munna

Did you read and take some notes from GEH**** Manuals regarding the Mark6e and Associated equipments?

I would suggest you to read the guide /instructions/ operations manuals for get some knowledges on how Alarms/Trips are managed with Mark6 and control ST workstation.

I know that There is a function called DDR ( Dynamics Data recorder) available for troubleshooting faults /alarms /events.
But since now i cannot tell you what is exactly doing since I am just beginning to read those manuals.

I know that it is a function ( capture buffer) can be setted and parameters adjusted for getting trends and views wic is a powerful tool if someone know how to handle with.

To answer to these questions i think that someone should clearly be aware of what Mark6e is capable to do since its a powerful equipment and having excellents tools for helping operator to get the plant operating in a correct and smooth manner.

I will have a look on this

Looking to hear back from you soon ,

There are LOTS of different implementations of Mark VIe out in the world right now. Many only use <R>, <S> and <T>, or <R> and <S>. Many now use Mark VIeS for "emergency" protection (thank you EU protectionists!) which complicates this explanation greatly because you haven't described how your "Mark VIe" is configured.

I'm going to address the Mark VIeS-LESS system in the absence of a proper description of the turbine control system at your site. The "trigger" for the Trip History trends is usually the signal L4, the Master Protective logic signal. L4 must be a "1" to run the unit, and the something happens that calls for the turbine to be tripped (something in <R>, <S> and <T> in a TMR (Triple Modular Redundant Mark VIe, or <R> and <S> in a DUAL Redundant Mark VIe), The logic (rung" for L4 looks like this:

L4S L4T L4
---| |-------|/|---------------( )

(If it was difficult to "draw" in before, it's next to impossible now!)

In the above rung, L4S is a momentary logic signal that is set to logic "1" when all the start-check permissives are met, a START is initiated and there is sufficient L.O. pressure to spin the turbine-generator shaft. L4T is a logic signal that is set to logic "1" when any one of a number of conditions that can cause a turbine trip are detected--in other words, it is a logic "0" when no trip conditions exist L4T is a logic "0"--and during a START no trip conditions can exist (so L4T will be a logic "0"). So, when L4T is a logic "0" AND when L4S is momentarily set to a logic "1" (closing the normally open contacts) THEN L4 will become a logic "1". When L4 becomes a logic "1" the normally open L4 contact in the L4 rung will change to closed--which will latch (or "seal in") "around" the L4S contact--which will go back to a logic "0" (the normally open contacts will revert to open). But, the L4 contact in parallel with L4S will remain closed and keep L4 energized (true; logic "1"; picked up). This is a VERY simple rung--when there are NO trip conditions (when L4T is a logic "0") and when L4S becomes a logic "1" then L4 will become a logic "1" and WILL REMAIN a logic "1" until L4T goes to a logic "1"--which will "break" the latch (break the seal-in) and cause L4 to go to logic "0".

L4 is used in a LOT of places in the Mark VIe application code--a >>LOT<< of places. One of the places it is used is as a permissive to open the fuel stop valve(s). So, when L4 goes to a logic "0" one of the permissives to open and keep open the fuel stop valves is lost, and the fuel stop valves--by their design--close VERY quickly, shutting off the flow of fuel to the turbine combustors.

The capture buffers used in the Mark VIe application code to record data for the Trip History trends will sense that L4 has changed state from a logic "1" to a logic "0" (when L4T has gone to a logic "1"!) and will continue to capture data for a pre-defined time and will then make the data in the capture buffers available to the "HMI." Here's where things get a little murky for me--I don't know exactly how the capture buffers tell the "HMI" there is Trip History data available and I don't know how exactly the data is transferred from the Trip History buffers to a designated location on the "HMI" for review and analysis.

What I DO know is this: I have been seeing LOTS of Mark VIe installations and HMI upgrades that were NOT properly configured to automatically upload the Trip History data to some location on the HMI to be available for review and analysis. And because the "mechanism" (method) of this transfer and file placement is NOT documented (anywhere that I have found) it is very difficult to troubleshoot and resolve without GE's help. And even when GE becomes involved in trying to troubleshoot and resolve the issue GE is not able to quickly fix the problem--again, most likely because GE has not properly documented how this is done, leaving it a mystery to most people, even in GE.

Anyway, that's how the Trip History works--or is supposed to work. The capture buffers in the application code running in the Mark VIe are usually set to trigger on a single signal: L4. when it transitions from a logic "1" to a logic "0". And, then some magic happens and the data is transferred to the HMI for review and analysis.

Now, for why some alarms aren't always available in the Alarm History. I think that's most likely caused by improper setting of the WorkstationST Alarm Viewer--which has MANY different filters and configurations available. One really needs to take the time to completely read and study the WorkstationST Alarm Viewer manual to understand all the capabilities and options and settings of WorkstationST Alarm Viewer. I suggest that all the alarms ARE in the Alarm History file, all the time--but that WorkstationST Alarm Viewer is not being used properly or is not properly configured at the time of use and that results in some alarms not being visible AT THE TIME WorkstationST Alarm Viewer is being used to analyze alarms.

Lastly, when a turbine trips the operators MUST be instructed to NOT immediately click on MASTER RESET--no matter what they have been previously taught or believe or think they should do. This is the single biggest mistake on sites when a turbine is tripped--to very quickly click on MASTER RESET, which very quickly makes analyzing why the turbine tripped (if it's not already known) very difficult. That's the first thing: Operators should NOT be allowed to click on MASTER RESET until the Operations Supervisor allows them to do so. (Now that means the Operations Supervisors might need some training, but not much.)

Next, the Operators and the Operations Supervisor need to immediately go to the Trip Display on the HMI and write down ALL of the conditions which appear in RED on the display. Yes, that's right--write them down. (Most sites have disabled the printer, or the printer doesn't have a good ribbon, or the printer doesn't have any toner, or doesn't have any paper, or some other such stupid reason which makes using the printer as a troubleshooting tool impossible.)

Then, using the current WorkstationST Alarm Viewer window on the HMI, the Operators and the Operations Supervisor need to slowly scroll backwards through the alarm list and find the first occurrence of every condition that was written down from the Trip Display and write down the time the alarm went to ALARM (not when it went to NORMAL--when it went to ALARM; when the alarm actually first occurred). The oldest time on the list is most likely the cause of the turbine trip.

Trender or Trend Recorder can then be used to look at the data from the Trip History capture buffers, which should include lots of little triangles below the graphical data next to the time axis along the bottom horizontal edge of the graph. By hovering the mouse cursor over the triangles (there will likely be LOTS of triangles) messages will appear on the display to indicate time and date and alarm condition/trip messages associated with each triangle. It will likely be necessary to zoom in on the data at the time of the trip (which should be obvious on the graph) to get better resolution (time) to see the data and the event triangles.

That's how to troubleshoot trips. One has to be methodical and logical, and use the available tools (properly configured). The Trip Display can be very helpful, but because GE has not really come up with a good "first out" trip function (well--GE Florence has, but, of course other GE divisions aren't using it (because they didn't invent it...!) it means one has to use the Alarm History AND the Trip History in some cases to understand what tripped the unit. It's a good thing to learn, and once one practices it a few times, it becomes very easy to spot what tripped the turbine from the WorkstationST Alarm Viewer window.

BUT, Operators MUST NOT click on MASTER RESET >>until the cause of the trip is determined!!!<< Period. Full Stop. Remain calm. Be logical. Follow a methodical troubleshooting process. It will seem "slow" at first, but after a while it will become very fast and routine.

I think WorkstationST Alarm Viewer can be configured to determine how often specific alarms (trips are alarmed!) occur, and that can be useful, too. But, one has to RTFM (Read The Fine Manual) to learn how to do that--and it's a VERY GOO manual to read and study because WorkstationST Alarm Viewer is a VERY USEFUL troubleshooting tool for many purposes, not just trips.

Now, there are OTHER things which can trip the turbine, besides functions in <R>, <S> and <T> (or <R> and <S>)--ones in the PPROs (the former <P> core/function). One of the most difficult to troubleshoot is the "Composite Trip"--which usually means that something is already being alarmed (via a Diagnostic Alarm) in the PPRO(s) and the operators are NOT paying attention to it. Or, there is a loose wire in the Emergency Stop Pushbutton circuit(s); or there's a problem with Emergency Overspeed Trip speed pick-ups. Something related to the TPROs or the TREG or the PPRO(s).

Hope this helps!
Good day Munna

Did you read and take some notes from GEH**** Manuals regarding the Mark6e and Associated equipments?

I would suggest you to read the guide /instructions/ operations manuals for get some knowledges on how Alarms/Trips are managed with Mark6 and control ST workstation.

I know that There is a function called DDR ( Dynamics Data recorder) available for troubleshooting faults /alarms /events.
But since now i cannot tell you what is exactly doing since I am just beginning to read those manuals.

I know that it is a function ( capture buffer) can be setted and parameters adjusted for getting trends and views wic is a powerful tool if someone know how to handle with.

To answer to these questions i think that someone should clearly be aware of what Mark6e is capable to do since its a powerful equipment and having excellents tools for helping operator to get the plant operating in a correct and smooth manner.

I will have a look on this

Looking to hear back from you soon ,
Dear James (controlsguy25),
Thank you for your time and suggestion.
I have all the manuals and read some part of it (didn't get time to read it fully as its 1000's of pages and took me 2 days nearly to sort out and rename some for easier access), Now my habit is to read completely when a problem pops up in one of the part and come back to to use the search. Its my habit and my memory is better when i learn this way.
And for this specific question i think manuals wont be much help as it doesn't contain real-time examples. (at least i didn't find it until now)
Dear CSA,
We have triple redudancy in Mark VIe and we have Mark VIeS for safety/protection. other than that i don't know the details for configuration.

L4 was easier to understand with your explanation. (initially difficult i took paper and draw the diagram for clarity. I think its same like push button start/stop NO/NC contacts)

as L4 is the trigger for the recorder i saw that trip log have data from specific time before the trip to after trip. So how data from pre trip time is captured and saved? (there must be some type of temporary memory that's storing and dumping all data s continuously to be ready for a trip?)

As for alarms I think it got cancelled due to master reset because at that specific time it was urgent to put back the unit in service ASAP(production always neck //// ). and we don't have a printer configured to print even though i saw printer in HMI room above one of the panels, GE people didn't care during commissioning and i believe our plant personnel are totally blank about the use of it.

during the trip generator trip due to one of electrical protection acted (breaker only should have opened keeping GT at FSNL). But consequently GT trip due to something and Restarted immediately. As it was night shift and end of shift nobody cared about the alarm or cause of trip, until next day morning all were on feet on why the GT trip. so the trip log came out and there started the difference of opinion.
as per event list it was some thing like this. (from memory)
breaker open - GT trip - recorder trigger - radial vibration alarm.
so people believed its vibration that tripped, but i believe something else tripped the turbine and vibration came after trip (the time stamps indicate that alarm difference are all less than 5ms)
I took out the trend and filter for radial vibration, FSR , generator MW, vibration trip voted.
even though some of the point vibration was high, i think vibration trip voted is the point of trip if its vibration that caused the trip (usually vibration have a time delay before the trip is latched??)
as per trend vibration trip voted change of state (from high to low) was after 30ms (my memory, anyway its after) of FSR becoming 0.
there was no other alarm other than vibration to prove my side

sorry i cannot take the trend with me due to our company policy/restrictions.

Ah, the Mark VIe$.... Totally unnecessary and outrageously expensive.

But I digress....

I presume the unit has conventional combustors (diffusion flame combustors, as opposed to DLN (Dry Low NOx) combustors which stage the fuel in two different combustion zones in the combustor and use multiple gas control valves). Further, I presume the unit may even burn liquid fuel (either distillate (HSD, or #2 diesel, etc.) or naphtha or heavy fuel).

If, as you believe, the generator breaker was tripped by some protective function that did not require the turbine to be tripped, and the unit should remain at FSNL (Full Speed-No Load) so that it could quickly be re-synchronized once the condition which tripped the breaker was fully understood and resolved, it's highly likely the fuel was cut back so quickly that flame was lost in one or more combustors with flame detectors resulting in a 'LOSS OF FLAME TRIP.'

Generally keeping the turbine running after the generator is tripped while on load (also commonly called a "load rejection") requires some tuning of operating and control parameters, especially when operating on liquid fuels. Maintaining operating speed after a load rejection while operating on gas fuel can also be problematic for slightly different reasons. But, even when auxiliaries are tested and tuned for such operation after a load rejection if one component or device is not working properly then maintaining flame and speed after a load rejection can be quite difficult to maintain.

It's not unusual for some units to experience high vibration shortly after a load rejection, but USUALLY there are multiple vibration sensors and more than one vibration sensor which must simultaneously indicate vibration levels high enough to trip the unit to protect it.

EVERY GE HMI equipped with ControlST is SUPPOSED to be configured to store about one month's worth of alarms and events on the HMI. WorkstationST Alarm Viewer can be used to look back at user-defined time periods to examine past alarms. The Operators should have noted in a written Log of some sort the date and time of the trip and that information can be used to review past alarm and event logs to determine what happened.

The capture buffers running in the application code in the Mark VIe are continuously capturing a "rolling" group of data, and when L4 changes from a logic "1" to a logic "0" the capture buffers can be--and usually are configured--to continue to capture data for some pre-determined time period after the trip so that data both before and after the trip will be available.

Further, EVERY GE HMI equipped with ControlST is SUPPOSED to be configured to write the contents of the Trip History capture buffers once per hour to the HMI hard drive. And, this data is usually maintained for a period of about seven (7) days. And Trener or Trend Recorder can be used to open these files and examine them. The files can also be copied to another folder on the HMI hard drive for more permanent storage and review.

The GE HMI has--or is supposed to be configured to have--several methods of troubleshooting. It's not high-speed data, and it's not EVERY signal or point in the control system, but if configured properly the information should be helpful. And, the Trip History capture buffers can be modified, easily, to add more points if necessary. (That doesn't mean old data can be looked at; only new data for the newly added points can be looked at going forward.) The standard for GE turbine control systems has always been: EVERY condition that results in a trip has a Process Alarm associated with it. And, by looking, carefully, at an alarm "printout" (be that a paper printout or an electronic alarm "history") it should IS POSSIBLE to determine the cause of the trip without ANY OTHER information. Period. Full stop. It's not always easy, but it is possible.

Without actionable data--a Trend Recorder file or an Alarm History file--it's virtually impossible (even over the Internet!) to say what might have caused the trip. But, AGAIN--the Standard Operating Procedure for ALL units should be to collect data on EVERY trip, using the previously outlined suggestions as a starting point for the site-specific procedures. It's just ludicrous and a waste of everyone's time to try to troubleshoot a trip without ACTIONABLE data--data that can be reviewed and analyzed using any number of different tools.

It's commendable that you are trying to understand how to troubleshoot trips and alarms, but you also need to move on from trips which do not have any actionable data to analyze. A printer ("old school" dot matrix printer, yes--but there's a specific reason for that which MANY people simply do not know, realize or try to understand) is almost always provided with a GE turbine control system. The reason "old technology" ("old school") printers are used is this: They can print messages on paper one line at a time (which almost ALL alarms are, no matter the control system). People say GE is "behind the times" and continues to use "old technology" for alarm printers by using dot matrix printers. But, they are the best technology--even today--for the application: printing one-line alarm messages, dates and times. They should be venerated, and treated with respect. They are often the best--and sometimes the only--method of analyzing alarms, particularly when there is a trip. The printer ribbons should be stocked in the plant warehouse/stores; paper should be available at all times; and the printer should be working and on at all times. Even if most of the paper gets thrown away; it is still invaluable in many instances. It just takes time, patience and experience to read the alarm list and determine what happened and when using a logical thought process and a methodical approach.

Even if you know what caused the turbine trip, people should be analyzing every alarm printout (paper or electronic) after a trip if for no other reason than to get experience and practice doing so. EVERY operator should receive a copy of the alarm printout after a turbine trip, and EVERY operator should analyze that printout and write down what they believe happened. And a knowledgeable and experienced Operations Supervisor should be reviewing EVERY Operator's written review and making comments and suggestions to help improve everyone's ability to read and understand alarms. This should be standard operating procedure at every plant, so that every Operator gets the skills they need to properly operate and protect the units under their care. Alarm Management--contrary to popular opinion and belief--is the SINGLE MOST IMPORTANT JOB OF AN OPERATOR. Period. Full stop. End of discussion. Properly responding to alarms helps operators to anticipate alarms, and to know how to handle situations that arise. Including getting the unit back up and running as quickly as possible. Or preventing catastrophic damage.

Hope this helps!
Dear CSA,
sorry for omitting the details. ours is a DLN1 type frame 5 with gas fuel. 3/6 GT are new and Other 3 are upgrade from markV to MarkVIe with DLN.
We are planning to do a load rejection test to check the parameters and verify our controls are ready for it in next trip. As we cannot afford to trip GT due to our requirements most of time.
we think we have a problem with way our alarm are configured (i believe its that time isnt synchronized properly in controllers) and GE is going to check into it. I will come back with feedback if they ever tell me what all was it.
Our historian isn't working as still the project not completed. hopefully soon it will be.
our Management feels same about the printer as u said, its obsolete, nuisance etc.. and GE didn't try to correct them on that and agreed to keep it as its.
Alarm management with newer control system should be easier than before. but many problems that is yet to be solved and giving the headache. Usually operations give a reason for trip then GE/engineering come and say its not that even though in alarm sequence first alarm should be the reason to trip other alarms are consequence of trip.
Lack of training due to budget constrains also a cause for that, but if ever any management realize it, all will be long gone.

Thank you for your feedback and support as always