Today is...
Monday, March 27, 2017
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Liquid Fuel Bypass Valve Oscillation
MKV machine liquid bypass valve starts oscillate after machine reaches 20MW and appears steady

Hello Control Guys!

In our 9E / MKV machine when loading 20MW and up Liq.Bypass valve starts oscillate while control signal is stable.

I looked over very useful threads about MOOG valves, Bypass valve check etc., but I still have a problem to solve at my site.
In addition to the written above, the unit started on gas fuel, transferred to liquid at FSNL, reached 20MW with no problems, steady FQLT, FQLM, flame detection, CTXF's and TTXD's, and at some point Liq.Fuel Bypass valve started to oscillate really bad. Checked control signal to the valve - stable. What can cause this behaviour?

Can it be a problem in hydraulic oil system ( we had an alarm at acceleration and aux.hydr.pp started, wich should've eliminated possible low hyd.oil pressure)?

Can it be a wrong MOOG valve type (771GK208 is original and we mounted 771GK200A, the only one we have now)?

Any other possibilities (there are a lot, for sure)?

Thanks for your time!

1 out of 1 members thought this post was helpful...

Could be a fluctuating hydraulic pressure causing valve to move. Is the hydraulic pressure steady? I don't know what the difference in part nos. that you give means, but if it was a GE part no and the final Pxxx was different it would that the servo was designed for a different flow rate. If that that is the same for your different Part Nos. then you have a problem.

2 out of 3 members thought this post was helpful...


When did this problem occur? Did it start after a maintenance outage? Did it start after a trip from load?

How often does the unit operate on liquid fuel? What kind of liquid fuel is being burned when this problem occurs?

I agree with glenmorangie, the problem could be a fluctuating hydraulic pressure, but if the unit starts on gas fuel with little or no problems and transfers to liquid fuel with no problems (and the IGVs are stable--they are also hydraulically actuated) a fluctuating hydraulic pressure is not likely the problem.

There is sometimes a pressure gauge for the discharge pressure of the Main (Accessory Gear-driven) hydraulic pump, as well as for the discharge pressure of the Auxiliary (AC motor-driven) hydraulic pump. What are the two pressures saying when the two pumps are running? Have you tried shutting down the Aux. Hyd. Pump when the unit reaches FSNL? (How is the unit synchronized if the Aux. Hyd. Pump is running when you reach FSNL???)

A GE-design Frame 9E heavy duty gas turbine usually has a hydraulic accumulator which serves to dampen MOST hydraulic pressure fluctuations. The hydraulic system on a GE-design heavy duty gas turbine has very little flow when the unit is operating at a stable load--because the hydraulically-actuated devices are not moving. There's only a small flow through the servo-valve to drain when the device is in the correct position.

If the hydraulic accumulator is not working properly (not charged to the proper pressure; the valves are not in the proper position(s); the bladder is damaged) then fluctuations from the pump can be transmitted to the system, and when there are high flow-rates (such as when the IGVs move, particularly) then the system pressure will fluctuate.

If the unit has been operating for some time it's possible the internal surface of the liquid fuel bypass valve hydraulic actuator could be worn and allow hydraulic oil to pass which affects operation (stability).

Liquid fuel stability is very much dependent on a steady liquid fuel supply pressure--if the supply pressure is fluctuating badly enough it can have very serious effects on the liquid fuel bypass valve and unit stability. BUT, that would almost always be accompanied with fluctuating servo current to the servo trying to compensate for the change in flow-rate.

What kind of control system does the unit have? Have you been able to trend and operating data when this occurs? Are there any Diagnostic Alarms being annunciated by the turbine control system--if so, what are they? What other Process Alarms are being annunciated during this problem? (Please provide ALL of the alarms, Process and Diagnostic, even if you don't think they are related.)

Lastly, as glenmorangie says, just because a Moog servo-valve looks the same from the outside doesn't mean it has the same flow-rate--which could be contributing to an existing problem. When you changed the servo-valve did you also check that the servo-current polarity was correct for each coil?

Please write back with more information, and we can probably provide more help!

I've had a look through alarm history and here is a sequence of alarms (ALM, SOE and DIA):

<S> DIA TCQA Flow Divider speed diff
<S> DIA FQLT2 voter mismatch
<T> DIA SSDIFF2 voter mismatch
<S,T> DIA FQR_INT voter mismatch
<R> DIA FQLP1 voter mismatch
<R,T> DIA SSDIFF1 voter mismatch
ALM Aux Hyd.Oil motor running
<T> DIA FSL voter mismatch
ALM L63HQ1L press low -[ON/OFF all the time till
the end of Liq.Fuel operation]
<T> DIA FSL_B voter mismatch
<T,R> DIA FQLT1,FQLT2 voter mismatch
ALM L63LF1H Liq.Fuel Oil Ftr[ON/OFF all the time
till the end of Liq.Fuel operation]

Checked prevote display at slowroll and looks like MPU3 input from <S> for FQLT1 voting is unstable. But as I understand voted signal is median of three inputs, so it will not be affected. Am I right?

Inputs from <T> of FSL and FSL_B are slightly higher (0.2-0.5) - does not seem a problem.

As you can see, all these alarms could be a result of a problem rather a cause of it. Again, at the time of Bypass valve oscillations I've seen FQROUT signal been stable.

I'll check MPU3 input from <S>, accumulators and LF filters and a coils polarity of the MOOG according to CSA's question.

That's it for now, tomorrow is another interesting day.

Dear jolek,

It's clearly now that the instability of fuel comes from S core due to mismatch signal of fql1 that connected on specified core causing an inverse reaction of command related to that core. so you should check either the gap or the pickup healthy. it should has a resistance of almost 600 ohm.

1 out of 1 members thought this post was helpful...


So, you mentioned that inputs of FSL (usually the LVDT feedback from a liquid fuel bypass valve) were within 0.2-0.5% of each other. FSL and FQLT2 are not the same. And, a small amount of mismatch is allowed before a Diagnostic Alarm is annunciated (no; we can't see what the allowable ranges are for Diagnostic Alarms). And, it's likely that any issues with liquid fuel bypass valve LVDT feedback voter mismatches were the result of instability--likely, but NOT the only possible reason.

It's really difficult to imagine how FQROUT would be stable when the liquid fuel bypass valve was unstable--REALLY difficult. We don't know what display you were viewing FQROUT on, but, yes, instability can be the result of an issue and not the cause of it. And, with servo-valve outputs it usually is the result of some issue, not the cause of it. The servo-valve outputs of the Mark V are checking the feedback and comparing it to the reference 128 times per second (even though the reference usually only changes 8 times per second) and adjusting the servo-valve output current to try to make the actual (feedback) equal to the reference.

And, FAL (the amount of current being applied to the liquid fuel bypass valve servo) is only reported to the CDB (Control Signal Database) four (4) times per second--which makes it very difficult, even with VIEW2--to see exactly how fast and how much the servo current is changing. (This is true of all servo current values--CAGV, FAG, FAGR, FAL; these values are only written to the CDB at the rate of 4 times per second.)

When you see a single value on a <I>- or GE Mark V HMI CIMPLICITY display (Main Display, or Liquid Fuel Display, or User-Defined/Demand Display) for any signal in a TMR control panel, that is the voted value of the signal. That could be the median value, or the minimum value, or the high-selected value--depending on the signal and it's criticality (as determined by GE). For liquid fuel flow divider feedback, there are usually three speed pick-ups--one connected directly to <R>, one directly connected to <S>, and one directly connected to <T>. In the Mark V, for liquid fuel flow divider feedback each processor uses it's directly-connected liquid fuel flow divider speed input to determine how much fuel is actually flowing. And, when one processor is seeing an intermittent signal and is adjusting its output accordingly, usually the other two are also adjusting their output trying to maintain stable flow.

The Pre-Vote Data Display, or in the case of servo-valve outputs AutoCalibrate Display, can be used to see with a higher degree of accuracy what the inputs/outputs of each processor are doing (control processors). And, not all signals are voted, either, so you won't always find every signal in the Pre-Vote Data Display.

Finally, if you're looking at a signal on an <I>- or GE Mark V HMI CIMPLICITY display those displays are usually only being updated at a once-per-second rate, sometimes a little faster, sometimes a little slower, but usually about once-per-second. And, if the signal is voted it's the voted value (sometimes median, sometimes minimum, sometimes high-selected)--there are no hard-and-fast rules. In the case of liquid fuel flow divider feedback where there are three values, one for each processor, each processor uses its own value--it doesn't vote them before using them. This is a departure from many other signals, but it's because this is deemed to be a critical parameter. And any fuel flow feedback value you see on a display (Main Display, or Liquid Fuel Display, or User-Defined/Demand Display) is the voted value. That's just the way it works.

Ain't the Mark V fun??? (It is, actually, but it can be frustrating at times.)

1 out of 1 members thought this post was helpful...


Please clarify something for us, you wrote:

>Can it be a wrong MOOG valve type (771GK208 is original and
>we mounted 771GK200A, the only one we have now)?

Are you saying that the servo valve on the liquid fuel bypass valve was replaced with a different servo P/N? If so, when was this replacement done? Has the liquid fuel bypass valve operated properly since the servo valve was replaced? Why was it assumed that the valve would operate properly with a different servo? A G771K208 (I believe you may have a typo in the servo P/N from your post) servo has a rated flow of 0.5 GPM, the G771K200A that you say was used to replace it is rated for 5.0 GPM. This effectively increases the flow gain by a factor of 10! It is not realistic to expect that the valve will perform the same way after such a change. The large increase in flow gain could very well be responsible for the instability you have observed.

>Any other possibilities (there are a lot, for sure)?

There are certainly other possibilities that could cause instability in the system, for instance, contamination or varnishing of the servo valve can cause a "stick-slip" situation that results in instability. However, it is highly advisable to verify that the correct servo valve is installed before spending too much time/effort on other troubleshooting steps.

Please write back to let us know what you find.

Dear jolek,

I agree with ceruty. from my recent experiences when we trying to alternate the VC3 servo which has the last three digits 208 with the SRV servo of last three digits 200, the unit suffered a highly oscillation with the fuel and feedback servo current FAL. ist thing you must use the servo if the problem still the you should check either the feedback of three pickups of flow divider. perhaps the issue in the one of the three pickups or the flow divider itself or some times there is an issue with the TCQA card of MK5.

please feedback me to see what happened with you.


My question is, what caused the site to change servos? Was there already unstable operation with the original servo?

Or was the instability caused or made worse with the new servo was installed?

First of all, I want to thank ALL of you busy guys for spending time and thinking trying to help - its not obvious at all and an exciting experience - to fill you're not a lonely warrior "fighting" a machine, but you have allies from very distant parts of this planet! :)

Now to the subject:
The unit indeed was in outage for exhaust and duct repair, and, as usual, we checked response of all servo valves prior to startup and, as often happen at our site, Liq. Byp. and Liq. Spltr valves were stuck.

From our experience, nothing helps (flushing & replacing filters) but installing a new MOOG. We had one for Splitter but not for Bypass. The only chance to run the turbine was to install a different servo. I exercised it (using DEMAND) after mounting and it moved OK.An ACALIB program is good enough to check coil polarity - all OK.
Then we primed fuel pipes, started on liquid fuel, loaded and stopped.
So, although I totally agree that proper MOOG P/N should be used, we did not have any problems caused by replacement.

The problem mentioned in the topic occurred at the next start,tree weeks after.Agree with CSA - on gas fuel all servos function smoothly, and they are fed from very same hydraulic oil system. so...
We did not run any trends/VIEWfiles - we were not hunting any problems. We'll do it next time we get a turbine for checks.

As for alarms - I will investigate logs more closely and report here (now I'm home on the couch :)).
BTW, we did synchronized with Aux. Hyd PP running with no difficulties.

I'll check accumulators, 77FD's, run the unit to FSNL and check Hyd. PP and Press. behaviour. Any other points worth checking? I'll be glad to hear you guesses, we still have a few days before we can have a turbine for execution :)

Thanks all again.

Dear Jolek,

Greetings. Thanks a lot for valued sentences.

As I mentioned on my previous comment, you said that you start and stopped the unit properly. So my opinion now is to check the analog card (TCQA) which responsible on the command of servo. I need from you to check the feedback of servo (FAL) for all three coils at prevote data display. they should be closed to zero in -ve or +ve. but if you noticed one of three read highly +ve value, this mean an issue with that analog card. and you can do a temporally solution you can open the wire of that erratic servo coil and look on the stability of voted value of ( FAL ).I'm waiting your feedback.


1 out of 1 members thought this post was helpful...


When there is a large disagreement between processor servo output currents it generally means there is either a problem with the feedback for that servo output or the polarity of the current being applied to that particular servo coil is incorrect--not a problem with the TCQA card (for a Mark V). I have seen several servo coils which had the color coded leads somehow crossed FROM THE MANUFACTURER. So, just terminating the coil leads of a new servo with the same color sequence as the old coil resulted in at least one of the coils having reverse polarity. This is why it is so important to always check servo polarity when installing a new (or refurbished) servo prior to re-starting the unit.

And, the feedback for liquid fuel bypass valves is liquid fuel flow divider feedback. And, many flow dividers used three speed pick-ups, one connected directly to <R>, one to <S> and the third to <T>. So, if one of the speed pick-up inputs is intermittent or failed or failing then that processor's servo output current will usually be higher or lower than the other two--AND there will be a Diagnostic Alarm or -Alarms to alert a conscious operator or technician of the situation. That's why I always ask, "What Process- and Diagnostic Alarms are present during the event?"

A similar situation can occur for machines with three P2 pressure transducers on gas fuel systems.

If there's a problem with a Mark V I/O card (such as the TCQA), there is almost ALWAYS one or more Diagnostic Alarms associated with that card. Diagnostic Alarms DO really mean something, even if "...they can't trip the turbine!" (as many people mistakenly believe). One Diagnostic Alarm by itself can't trip the turbine, but some combinations of Diagnostic Alarms, usually from two or more control processors, CAN trip the turbine.

But, we digress. The original poster said he had checked the servo currents and they were stable.... Difficult to understand because instability in the liquid fuel flow-rate is almost ALWAYS accompanied by instability in the liquid fuel bypass valve servo current as it tries to respond to the flow-rate instability and correct/compensate for it. So, sometimes it's difficult to understand whether it's the control system (usually NOT!) or some external factor. The Mark V (or Mark VI or Mark VIe) does NOT generally control liquid fuel supply pressure to the unit, so if there are pressure or flow problems (such as choked strainers or high filter differential pressures or air in the piping or filter vessels which restricts fuel flow and causes supply pressure instability the Mark* can't correct for that and is a "slave" to that condition. Sure, it seems the Mark* output is unstable--but it's just trying to smooth things out, things that are not under its direct control.

We don't know how old the liquid fuel flow divider is on this particular unit. The bearings of these flow dividers do wear out and require refurbishment/replacement. The gaps of the liquid fuel flow divider speed pick-ups can change over time. And, the toothed wheels of the flow divider have been known to come loose and or get bent and cause intermittent problems.

If there is an imbalance in liquid fuel bypass valve servo currents when the unit is operating at steady-state (so, for this thread at some load less than 20 MW--which is when the original poster says the instability problems begin), then it's very likely there's either a problem with the flow divider feedback or the polarity of the servo current being applied to that coil.

Personally, I think the problem is related to something with the liquid fuel supply system--choked liquid fuel forwarding pump suction strainers, or plugged fuel filters, or a problem with the liquid fuel forwarding (supply) system pressure regulator (if one is present on the liquid fuel forwarding system), or air in the filter canisters (or possible wrong valve positions for the fuel filters/strainers (transfer fill valves left open), or air in the liquid fuel supply piping (trapped at high points in the piping). Or, there is some kind of problem with the liquid fuel flow divider feedback--improper speed pick-up gap, worn bearings or loose toothed wheel(s), failed or failing speed pick-ups, etc. If there's a problem with a TCQA card there should be Diagnostic Alarms to alert that issue. (But most people ignore Diagnostic Alarms--at their own peril.)

Hope this helps!

There really is some conflicting information provided by the original poster, and without knowing what alarms are being annunciated it's even MORE difficult to understand what has happened and what's happening. Alarms (Process AND Diagnostic) are really important when troubleshooting problems. I know--people ABHOR alarms, and feel they are cryptic and can't even tell which alarm caused the turbine to trip when it does trip. But, that doesn't mean that alarms can't be a critical part of troubleshooting and understanding turbine operation. In fact, I would argue that by working through alarms as they are annunciated and explaining to everyone (operators; operations supervisors; technicians) what each alarm means and what to do when each alarm is annunciated that everyone at the plant can learn from alarms. Most plants/sites just ignore alarms as long as the unit doesn't trip, and even then, they ignore the alarms when troubleshooting why the turbine tripped if it's not immediately obvious why the turbine tripped. (We get a LOT of questions on that are basically, "My turbine tripped. Why?" And when we ask for the alarm list, we rarely get it--because the printer hasn't worked for a long time, and no one logged the alarms when the turbine tripped.

Dear CSA

Really you are a huge terrific reference and an encyclopedia.

I believe we should cancel the probability of swapping the polarization of servo coils and the speed pickup issue because the poster said he had already check the polarity and pickups. but why I suspect the issue with the TCQA card? because once in my power plant one unit suffered a fluctuation issue with the load while it was at base load and this happened suddenly and occasionally. definitely as you stated we did an investigation on the process alarms and diagnostics alarms, but we did not find any things that refer to Suspicious behavior whether of bypass feedback or fuel supply system as well as TCQA. but the situation remained although did all possibility tries until we replaced that card of infected core from that particular unit.

Do you thing this matter is coincidence?

Thanks and sincerely

1 out of 1 members thought this post was helpful...


I don't believe in coincidence. And I do NOT believe all problems are not the same, even if they appear to be.

And, I've NEVER seen a card with issues that didn't have some associated Diagnostic Alarms. Now, I haven't seen EVERY possible problem, but I have seen a lot of them. And, as we've just learned the problem is likely related to speed pick-ups. And, the original poster did NOT say that servo polarity had been checked.

It's not clear where the original poster was looking at FQROUT to see if it was stable or not, but unless it was using Pre-Vote Data Display or AutoCalibrate (which can be used WITHOUT affecting unit operation) the displayed value may not have been updating fast enough. AND, if the original poster was looking at the "median" value of FQROUT, it won't appear to be unstable if only one processor's output is unstable. Usually.

I'm not a card-swapper when it comes to troubleshooting. Why? Too often people swap cards when there's a problem (because the problem MUST BE in the Mark V, right???) and burn out a second, or even a third card before they realize the problem is OUTSIDE the Mark V panel. That's costly; very costly. Both in terms of card costs and labor costs and loss of generation/revenue.

You said you replaced the card of the "...infected core..." How did you know it was infected? Or was that determination made after swapping cards? Did you swap cards in one or two other processors before you found the "infected" card/processor?

Not all problems can be detected by Diagnostic Alarm routines--but most are. And, as we have just learned from the original poster there actually WERE Diagnostic Alarms which pointed at a feedback problem. As most instability problems are--either there are or were Diagnostic Alarms which weren't investigated, or, there is a problem with L.O. quality which causes the servo valves to fail. There's aren't really too many other problems. And, when a card does fail when there really isn't a problem in the field, then it's a rare case--or, the card is old, or there has been poor housekeeping in the control panel (dust build-up), or the air conditioning in the compartment where the control panel has not been maintained either allowing the compartment/control panel temperature to get too high, or the temperature setpoint was too low, which allowed moisture to condense in the compartment on the cards, where there was dust. Improper sealing of the cable entry to the control panel allowing moisture/condensate to enter the control panel is also a problem.

Hope this helps! All problems are not the same--especially when one gets down to the details. And, Diagnostic Alarms are truly helpful--despite popular (and mistaken) belief.

Actually, I DO NOT believe all problems ARE the same. (Sorry for the typo!)


In order to keep the good tradition of "closing a thread" by a poster who opened it, and, at the same time to thank everyone who shared his knowledge and experience with me:

As soon as we received and mounted a correct type of MOOG valve for LCV, we run a turbine successfully up to Base load on liquid fuel.
That's it, we learned a lesson and earned a bit of knowledge.
In several days we had the turbine out of service in liquid fuel, I've made few checks - Hyd.Oil Accumulators, FQLT@FQLP pick-ups and wirings, injected frequency to inputs to verify signal stability.All check results where fine except that MPU3 (which had no affect on the control system while running the unit, and we'll deal with it later).

Thanks ALL again for you help.


Thanks very much for the feedback! A servo is NOT a servo, as you have found out.

Lube oil quality is the single most contributor to servo longevity--or, said in other words, poor lube oil quality is the number one cause of servo failures. AND, refineries have improved turbine lube oils at the expense of those turbines that use lube oil as the hydraulic fluid. (It has higher lubricious and longer life as lubricating oil, but it tends to form solids much faster--which has a very negative effect on servo valve operation.)

The description in the Control Specifications about observing stroke smoothness as an indicator of servo polarity is pure nonsense. The only way to properly verify servo cure polarity is under the control of one processor at a time.

But, as you've learned even though servos appear to be the same (from the outside), they definitely are not the same on the inside. And this can have very definite impact on proper operation and stability.

Again, thanks for the feedback. And it's guaranteed if you can keep the oil clean the servos will not experience nearly as many problems.


One more thing--you mentioned that when you applied a frequency to the third mag pick-up input that nothing happened. The majority of Mark V turbine control systems which used liquid fuel had 77FD-1 connected to <R> QTBA-55 & -56 (Q_Q_MPU3--which is the third magnetic speed pick-up input to <R>), and 77FD-2 was connected to <S> QTBA-55 & -56 (the third magnetic speed pick-up input to <S>, and 77FD-3 was connected to <T> QTBA-55 & -56 (the third magnetic speed pick-up input to <T>). This configuration had a single magnetic speed pick-up input from the liquid fuel flow divider connected to each of the three control processors, and each control processor used it's dedicated liquid fuel flow divider magnetic speed pick-up input for the liquid fuel bypass control valve regulator (for the servo-valve output).

Several of us in the field felt that this lacked any redundancy--if the single liquid fuel flow divider input to any control processor was lost that control processor would think there was no liquid fuel flowing and would try to increase the liquid fuel flow-rate by decreasing (because negative servo current increases fuel flow) the servo current which would cause problems for the other servo-valve outputs.

The Mark V I/O Configurator had a type of regulator that would take the high value of two inputs and use that for the liquid fuel bypass valve regulator/servo-valve output--thus giving some redundancy. However, because there were only three speed pick-ups available it was necessary to connect 77FD-1 to <R> QTBA-55- and -56, and jumper that signal to <S> QTBA-55 & -56 and also to <T> QTBA-55 & -56. And to connect 77FD-2 to <R> QTBA-57 & -58, and jumper that signal to <S> QTBA-57 & -58, and also to <T> QTBA-57 & -58. This connects two speed pick-ups to all three control processors, and then by choosing the proper regulator in the I/O Configurator for the liquid fuel bypass valve there would be redundancy in the event one of the two speed pick-up signals would be lost to the Mark V and the unit would continue to run with a single speed pick-up until the faulty pick-up could be replaced.

I don't know how your Mark V is configured, but this might explain why there was no signal/action when you connected the frequency generator to the 77FD-3 wiring.... It's the only reason I could think of. Usually, when this alternative liquid fuel flow divider speed pick-up configuration was used it was necessary to give the two inputs unique signal names--such as FQLT1 and FQLT2. When only one input was used to each control processor the signal name was usually FQLT. You could look in IO.ASG to see how the signal names were assigned, and you could check the wiring at the three QTBA cards to see if two liquid fuel flow divider speed pick-ups are jumpered to all three control processors, and look at the I/O Configurator liquid fuel bypass valve servo regulator screen to see which regulator type was chosen.

Anyway, hope this helps! And, glad to hear the problem has been resolved.