MK-V <P> question

Hello All,
What can cause all three TCEA cards of protection module <P> stop functioning, at the same moment?
Theirs green LED bars stop running. Recycling power from <PD> returns them back to life and unit runs normally.
We've replaced two common cards of <P> - power supply card and TCTG.
No 125VDC GND Alarm present when the problem occurs.
It happend at Fuel Changeover from Liquid to Gas, immediately with 20FL-1 closed feedback we get Hyd Trip Press Low both at liquid and gas circuits.
There is no feedback from 20FG-1 solenoid. Both 20FL-1 and 20FG-1 are operated from <P>. We will check them electrically at next opportunity.
Alarm sequence attached:
Please, your thoughts and suggestions would be appreciated.

While it is true the stop valve solenoids are connected to <P>, I think you are ascribing entirely all too much responsibility to the TCEAs in the <P> core. To my knowledge, the <P> core of a GE-design heavy duty gas turbine consists of three TECA cards (Loc's. 1, -3 & -5), a TCEB (I think that's the name--it's the one in Loc. 2) and the TCTG card (in Loc. 4). I don't know of a "<P> core power supply "card"). Each TCEA gets 125 VDC from the <PD> core, via the J7X, J7Y and J7Z switches/cables (if I recall correctly). And the power for the other cards comes from the J7W connector in the <PD> core.

The TCEAs all vote--through the Primary- and Emergency Trip Relays on the TCTG card (this is clearly visible in the Signal Flow Diagrams in an appendix in the Mark V Application Manual, GEH-6195). The PTRs get their signals from the respective processors (<R>, <S> & <T>) via the IONETs of <R>, <S> & <T>. The ETRs get their signals from one of two places--either the TCEA cards (<X>, <Y> & <Z>) or via the signal L4_XTP from the three control processors (<R>, <S> & <T>)--again the L4_XTP signal comes via the IONET--I believe. The PTR signals from <X>, <Y> & <Z> are a function of a couple of things--the E-Stop P/B circuit, the overspeed detection functions of the individual TCEA cards, and the rate of change of speed detection (not well known, this one).

You need to understand what Diagnostic Alarms are present for ALL cards, and communicate that to us. If one TCEA thinks the unit should be tripped for some reason (faulty or intermittent overspeed pick-up for example) and another TCEA decides the unit should be tripped for another reason (E-stop P/B circuit loose or intermittent connection), then that's two out of three--but there WILL be Diagnostic Alarms to let you know what's going on. It is true--a SINGLE Diagnostic Alarm will NOT result in a turbine trip, BUT some combinations of Diagnostic Alarms will--not just for the <P> core, but also for the control processors.

I'm NOT saying the problem ISN'T in the <P> core, I'm just saying from the information provided it doesn't seem (to me) that the problem is the <P> core. Yes, the <P> core provides the positive and negative 125 VDC for the trip solenoids (20FL-1 and 20FG-1), -65 VDC through the PTRs and +65 VDC through the ETRs. Those signals come from the TCTG to the terminal board in Loc. 6 of the <P> core. And, that's ANOTHER common card for <P>--the terminal board in Loc. 6 of <P> (I think it's called the PTBA card, but I may be wrong about that; I don't have access to Mark V manuals at this writing).

You also didn't say WHEN this problem started. After a maintenance outage? After a trip from load? After a heavy rainstorm or electrical storm (lightning)? AND, as glenmorangie says--are you sure there isn't a 125 VDC battery ground?

Finally, an IOMA Power Supply out of Limits Diag. Alarm is nothing to ignore. It appears to be coming from <S> (at least in the screenshot photo). The IOMA is a pretty important part of each of the three control processors.

Anyway, I'm just saying in my personal opinion, based on the information provided, that it doesn't seem likely the problem is something in <P>, unless there's a ribbon cable connector which has corrosion on it that needs cleaning and lubricating (with conductive grease such as is found in MOST (but not ALL) Mark V spare card boxes), or a loose connection, or something similar. A LOT of seemingly odd problems like this can be traced to corrosion on ribbon cable pins/receptacles. If it's been more than a couple of years since conductive grease has been applied to the ribbon cable connectors--it's been too long!!! And, remember: Too much conductive grease is worse than none!!! A thin film applied to the ribbon cable connector and then the connector is plugged and unplugged several times before firmly seating it will do the trick. A heavy film of conductive grease will make a mess, especially in a dusty, dirty environment. Also, check all the wire terminations of all the trip solenoid circuits--from the Mark V <P> core terminal board through every junction box (main and intermediate) all the way to the trip solenoid sub-junction box (if so equipped). Also, check crimp terminal for good, solid crimps.

Hope this helps! Please write back to let us know how you fare in resolving the problem(s).

I have been ruminating on this thread and the information provided. It’s entirely difficult to understand how all three TCEA cards can freeze at the same time. Unless there was some kind of 125 VDC power supply problem which affects all three TCEAs.

I don’t recall seeing all thre TCEA cards freezing at the same time. In fact, I don’t recall seeing even one TCEA freeze (the LED bar graphs stop flashing their sequence). I haven’t seen every phenomenon and problem with the Mark V but I have seen many, maybe most. But this one is very baffling.

And it would be extremely interesting to see the Diagnostic Alarm display just prior to this issue as well as immediately after the issue.

Again, the TCTG card has the PTRs which are operated by L20FL1X and L20FG1X in <R>, <S> & <T> in your case, which are basically controlled by L4. The ETRs are operated by the TCEAs with the cross-trip signal, L4_XTP, from <R>, <S> & <T> The TCEAs monitor the overspeed speed pickups for overspeed AND excessive rate of change. The cross-trip signal is just a redundant way of ensuring the stop valve trip solenoids get de-energized when L4 drops out in <R>, <S> & <T>.

So, I gotta think the problem isn’t predominantly in <P>, but it certainly might be (I know; I’m changing my mind—but when troubleshooting a sticky problem one has to be flexible!) if it’s not something being caused by a problem with the 125 VDC power.

The power for the trip solenoids is (and should be) entirely separate from the power for all other 125 VDC solenoids. Meaning there should be no (108) power to either of the stop valve trip solenoids. If the unit also has a 20FD-1 (Liquid Fuel Forwarding) solenoid, especially one manufactured by Laurence Valves (I think I spelled that name correctly) I have seen those solenoids fail in a way that causes either a large inductive “kick” (spike) on the 125 VDC system, or it blows the time-delay fuse in the 20FD-1 circuit which can also cause problems for the 125 VDC system, especially if the battery charger and/or batteries are old and failing. (A single battery which has a deep build-up of sediment at the bottom of the plates can actually reverse polarity and when a high current draw is placed on the battery it can reduce the battery voltage by 20% or more during the initial surge of current. Battery charger output filter capacitors can and do fail causing issues when there is inductive kicks or current surges. Battery and charger maintenance is very important to control system maintenance.)

Finally, GE used to install filters on high-current and high inductive current devices (such as Laurence Valve solenoids and generator trip coils and even GE HGA-style relays (which were often used in Generator Control and/or Protection Panels provided with units packaged by GE USA) to protect Mark V components from damage (until they increased the design robustness of some of the Mark V components).

That’s about all I can add to this thread based on the information provided. Please update us on your progress with this problem.

I have had an opportunity to look more closely at the alarm photo you attached to your original post. What seems to have caused the trip is the loss of liquid fuel trip oil pressure, but without being able to see the CSP running in the Mark V it's very difficult to say why that should have caused the trip if the unit was transferring from liquid to gas--because the liquid fuel trip oil pressure SHOULD HAVE dropped when 20FL-1 was de-energized and the SOE shows the liquid fuel stop valve went from open to closed before the trip oil pressure dropped. So, this seems a little odd; I would expect that when 20FL-1 is de-energized it would take a split second for the trip oil pressure to drop sufficiently to allow the hydraulic dump valve to shut off the flow of high-pressure hydraulic oil to the liquid fuel stop valve actuator and for the valve to move from open to closed. But, once 20FL-1 is de-energized the logic shouldn't care that the liquid fuel trip oil pressure decreased enough to signal a trip. AND, if something was amiss with the trip oil system in general THAT could be responsible for the sudden and unexpected drop in gas fuel trip oil pressure.

Another thing I find unusual and difficult to explain is that the <P> core detected a turbine overspeed trip AFTER the fuel stop valves should have closed.... AND, there was some kind of disagreement on overspeed detection. Now this could have been caused by the TCEA cards "freezing", but why?

Some other unusual things .... Why are the two fuel stop valve solenoid logic signals NOT in the EVT or SOE log? The generator breaker should have opened very soon after the fuel stop valves closed, and that doesn't appear in the EVT or SOE, either. There was another alarm, REMOTE EMERGENCY TRIP, which is presumed is also a trip coming from a ... DCS?

The low gas fuel trip oil pressure signal was 0.250 seconds after the low liquid fuel trip oil pressure. Possibly insignificant, but still a difference. (If the unit uses the typical 125 msec scan rate (8 scans per second) that's two scans after the low liquid fuel trip oil pressure.)

And, we don't really know WHAT Diagnostic Alarms were present before, during and immediately after the trip occurred, either.

Changing the TCEB and TCTG cards were probably not going to help anything--but it may have. If it were me, I would be testing the trip oil system in addition to the fuel stop valve solenoids. AND, I am ASSUMING that the Mark V was supplied with the unit when it was new and originally commissioned (so, not as a turbine control retrofit or upgrade on an older unit with an older turbine control system). Older units may have the servo interface module which was necessary to allow electro-hydraulic servo-valves to function as solenoid valves before solenoid valves were used as fuel stop valve solenoids. (I'm sorry; I can't remember the name of this servo interface module right now; it's been a LONG time since I've seen or worked on one--unfortunately.)

Anyway, just some observations. Still not enough information, and the information that has been provided is kind of odd. AS IS the description of all three TCEA cards freezing at the same time. But, a list of Diagnostic Alarms from the trips would probably help understand a lot--but maybe not. My money's still on something unusual with the 125 VDC power supply (battery; battery charger; inductive kick; high current draw; etc.). But, I would really like to understand this problem and what triggered the TCEAs to all freeze and require re-booting. Very strange, indeed.

The TCEAs are really independent protection cards--<X>, <Y> and <Z>, so named because they are part of the turbine protection system. They are the emergency, or "back-up" overspeed protection and as such are supposed to be independent of <R>, <S> and <T> even though they are associated with <R>, <S> and <T>. In fact, because the protection code on the TCEA cards runs at 100 or 128 Hz and the CSP only usually runs at 8 Hz, the <P> core should detect an overspeed BEFORE <R>, <S> and <T> ever do (under normal circumstances). And, the <P> core (TCEA cards) is designed to be totally independent of <Q> in order to provide the redundant overspeed protection. So, three TCEA cards freezing at the same time (or nearly the same time--we really don't know exactly when they froze, do we????) is very odd indeed.

Anyway, keep us up to date, please!
CSA, glenmorangie,
Thank you indeed for giving a thought to an issue and spending time to write it down.
Yesterday we've checked function of 20FG-1 and 20FL-1 stroking them independently and also simulated fuel changeover situation, including hydraulic oil pressure and monitoring influence on pressure and system voltages at DiagC. Nothing suspicious. No pressure drops and no serious P125/N125 fluctuations. This morning we've found full DC GND ( P125 = 0 / N125 = -126 ), traced it and found intermittent GND at Water Cooling tower JB. But this could and could not be a reason for a main problem, just because no 125DC Fault was detected closely before and during the event.
Checked DIA Alarms and only IOMA Power Supply Out Of Limits P15 from <S> and <T> where written prior the trip. Interestingly, according to DiagC 15v <S> and <T> voltages even better then the one of <R>. In the past, to liquidate this type of alarm we replaced TCPS card of the particular controller, because tuning was no help. And even replacing was not always helpful.
Thats about all news that a can share for today. Additional information and update will be gladly provided, when we will have it.
I have been thinking hard about this event. I finally remembered something similar. I was assisting some technicians at a large steam plant with other issues when they described an event in which P core did not alarm yet caused a trip to the hydraulics.

The cause was the red high current ribbon cables that send PT/CT information to P core. The found the damaged cable and replaced it and the problem was no longer.

Other than that, I have found that P core is rock solid in performance.

Yeah; GE stopped the practice of putting CT inputs to the <P> core because so many people don't know to short the CTs before lifting wires.... GE used a PLU (Power Load Unbalance)core for large steam turbines, too. But, the bigger problem with those inputs to the <P> core (and even the PLU) was that the wires were not run in the proper locations in the panel and so would occasionally cause induced voltages which lead to nuisance and intermittent problems. Some electricians and electrician-wanna-be's--and commissioning personnel just don't understand industrial wiring practices and aren't properly supervised or don't properly supervise during construction.

That, and chafed ribbon cables, as you mentioned, can cause problems, too. That was another thing GE had to work on in the beginning of the Mark V--the ribbon cables and interconnecting cables were not always routed well, and some were even too short to begin with and were just "stretched" by factory personnel instead of bringing the problem to Engineering's attention.

This problem is either going to be something very simple, or it's going to be one for the memory banks. Based on the information provided, it's a head-scratcher. And, a lot of times--as you know--these kinds of problems are ALWAYS the Mark*'s fault, until they aren't (and they usually aren't). I wish we'd hear back from the original poster at some point. I'm guessing they can't afford to trip the unit and/or can't shut it down to do any testing. So, for the moment they are amassing the shot for the shotgun approach--do every recommendation at once and hope and pray the problem doesn't return--and if it doesn't no one will ever know what the root cause was. (I'm not a personal fan of the shotgun approach for troubleshooting--but it's damn popular in many places in the world!)