We work in a combined cycle power plant where there are 4 gas turbines and 1 steam turbine running successfully for last 20 years. The model of the gas turbine is GE PG6551B associated with Alstom T190-240 generator operated by MarkV Control System. During December 2015, we have upgraded turbine parts to 32k parts (including turbine buckets, fuel nozzles, combustion liner, flame scanners etc) and MarkV to MarkVIe control system. After that, the gas turbine base generation increased to 38+ MW from 34MW. It was doing well then. But after 9 months (September,2016), we have faced generator + turbine trip running at base load due to Generator differential protection (We are using LGPG111 for combined generator protection) while other units remained unaffected (no Grid related issues).
That time we checked the stator current (IST1,2,3) curves, visually inspected the generator, did PI test, measured stator winding resistance and found nothing abnormal and started/synchronized the unit thinking of false alarm. But after that tripping due to generator differential protection started happening on irregular intervals sometimes twice in a month even in part load. As a matter of concern, we hired professionals to test the generator in depth (TAN delta, Partial Discharge, PI etc), and they certified that the generator is in very good condition. We have checked the generator CT secondary loop to relay panel and found OK, even we replaced the CT cables right from generator junction box to A520 panel. We have tested the generator CTs (ratio, saturation) as well as generator protection relay (LGPG111) by hired professionals and found all in very good condition. We have earthing resistance near the generator and the earthing resistance is found 2 ohm. Tripping due to generator differential protection become a nightmare to us now and don't know what to do next.
Before installing turbine 32k parts and MarkVIe, we never faced generator differential trip issue and we know that generator differential protection has nothing to do with 32k parts or MarkVIe.
Have you ruled out a bad configuration or faulty differential relay? What about PMing the relay panel and associated connections?
Thank You. We have already checked the CT secondary loop multiple times and also the LGPG111 relay with secondary injection test device. Besides no wiring/configuration of the relay and its connections were replaced/altered before the happening the problem after commissioning. We are afraid that we don’t know what you meant for “PMing”. Can you please explain it?
Has the relay settings been reviewed in the differential protection relay since the MWs have been increased. And since you have checked the CTs, CTs polarity can be rechecked once again.
The differential relay settings is currently as IS1=0.15KA, K1=0% and IS2=3.0KA, K2=10% and its as same as other 3 units of same model. At part load (21MW), the differential currents are as Ia-diff=0A, Ib-diff=4A, Ic-diff=4A and At base load (39MW), the differential currents are as Ia-diff=4A, Ib-diff=8A and Ic-diff=8A. The differential setting is not revised/altered after MWs have been increased. We have checked the CTs polarity by "professionals" and it was found OK. To check it again we have to ask them again as we don't have a CT tester at our site. But please consider that the turbine was successfully running for last 20 years and the CT connections were not opened ever before the recent trips happening.
The generator differential trip lock-out (86G) is a device that can be tripped by MANY different devices (or just one, if it is a multi-function digital protection "relay"). You need to have someone examine the schematics for the 86G relay trip (actuation) circuit and eliminate each one of the potential causes of the actuation (tripping) of the 86G lock-out relay.
I'm not personally familiar with a LGPG111 relay, but you say it has been verified "by professionals."
USUALLY, there is a contact that is closed when the 86G lock-out relay is in the reset position that is connected to the Mark* and when that contact opens it signals the Mark* that the 86G lock-out relay has been actuated (tripped) by one of the many possible inputs, and that to protect the generator the turbine needs to be tripped. It's usually just a single contact (closed when there is NO trip condition detected and the 86G lock-out relay is reset; open when the 86G lock-out relay is actuated and a TRIP condition has been detected).
You haven't said if the 86G lock-out relay on the generator protection panel has tripped and has required a manual reset before the turbine can be restarted. If the 86G lock-out relay is NOT being actuated and is NOT requiring a manual reset, then it's very likely that something is wrong with the wiring between the 86G lock-out relay and the Mark*. OR, that there is something wrong with that input "channel" or input card of the Mark* (which would USUALLY be accompanied with a Diagnostic Alarm). It could just be a loose wire termination somewhere in the circuit, or a bad crimp-on lug.
You also haven't told what Process- and Diagnostic Alarms were present and active BEFORE the trip occurred, and what Process- and Diagnostic Alarms were annunciated at the time of the trip and after the trip (say for 10-30 seconds after the trip). Even if you don't think the alarms are relevant--please provide a comprehensive list of alarms, in chronological order. Many times, some, but not always all, of the devices that can actuate (trip) the 86G lock-out relay also have contacts connected to the Mark* that can indicate which condition specifically actuated the 86G lock-out relay. Even multi-function digital relays also have these contact outputs for alarm annunciation.
Finally, any protective relay which trips the 86G lock-out relay SHOULD have a "flag" on the relay to indicate when it is actuated. (A "flag" can be a little orange indicator which is uncovered or drops, or an LED which illuminates, to indicate a condition was detected and the relay caused the 86G to actuate.) I was on one site MANY years ago where the 86G lock-out relay actuated SO FAST that it didn't allow the flag to be actuated on the protective relay that was actuating the 86G lock-out. It took about 12 people standing on chairs and ladders looking at every possible relay that could trip (actuate) the 86G relay to find the one that was causing the problem (it was a generator differential current relay--not that it matters to this thread). The relays were all electro-mechanical relays and they had disks that rotated when they were sensing faults, and the disk of the generator differential relays were moving but the flags weren't dropping because the 86G relay was tripping so fast. (The fix was to put an RC network on the tripping coil circuit to slow it down, by 10th's of a second, to allow the relay flag to drop. And, the real cause was that the CT wires had been inadvertently reversed by the testing crew--there was no actual differential current condition; just reversed polarity wiring.)
So, please tell us if the 86G lock-out relay is being actuated (tripped). And, if not, then it's likely the contact or wiring of the 86G lock-out relay input to the Mark*. Or some problem with that input channel of the Mark* or the printed circuit card/I/O pack of that input channel. If the SOE function for the 86G lock-out input is not enabled, it should be enabled to help in troubleshooting.
Hope this helps! Please write back to let us know what you find, and provide the answers to the questions above if you need further help.
Our LGPG111 relay sends it output signals through separate relays (each for every protection, i.e. generator differential, stator overcurrent, reverse power, under frequency etc.). One contact of the 3 contacts of the relay is used for interlocking the relay itself, 2nd contact is connected to Mark* as L87G through "Diode Matrix" and the 3rd one is used for separate alarm annunciation system with T1000. If the LGPG111 or any other relay is actuated for tripping, a separate push button is lit namely "Tripping relay reset" which must be reset (manual) along with resetting the actuated relay before starting the turbine. We don't have any other combined lockout relay for the turbine.
We are sorry, that we forgot to mention, for those trips, every time the LGPG111 relay itself got actuated with an indication of Red LED "Trip" associated with system buzzer. After diagnosis of every trip, before starting the turbine, LGPG111 relay and the "tripping relay reset button" was reseted manually. So, as per your suggestion, we think, its not a problem associated with Mark*.
Please consider that, after each trip, we have gone through the IST1,2,3 curves and found the values are within limit. For each Trip, the alarms are as follows:
1) "Generator differential trip-PPRO" (15:03:33.401)
2) "Generator electrical trouble" (15:03:33.401)
3) "Generator differential protection" (15:03:33.401)
4) "Boiler not purged, diverter open, trip GT" (15:03:34.041)
1) Generator differential trip-PPRO (09:22:23:278)
2) Generator electrical trouble (09:22:23:278)
3) Generator differential trip (09:22:23:278)
4) Generator differential protection (09:22:23:318)
5) Boiler not purged, diverter open, trip GT (09:22:24.598)
1) Generator differential trip-PPRO (21:18:25.201)
2) Generator electrical protection (21:18:25.201)
3) Generator differential trip (21:18:25.201)
4) Generator electrical trouble (21:18:25.201)
5) Remote breaker open detected (21:18:25.482)
6) Boiler not purged, diverter open , trip GT (21:18:25.601)
1) "Generator differential trip PPRO" (19:57:56.241)
2) "Generator differential protection" (19:57:56.241)
3) "Generator differential trip" (19:57:56.241)
1) Generator differential trip (15:18:56:282).
2) Generator differential protection (15:18:56:282).
3) Generator electrical trouble (15:18:56:282).
4) Generator differential trip-PPRO (15:18:56:282)
1) Generator differential trip. (13:03:42:203)
2) Generator differential protection (13:03:42:203).
3) Generator electrical trouble (13:03:42:203).
4) Generator differential trip-ppro (13:03:42:203).
1) "Generator differential trip"(16:46:28:238)
2) "Generator differential protection"(16:46:28:238)
3)" Generator electrical trouble"(16:46:28:238)
4) "Generator differential trip-PPRO"(16:46:28:238)
1) "Generator differential trip" (10:00:53.478)
2) "Generator differential protection" (10:00:53.478)
3) "Generator electrical trouble" (10:00:53.478)
4) "Generator breaker trip" (10:00:59.630)
1) "Generator differential trip" 14:08:06.604
2) "Generator electrical trouble" 14:08:06.604
3) "Generator differential protection" 14:08:06.604
The generator CT (line and neutral) secondary connections (separate core for differential protection only) is directly connected to LGPG111 Relay input terminals (Please refer to the above link for CT connections, we are now using 2nd cores of all CTs previously kept reserved for Generator differential current on the neutral side from 3rd cores and kept 3rd core secondary terminals shorted as per GE recommendation to solve Differential issues). No separate relay is used in our system to actuate the LGPG111 relay. It is great to know what you have faced earlier with "flag issues" of 87G lock out relay and solved it. Your previous experience has added a feather to our experience. Thanks for sharing. We are confident that no CT wire is reversed. Please be noted that the turbine is running at 21MW load while we are writing this reply.
Finally, summing up all above, the LGPG111 relay actually tripped on each cases.
Two things jump out at me from the information provided. First, are the 'Alarms' you listed times for actually alarms (Process Alarms? If they are, then do you have the SOE information for the inputs which drive those alarms?
SOE is the term given to the optional function that can be used to monitor the change of state of any discrete (contact) input with a 1 millisecond degree of accuracy. Now, before you say it--yes, you provided time stamps with a 1 millisecond degree of accuracy. BUT, the way most Mark* turbine control systems report Process Alarms is that during any execution scan (usually a 40 msec time period) they record ALL of the Process Alarms which occur during that time period then they report all of them with a single time stamp that has a 1 millisecond resolution. So, as posted--there are many 'alarms' that are all being reported with the same time stamp--down to the same millisecond. BUT, it's probably pretty unlikely that if every one of those alarms all came from individual relays of the LGPG111 they all changed state at the same millisecond in time.
The SOE feature allows the Mark* to report the exact instant (with a 1 millisecond resolution) the discrete input changed state. If that change of state occurred sometime after the execution scan started, say, 13 msec after the scan started, then it would be reported as such--and the alarm would be reported with the execution scan rate time stamp. So, the SOE feature would be useful in determining precisely when each discrete input actually changed state--which would be useful in trying to troubleshoot which came first.
The second thing is the "diode matrix" ... I think I have heard of this, but, I've never seen one used on a Mark* turbine control system. I would be highly suspect of such an arrangement, and would imagine it has some kind of power supply associated with it (or it uses the power from the PDIO and terminal board.
I'm also not clear if the Mark V was upgraded to a "Mark Ve" or it was upgraded to a full-blown, real Mark VIe (meaning the Mark V control panel was determinated and completely removed, and replaced with a true Mark VIe control panel, and the wires were re-terminated to the Mark VIe. In the Mark Ve, some Mark V cards are removed and replaced with Mark VIe-compatible cards in the plastic card carriers, then connected using IONET switches to UCSx cards (which replaced the LCC/SLCC and DCC/SDCC card combinations). So, if you could clarify precisely how the Mark V was upgraded it would be very helpful.
At this point, I'm really thinking the problem is the LGPG111--regardless of what the "professionals" say--and/or the diode matrix arrangement of inputs from the LGPG111 to the Mark*. But, that's just a SWAG (Scientific Wild-Arsed Guess) based on the information provided and some knowledge of how Mark*s work and report alarms.
Are you working with the packager/supplier of the Mark* to sort out the issue? If so, what are they offering and recommending to do?
You haven't indicated what, if any, Diagnostic Alarms, are annunciated by any and all packs and processors in the Mark*--REGARDLESS of whether they seem relevant. They might be important; they might not. But, let us be the judge of that.
Finally, since we can't post images or attachments to control.com responses/threads, many people scan drawings or photo's and post them to free websharing sites (such as www.tinypic.com) and then post the URL in a response to control.com so we can see them. Personally, I would greatly appreciate seeing the electrical schematic drawings of the diode matrix of LGPG111 inputs to the Mark.... GREATLY, I would appreciate it.
One more thing, I have two sneaking suspicions. First is, does this panel use a Marshaling Cabinet between the field wires and the Mark* I/O terminal boards, and if so, are there also any kind of current limiting devices between any of the inputs/outputs and the Mark*? Second, does the Mark* use 125 VDC for contact input circuits, or some other wetting voltage?
Thank you for taking the pain to address and solve our generator differential issues. Please check the link (http://tinyurl.com/gen-differential) to get a better understanding regarding the drawings and SOE we currently have.
For the "Diode matrix" (in A502 panel) (please refer to the above link), the power supply comes from a 125VDC bus directly came from A507 panel which is from the units local 125VDC system associated with Battery and charger. The diode matrix takes input from protection relays and directly sends the signal for associated trips/alarms to Mark*.
We are sorry that we did not mention earlier about how the upgradation was took place. In our site, the old Mark V panel was fully replaced by new Mark Vie panel and all the old cables are terminated directly to the new Mark VIe panel with new tagnames. (there were some issues arose to install new type flame scanners and vibration transducers, where new cabling was done from field).
As for the diode matrix and protection relay, Previously we had some issues with false trips, where the unit tripped for protection trips (i.e., overcurrent, earthfault), where the relays did not send trip signals and after diagnosis we just replaced the diodes or sometimes cleaning up the diodes resolved the issues. But, If the protection relay itself sends trip signal, the diode matrix has nothing to do rather to carry the signal to Mark* to trip.
Here are the last trip record we just recently printed from LGPG111 relay. Please have a look on this:
Protection: 87G Generator Differential A
Relay Output Status: GENE.DIFF.87G
Logic Input Status: 27/81V Inhibit
Scheme Output: Enabled
Active Setting Group: 1
Ia-Mean Bias: 2434A
Ib-Mean Bias: 2220A
Ic-Mean Bias: 2295A
Active Power Aph: 13.88MW
Reactive Power Aph: 3.477MVAr
Phase Angle Aph: -16.0deg
Whereas the setting for generator differential in the LGPG111 relay is:
Again, All the field cables are terminated in A520-Marshaling Panel and then connected to Mark* or other relay panels and there is no "current limiting device" installed between any of the inputs/outputs and the Mark*. And Mark* use only 125VDC for contact input circuits and no other wetting voltage. We are collaborating with GE for long term service agreement. Please refer to the above link for CT connections, we are now using 2nd cores of all CTs previously kept reserved for Generator differential current on the neutral side from 3rd cores and kept 3rd core secondary terminals shorted as per GE recommendation to solve Differential issues.
Sorry for the lateness of my response. I think I understand the concept of the diode matrix now, and in my personal opinion it's typical of GE Belfort--overcomplicate and unsimplify. Unfortunately, the deed is done, and you have to live with it.
Looking logically at this problem--as has been presented--there have been nuisance trips in the past, related to the diode matrix AND the LGPG111. They were resolved after some work, and were seemingly not attributed to the LGPG111.
The CT inputs to the LGPG111 were not disturbed during the Mark V-to-Mark VIe upgrade (that is not clear, but it doesn't seem it would have been necessary just to upgrade the Mark*).
It seems you are certain from your tests and observations the source of the tripping is the LGPG111 outputs. So, either the inputs are the problem, or the relay is the problem (presuming the diode matrix is not the problem--and the complexity of the scheme doesn't help to troubleshoot or understand the scheme).
I would have to imagine the plant has a Master Time generator which all the control systems are connected to.?.?.? And, you can use the SOE function of the Mark VIe to help try to understand what is happening first, second, third, etc.
This problem seems to have started some time after the Mark* was upgraded--meaning that things were fine for some time after the upgrade. If there are no Diagnostic Alarms and no other indications the problem is with the Mark VIe, it seems to point to either the inputs to the LGPG111 or the LGPG111 itself.
It seems the relay isn't made any longer. Have you looked into trying to buy a used or new-old-stock relay?
Thank you for uploading the files and picture; it was helpful. But, unfortunately, I'm still a little unclear about the CT inputs. Again, try to break down the problem into small parts, and then do what you can to eliminate each part--or the root cause may become obvious.
I might also suggest renting a digital storage device and connecting it to the same CTs connected to the LGPG111, and seeing if the device reports the same conditions as the LGPG111. Sometimes the expense of the device can be justified if the plant loses a lot of revenue and reliability on each trip.
I wish I could have been of more help. And, it would be great if you could write back to let us know what you find as you work through this issue. GE can be helpful, but you need to find the right people who will 'take ownership' of the problem and get the other human resources involved to help investigate and resolve the problem. Much easier said than done, especially when working with GE in Belfort, France. Again, there are some good people there, but getting them involved usually requires getting planets to be aligned in a particular way....