MarkV: L14HR and Racheting Issue

Mark V TMR system is installed on our site for Frame V gas turbines. Mark V was initially configured with <I> but in 2008 <I> was upgraded to HMI (computer based and with cimplicity). Two gas turbines are installed at our site and each gas turbine has its own HMI in the GT compartment and we have one HMI in the control room for both the gas turbines for displaying data. The fuel used for the gas turbine is Natural Gas.

We are using three magnetic pickups. Same pickups are used for <R>, <S>, <T> and <P> core. Turbine was shutdown and was not under any maintenance. It was showing ready to start status. Turbine cooldown sequence was off. Turbine was at rest speed and L14HR was 1.

On 23-June-2018 at 3:40:34 L14HR became 0 for few seconds and then again came back to 1. It should be noted that the turbine was at rest speed. No alarm was shown on HMI and ONLY ratcheting started. Due to the transition of L14HR the timer (T62CD) for L62CD was reset and again started from zero. We were unable to stop the ratcheting as L62CD was not set.

We started to monitor T62CD so that as soon as timer is completed and L62CD is set we can stop the ratcheting (L62CD sets when when timer T62CD reaches to 24 hours). On 23-June-2018 at 8:25:11 the timer was reset to zero again due to L14HR toggling from 1 to 0 and back to 1 again. Turbine was at rest and no alarm appeared on HMI.

At 8:32 we got the following alarms<pre>
23-JUN-2018 08:42:37.875 T1 1 Q 0287 ALM PROTECTIVE MODULE ACCELERATION TRIP- HP

23-JUN-2018 08:42:37.937 T1 1 L4T EVT Master Protective\Turbine Trip

23-JUN-2018 08:42:40.000 T1 1 C 2906 DIA Voter mismatch, <T> L12H_ACC

23-JUN-2018 08:42:43.000 T1 0 C 1850 DIA Voter mismatch, <R> L12H_ACC</pre>
These alarms cleared after master reset but T62CD was not restarted due to these alarms.

We started to monitor TNH1 on pre-vote data screen. TNH1 for <S>, <T> and voted remained at zero percent. TNH1 for <R> core was changing from 0 to 10%. As soon as the TNH1 for <R> increases beyond 5% we get the following alarm

DIA Voter mismatch, <R> L12H_ACC

However this does not result in toggling of L14HR and does not rest T62CD.

Due to varying value of TNH1 for <R> we checked the magnetic pickup connections of all the three cores. They were found Ok.

When we remove speed pickup from <R> and <S> core QTBA prevote value varies between 0.12% to 0.6%. When we remove speed pickup from <T> core QTBA its value on prevote data reads upto 63% that results in number of alarms. Is this the normal behavior?

L14HR is still toggling between 1 and 0 after every few hours and we are not able to stop the ratcheting. When L14HR toggles and timer is reset we are not getting any alarm on HMI. What can be the possible cause of this problem and how can we rectify it?

NOTE: We do not intend to force L62CD.
 
Esoteric_Stone,

Is this occuring on the same Mark V turbine control panel which had the battery ground you wrote about a couple of years ago? (And which we never heard any results from?)

This kind of behaviour is NOT normal. What Diagnostic Alarms (ALL of them, please--even the ones you don't believe are relevant) are present?

If you're not going to run the unit and you don't want the Hydraulic Ratchet to start, then forcing L62CD to a logic "0" is about the only thing that will prevent the ratchet sequence from initiating--until such time as the problem with the speed pick-up inputs are resolved.

When you say the speed pick-up inputs are being "disconnected" from the QTBA cards, are you disconnecting ALL the wires from each of the two speed pick-up input terminals, or just the wires from one of the speed pick-up input terminals?

Are the speed pick-up inputs to <R>, <S> and <T> jumpered from the respective QTBA terminal boards to <P>?

Are there hard-wire jumpers installed at <P> PTBA-3 to -4, and -7 to -8, and -11 and -12? Those are the LP shaft speed pick-up inputs, and if not used it was customary to install a wire jumper across each pair of terminals to short out the input so that there would be no intermittent LP shaft speed signals to <P>.

Have you tried measuring the resistance of all the shaft speed pick-up inputs, first at the junction box closest to the #1 turbine bearing, then when both of the wires from each of the speed pick-ups is disconnected from the QTBA terminals?

Have you tried jumpering out the speed pick-up inputs at the QTBA to see what happens?

Have you considered running temporary twisted, shielded pair cables from the JB closest to the speed pick-ups themselves all the way to the Mark V (on the "floor")--just to see what happens in this case?

Do you have an oscilloscope to look at the speed pick-up inputs to see if there is, in fact, some frequency coming in on the wires?

Have you checked to ensure the shield drain wires of the twisted, shielded pair cables used to connect the speed pick-up inputs to the Mark V are properly terminated along the entire length of the cables?

Has there been any work done on the wiring or the speed pick-ups recently?

Have there been any new wires/cables run into the Mark V, or into the vault underneath the Mark V? Especially from around the turbine, accessory compartment or generator? If so, what do these new wires/cables provide power to?

Does the site experience electrical (lightning) storms--and if so, have there been electrical storms recently?

About the only way I could envision a signal coming into the Mark V on the speed pick-up input wires is if there is some source of electrical noise on the cable(s) that bring the speed pick-up input signals from the turbine accessory compartment to the Mark V. AND, then it would only likely occur if the shield ground wires were not terminated properly.

Lastly, most Mark V turbine control panels had electrical power filters installed in the very bottom of the Mark V panel, back behind where all the field wires came up into the bottom of the Mark V, just about in the middle of the Mark V panel (so, underneath and behind <QD1>). The purpose of those filters was to prevent electrical noise from the Mark V from getting out of the Mark V and causing problems with other devices which might share the AC and DC sources used to power the Mark V. It's possible that those filters have been damaged and electrical noise from the AC and/or DC sources is getting into the Mark V.

By the way, once again, thank you for the complete information you have provided on the problem and the results of your troubleshooting. IF ONLY we could get such good information from most of the other people who post here for help. (We would like feedback, though!)

Looking forward to the answers to the questions!
 
Esoteric_Stone,

I want to mention, also, that GE has, in recent years, been adding a flame detected permissive to the cooldown sequence initiation logic. So, if the unit is just cranked without establishing flame it wouldn't automatically go on cooldown.

If any flame was detected while the unit was above cooldown initiation speed then when the unit would automatically go on cooldown.

This is an easy modification to the logic, and completely in line with the OEM's current philosophy.

Of course, if the unit were shut down or tripped from load and for some reason it was STARTed in CRANK mode and then STOPped, it would still be incumbent on the operator(s) and their supervisor to make sure the unit went on cooldown if the highest wheelspace temperature was still above 150 deg F when the unit was taken off cooldown (that value, 150 deg F, is also a published number by GE in GER-3620 (available for download by searching the World Wide Web) for safely taking the unit off cooldown).

The whole 12 hours, or 24 hours, or whatever sets L62CD to a logic "1", was always an arbitrary number. It really depends on how hot the unit is, and wheelspace temperatures are the best indicator of both internal- and rotor temperatures, as well as bearing temperatures (which is the secondary consideration for cooldown).

Hope this helps!
 
CSA

I have to admit that your memory is very sharp. You never forget anything. Yes, coincidentally it's the same turbine. Last time we changed DCC card to solve the problem. The battery ground alarm is still present. We always rectify the battery ground problem, but somehow it always appears after some duration of time. This time varies from a week to a month.

No diagnostic alarm appeared at the time when ratcheting started. When we checked the events log (on internet explorer) we only seen an EVT in which state of L14HR was changed. I am posting it below.<pre>
22-JUN-2018 09:41:21.001 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
22-JUN-2018 09:41:27.005 T1 0 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
22-JUN-2018 09:44:28.559 T1 0 L52QA SOE QD1-DTBA-077 Auxiliary lube Oil Pump running [52QA-1]
22-JUN-2018 09:44:29.748 T1 1 L63QT2B SOE CD -DTBA-091 Low lube oil pressure - trip load [63QT-2B]
22-JUN-2018 09:44:29.750 T1 1 L63QT2A SOE QD1-DTBB-013 Low lube oil pressure - trip load [63QT-2A]
22-JUN-2018 09:44:32.886 T1 1 L63QA2L SOE QD1-DTBA-091 Low lube oil press - aux pump start [63QA-2]
23-JUN-2018 03:40:34.687 T1 0 L14HR EVT HP Speed - Zero Speed
23-JUN-2018 03:40:34.715 T1 1 L52QA SOE QD1-DTBA-077 Auxiliary lube Oil Pump running [52QA-1]
23-JUN-2018 03:40:34.938 T1 0 L72QEZ SOE CD -DTBA-079 Emergency lube oil pump motor aux relay [72QEX]
23-JUN-2018 03:40:36.062 T1 1 L14HR EVT HP Speed - Zero Speed
23-JUN-2018 03:40:37.440 T1 0 L63QT2B SOE CD -DTBA-091 Low lube oil pressure - trip load [63QT-2B]
23-JUN-2018 03:40:37.443 T1 0 L63QT2A SOE QD1-DTBB-013 Low lube oil pressure - trip load [63QT-2A]
23-JUN-2018 03:40:41.605 T1 0 L63QA2L SOE QD1-DTBA-091 Low lube oil press - aux pump start [63QA-2]
23-JUN-2018 03:40:41.875 T1 1 L72QEZ SOE CD -DTBA-079 Emergency lube oil pump motor aux relay [72QEX]
23-JUN-2018 03:40:42.104 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
23-JUN-2018 03:40:48.174 T1 0 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
23-JUN-2018 03:43:54.973 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]</pre>
If I force L62CD the ratcheting will be stopped but what if we have to start the turbine. Will we have to unforce L62CD before starting? To my understanding we can start the turbine but when the turbine will be stopped or tripped the ratcheting will not be started automatically and the operator will have to start it manually. Am I correct?

When you say the speed pick-up inputs are being "disconnected" from the QTBA cards, are you disconnecting ALL the wires from each of the two speed pick-up input terminals, or just the wires from one of the speed pick-up input terminals?

About disconnecting the wires from QTBA, first I removed one wire from <T>'s QTBA, its prevoted value was showing 63%. When I removed the second wire of this sensor there was no change. It was still showing 63%. At that time following alarms were appeared<pre>
22-JUN-2018 09:41:21.001 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
22-JUN-2018 09:41:27.005 T1 0 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
22-JUN-2018 09:44:28.559 T1 0 L52QA SOE QD1-DTBA-077 Auxiliary lube Oil Pump running [52QA-1]
22-JUN-2018 09:44:29.748 T1 1 L63QT2B SOE CD -DTBA-091 Low lube oil pressure - trip load [63QT-2B]
22-JUN-2018 09:44:29.750 T1 1 L63QT2A SOE QD1-DTBB-013 Low lube oil pressure - trip load [63QT-2A]
22-JUN-2018 09:44:32.886 T1 1 L63QA2L SOE QD1-DTBA-091 Low lube oil press - aux pump start [63QA-2]
23-JUN-2018 03:40:34.687 T1 0 L14HR EVT HP Speed - Zero Speed
23-JUN-2018 03:40:34.715 T1 1 L52QA SOE QD1-DTBA-077 Auxiliary lube Oil Pump running [52QA-1]
23-JUN-2018 03:40:34.938 T1 0 L72QEZ SOE CD -DTBA-079 Emergency lube oil pump motor aux relay [72QEX]
23-JUN-2018 03:40:36.062 T1 1 L14HR EVT HP Speed - Zero Speed
23-JUN-2018 03:40:37.440 T1 0 L63QT2B SOE CD -DTBA-091 Low lube oil pressure - trip load [63QT-2B]
23-JUN-2018 03:40:37.443 T1 0 L63QT2A SOE QD1-DTBB-013 Low lube oil pressure - trip load [63QT-2A]
23-JUN-2018 03:40:41.605 T1 0 L63QA2L SOE QD1-DTBA-091 Low lube oil press - aux pump start [63QA-2]
23-JUN-2018 03:40:41.875 T1 1 L72QEZ SOE CD -DTBA-079 Emergency lube oil pump motor aux relay [72QEX]
23-JUN-2018 03:40:42.104 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
23-JUN-2018 03:40:48.174 T1 0 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]
23-JUN-2018 03:43:54.973 T1 1 L33HRF SOE CD -DTBA-017 Hydraulic ratchet limit switch forward stroke [33HR-1]</pre>
Then we connected the <T> core pickups and disconnected <R> core pickups. Now the prevote data for <R> was showing 0.12%. We connected <R>'s pickup and removed <S> pickups and the prevote data of <S> was also showing 0.12%. Isn't <T> showing too much value when we removed the pickups? Is it normal?

Are the speed pick-up inputs to <R>, <S> and <T> jumpered from the respective QTBA terminal boards to <P>?
Yes, the speed pickup from QTBA boards are jumpered to <P>.

Are there hard-wire jumpers installed at <P> PTBA-3 to -4, and -7 to -8, and -11 and -12? Those are the LP shaft speed pick-up inputs, and if not used it was customary to install a wire jumper across each pair of terminals to short out the input so that there would be no intermittent LP shaft speed signals to <P>.
No jumpers are not installed on the mentioned terminals.

Have you tried measuring the resistance of all the shaft speed pick-up inputs, first at the junction box closest to the #1 turbine bearing, then when both of the wires from each of the speed pick-ups is disconnected from the QTBA terminals?
We checked the resistance in the JB. We disconnected the pickups from JB and checked their resistance. The resistances were 202, 216 and 220 ohms.

Have you tried jumpering out the speed pick-up inputs at the QTBA to see what happens?
No, we did not try that. Is it safe to jumper the inputs on QTBA?

Do you have an oscilloscope to look at the speed pick-up inputs to see if there is, in fact, some frequency coming in on the wires?
We do not have oscilloscope at our facility.

Has there been any work done on the wiring or the speed pick-ups recently?
No work was done on pickups.

Have there been any new wires/cables run into the Mark V, or into the vault underneath the Mark V? Especially from around the turbine, accessory compartment or generator? If so, what do these new wires/cables provide power to?
No new wiring was done.

Does the site experience electrical (lightning) storms--and if so, have there been electrical storms recently?
No electrical storm was observed.

There is a LED bar on the DCC card. The LEDs on all three cores were not synchronized. We powered down the whole MarkV panel (We turned off <R>, <S>, <T>, and <P>) and powered up again. After powering up we waited for 24 hours. The timer did not restarted after that and L62CD is set and ratcheting is stopped.

Where can I get the information about the LED bar on DCC card? Should all the three cores have same pattern?

On <C>'s DCC card only leftmost led is blinking on LED bar. Is it okay?
 
CSA
Our turbines do not have flame detected permissive to the cooldown sequence.

I want to mention here that we are upgrading MarkV to MarkVIe on one of our turbines. Should we ask for this modification in the logic?

This modification will increase the responsibility of operator.

Secondly our turbines are not in service currently. The operator do the ratcheting daily for one hour. As L62CD is set operator can start and stop the racheting manually. If we incorporate the flame detected permissive, will the operator be able to start and stop the ratcheting manually?
 
Esoteric_Stone,

Yes, if you make the modification, or have it made, the operator will still be able to manually and stop COOLDOWN just like before. The only difference will be that if you crank the unit (or if the speed pick-up inputs are erratic--which they SHOULD NOT be!) the unit will NOT automatically go on COOLDOWN when STOPped. It will only go on cooldown automatically IF the unit was above zero speed AND flame was detected.

Oh, ..., Er, ..., Uh, ..., You will probably be getting this modification in the Mark VIe application code, though GE WILL NOT be able to tell you in advance if they are providing it or not--nor will they be able to tell you all the OTHER modifications they will be providing. Only that you are getting "the latest and greatest" improvements to the control and protection of your unit. (And you thought they were going to just duplicate the existing sequencing...! Well, the lawyers won't let that happen.)

You can ask, but it's not likely until you click on the START button that will know if that little bit of code is in the Mark VIe or not. and, then pretty much every time you click on the START button you will learn about more new--and undocumented--"features" you received but they didn't tell you about.

If GE just duplicated the existing sequencing and then offered a menu of modifications (which would be confusing to some--especially those who make the purchases, who don't usually have a lot of experience with the day-to-day operation and maintenance of the units) the Mark VIe as a turbine control retrofit would not get the poor reputation it has earned. It's a fine control system, but the way it is implemented can be very frustrating. And, I would venture that the commissioning person from GE or it's vendor will not be able to look at the application code and say what's new versus what was in the Mark V. And, when you challenge GE on these new modifications, they will argue that the unit functions just like it did before--it produces amperes. And, technically, they will be right. But, in reality there will be some differences, and some may be very different.

If your force L62CD to a logic "1" then the operators will be able to select COOLDOWN OFF (if it's on cooldown) and then if L14HR toggles again I believe it won't try to go back on cooldown automatically. <T>BUT,</b> I don't have access to any logic at this writing and I'm not sure if it will prevent the Mark V from going on COOLDOWN if someone forgets to unforce the signal before STARTing the unit, or if it will prevent the unit from going on COOLDOWN if the unit trips or is shut down after running. Sorry; it's been a while since I've looked at that scheme....

Good to hear that re-booting the Mark V in an orderly fashion seems to have resolved the speed pick-up issue for now, at least.

But, it just seems very odd that you continually pick up grounds on this one panel and that you correct the problem, but it comes back. Can you elaborate on what you find when you correct the grounds? Is it always in the same location/area?

Converting this a Mark VIe will possibly help with some issues--but if the grounds keep coming back it may be worse with the Mark VIe.... Just saying....

Anyway, best of luck with the Mark V-to-Mark VIe upgrade. Let us know how that goes!
 
Esoteric_Stone,

Good troubleshooting--especially the part about performing an orderly shutdown and power-up of the Mark V. CONGRATULATIONS on solving the issue for now, and thank you for the feedback!

It WILL NOT hurt anything to add the jumpers (just short pieces of insulated wire) between the three pairs of terminals on the <P> PTBA. It cuts down on nuisance problems with those input being open-circuited by shorting them.

It would be safe to jumper the HP shaft speed pick-up inputs on the QTBA terminal board just as a test. The speed pick-ups produce their own power (they are passive, inductive speed pick-ups) so the Mark V does not power those terminals, it only looks for a small voltage and then measures the frequency of that voltage (which is produced as the toothed wheel rotates beneath the speed pick-up face).

Another thing I forgot to ask: Have you checked the speed pick-ups to be sure they are securely bolted in place, and that the gap between the face of the pick-up and the high spot of a tooth of the toothed wheel is correct?

You did not mention checking the twisted, shielded pair drain wiring along the entire path of the loop from the speed pick-up all the way to the Mark V? I have seen many times where the shield drain wires were terminated properly on one unit at a multi-unit site, and improperly on another unit at the site. This results from poor construction supervision and lack of knowledge on the part of the electricians. And it has happened many times over my three decade career.

>There is a LED bar on the DCC card. The LEDs on all three
>cores were not synchronized. We powered down the whole Mark V
>panel (We turned off <R>, <S>, <T>, and <P>) and powered up
>again. After powering up we waited for 24 hours. The timer
>did not restarted after that and L62CD is set and ratcheting
>is stopped.

ALL the LED bargraphs (as they're formally called) on the DCC cards--in <R>, <S> & <T> and <C> (and <D> if present)--should flash in the same sequence and at the same time(s). Any LED bargraph which flashes differently from the others indicates a Diagnostic Alarm is present in that processor. (The same is true of the three TCEA card LED bargraphs in <P>, and the TCDA LED bargraphs in <CD>, <QD1> and <QD2> (if present), and the TCQA cards in <R, <S>, and <T>. All like cards in all cores should always flash in the same sequence and at the same rate (presuming the LED bargraph segments are all working) when everything is good and there are no Diagnostic Alarms. The Mark V processors and cards are all very tightly synchronized together when everything is happy and healthy and the various LED bargraph flashing sequences should indicate that.

Unfortunately, the LED bargraphs were only used by the development engineers when developing and testing firmware on the cards. There was no standard in GE to ensure that when testing was done the functionality of the LED bargraphs were returned to a particular standard. And since there were several development engineers working on the software and the cards and no one was checking their work and seeing to it that the flashing was returned to some kind of standard everyone of the engineers just left them at whatever sequence they were using.

So, no; there is no documentation of any kind on the meaning of the LED bargraph flashing segments--and if there was, it would have to match the version of software in use on the card. And, GE just didn't ever intend for those to be used by anyone in the field.

AND, unfortunately sometimes individual LED bargraph segments also fail, so it's difficult to tell if the flashing sequence is different or not.

BUT, you should always--if all of the segments are working--be able to look at the Diagnostic Alarm Display OR the LCC display to see Diagnostic Alarms if the segments are flashing out of sequence. Most--but not all--of the Diagnostic Alarms that appear in the LCC Display are also displayed in the Diagnostic Alarm Display on the <I> or HMI. Especially in later versions of the Mark V (some earlier versions had a few Diagnostic Alarms on the LCC Displays that didn't show up in the Diagnostic Alarm Display on the operator interface).

Hope this helps! Wish the news were better, but it is what it is, as they say.
 
Top