We have Frame 6 machine with speedtronics MARKV control system. In recent past we were experiencing hunting in SRV & p2 pressure and sometimes it resulted in Load hunting also so recently we took a shutdown and did following things.

1. SRV was checked with individual core and it was found that polarity in s core was reverse which was corrected. While further checking we were getting very stable response on single coil operation with S & T but there was hunting with R core.

2. We replaced the TCQA and TCQC card in R core but hunting in servo output from R core remained the same.

3. We started the machine but SRV,P2 and load hunting worsened then prior to shutdown so we opened the servo output to SRV from R core and all became normal and we were able to raise machine to 30 mw without any load hunting.

Can anyone suggest what can be the probable cause for SRV servo current hunting from R core?

 

The most important question is: What changed before this problem started? Was there some kind of maintenance outage? Was LVDT feedback "re-calibrated"? Was there some kind of forced outage, such as from a lightning strike or severe ground? Was the SRV servo-valve replaced? Were downloads and re-boots of the Mark V processor(s) being performed prior to the start of this problem? Were Mark V cards replaced prior to this problem? Or, did this problem just appear and get worse with time?

This kind of problem is usually not caused by the Mark V (and replacing the TCQA and TCQC have basically verified that), though it could be the Mark V, and not either the TCQA or the TCQC, though those are the two "main" I/O cards associated with servo-valve outputs.

The SRV regulator on the TCQA is basically a pressure control loop with position feedback. So, can you use the Prevote Data Display to determine what P2 pressures and the LVDT feedback that is being seen by all three processors, and in particular, <R>?

It might be easier to see the two LVDT feedback signals to the three processors using the AutoCalibrate Display. (You *will not* disturb operation by using the AutoCalibrate display to view parameters when the turbine is running. You can see the LVDT feedbacks and servo currents for all three processors when the unit is running by using the AutoCalibrate Display. The targets (buttons) of the AutoCalibrate Display are disabled when the unit is running.) With <R>'s servo coil disconnected you can still see the LVDT feedback that is being seen by <R>. If <R>s coil is connected, you should be able to see the current output from <R>, also. You could do this when "stroking" the SRV while the unit was not running (make sure the gas fuel supply is isolated and bled down upstream of the SRV!!).

Have you measured the resistance of all three individual coils of the electro-hydraulic servo-valve?

Have you verified the hardware ("Berg") jumpers for SVO1 on the TCQA and TCQC of <R> are correct? (It's presumed they are correct on <S> and <T>, so the positions on <R> could be verified against those of <S> and <T>.)

What Diagnostic Alarms are present on the panel when <R>'s servo coil is connected to the panel (not necessarily when the unit is running, though that information would be helpful)?

Have you checked the wiring between <R>'s QTBA and the servo-valve for grounds and shorts? You can disconnect the wires from the servo-valve and from the QTBA and use a meggar to check the wiring and insulation resistance for any possible problems. If you have an "odd" reading, check <S> and/or <T> for similarity.

Have you confirmed the shield drain wire(s) of the interconnecting wiring between <R> QTBA and the servo-valve is(are) properly terminated throughout the entire length of the wiring? Remember: Any length of drain wire should be grounded at one end only.

Unfortunately, the servo current values are only reported to the control signal database at a very slow rate (4 Hz, as I recall), even though it can change at a 128 Hz rate (that's the execution rate of the regulator on the TCQA card) and the reference can change at the scan rate of the CSP (usually 8 Hz). So, using the VIEW tools to try to gather data can be very frustrating even though they run as fast as 32 Hz. Can you observe the servo currents on the AutoCalibrate Display for the SRV and provide some indication of what's happening to the three values, particularly <R>'s?

Can you tell us what the values of the SRV regulator gain and null bias are for <R>, <S>, and <T>? (They will all be the same and can be seen in the I/O Configurator if only one file is downloaded to all three control processors. *HOWEVER* if there are individual download files, which some Mark Vs utilized, the values can be different, though not usually.)

Another thing you could try would be to switch the servo-valve coils, say swap the wires for <R> and <T> at the JB closest to the SRV. This would isolate the problem somewhat to either the wiring for <R> or to the <R> coil. If when <R>'s coil is connected to <T> there is no instability on <T>'s output then it's likely not the <R> coil of the servo-valve.

If the problem stays with <R>'s output when <T>'s coil is connected to <R> then it's likely either the wiring or some problem with the Mark V, up to and including the QTBA and the ribbon cables connecting the QTBA and the TBQC (that's the card that has the LVDT feedbacks connected to it and has ribbon cables to <R>, <S>, and <T> to get the LVDT feedback signals to the three processors).

So, there are several things to try. Understanding if something changed prior to the start of the problem is important. It would be interesting to know how long <S>s output was reversed, but it's not critical to solving this problem.

Knowing what, if any, Diagnostic Alarms are present when <R>'s output is connected to the panel is very important.

Knowing if the problem is with the feedback(s) (P2 and LVDT position feedback) being seen by <R> is important.

Knowing if the wiring is correct and free from grounds and the shield drain wire(s) are properly grounded is important.

Knowing that the hardware jumpers are in the correct positions for all processors is important.

Knowing that the servo regulator gains and null bias current values are as expected is important.

Knowing if <R> can properly drive either other servo coil without problems is important.

They're not very common these days, but a zero-centered milli-ammeter could be inserted into the wiring for <R>'s output and monitored. Using an analog meter usually won't work very well, and using a digital meter usually doesn't work very well either.

So, try to pin the problem down to either something inside the panel or outside the panel. While there are several steps involved in checking all the possibilities outside the panel, one needs to be sure the problem is inside the panel before progressing, or that the problem is outside the panel before progressing.

Divide and conquer, by systematically and logically working through each possibility. If you start by concentrating on possibilities outside the panel, eliminate all of them before shifting your efforts to possible problems inside the panel.

This is good and proper troubleshooting, using a logical and systematic approach to isolating the problem and eliminating the possible causes until the cause is found. By understanding what had changed prior to the start of the problem, one can concentrate on factors which might have been affected by the change. But all troubleshooting is just understanding all the possible causes, using one's experience and judgment to choose a course of action, and then systematically eliminating possible causes until the cause is found and resolved.

Just remember: Good judgment comes from experience, and experience comes from bad judgment. In other words, if we learn from our mistakes we are much the wiser. Eliminating possibilities is not making mistakes; it's just working through all the possibilities until the cause is found and resolved.

 

Excellent CSA, keep it up your good work.

 

thanks a lot CSA for your detailed reply,pls find some of our observations with reference to your queries

Data as seen on Auto calibrate page
R S T
LVDT1 -1.563 -1.581 -1.552
LVDT2 -1.628 -1.638 -1.660
SOV1 0.15 1.62 -3.79

These values are with R core TCQA 27,29 disconnected as machine is on load right now so we are not allowed to re-connect wires to R core TCQA 27,29

FPG2(as seen from prevote display)
18.57 18.63 18.37

During recent shutdown we had checked coil resistance for the three cores from the panel itself and same were found to be in range of 1.15 K to 1.20 K

The SRV/Load hunting started some 8-9 months back after a shutdown when we had replaced the moog valve of SRV as we changed our fuel from liquid to gas(our Gas skid was not in use for a very long time )and at that time LVDT calibration was also done and IOCFG file was downloaded and MARKV was rebooted also.

SRV gain is 2.69 and Bias is 3.0

Berg jumpers were checked when we replaced the boards.

On prevote display I have notice a peculiar readings for TNH_OS in R core.

For R core TNH_OS fluctuates between 68.15 to 100.04 while in S & T the values are 100.01 &100.04 and do not fluctuate.
The reading of TNH in three cores is steady.

The diagnostic alarm for R core are as under 1680 (toggling 0 to 1) TCE1 HP reading ,hardware trouble,N24.
0276 ioma POWER SUPPLY OUT OF LIMITS,N24
1256 TCQA 10V on card voltage ref. trouble.

The values of FPRG_INT in R,S and T are as 34.77 ,31.83 & 36.71 respectively.

As machine is running so I am unable to do more checks as suggested by you.

Pls suggest if I could do any further checks online.
thanks.

 

Okay, so the SRV was replaced and the problem started at that time. And seems to have gotten worse over time (can you confirm or clarify that, please?).

I do think the servo-valve coil resistances are a little on the high side, about 10% too high. Most Moog servo-valves have coil resistances of approximately 1K ohms, so 1.1 or 1.2 seems a little high. What is the distance between the Mark V and the servo-valve junction box? Are there intrinsically safe barriers/zener barriers installed on these outputs or the feedbacks or anywhere on the wiring of this machine? Are you measuring the resistances at the Mark V or at the junction box closest to the servo-valve?

You didn't mention the DC supply voltages with respect to ground (if I didn't mention that before, my bad!).

But the one thing that really jumps out from the data you did provide is the TNH_OS value for <X> ("<R>")! Why is it jumping around and why isn't it being resolved? How long has this problem been going on?

You also did not provide the P2 pressure reference for the three processors, usually FPRG (Fuel Pressure Reference-Gas; implying the P2 gas pressure).

The formula for P2 pressure reference is:

FPRG = (FPKGNG * TNH) + FPKGNO

Where
FPRG is the P2 pressure reference;
FPKGNG is the P2 Pressure Reference Gain;
and,
FPKGNO is the P2 Pressure Reference Offset.

(Another y = mx + b, or f(x) = mx + b equation! They're just all over in Speedtronic turbine control systems! And the equation can be found in the CSP or the Control Specification.)

So, if the actual speed feedback is not stable, then the pressure reference won't be stable, and the servo-valve output won't be stable.

How many speed pick-ups does the turbine have? Three or six? If it's only three, then <R> probably shares the same speed pick-up with <X> of the <P> core, which is "identified" as <R> in the Prevote Data Display when looking at <P> signals (isn't this fun?). The P2 pressure reference is a function of actual turbine speed, TNH, or TNH1, for some machines. So, if <R> is having an intermittent signal then the P2 pressure reference will be going crazy and so will the output.

Diagnostic Alarms really do mean something. They're not just nuisance alarms because they don't trip the turbine, contrary to popular belief, legend, myth, tribal knowledge, or wives' tales. That one about TNH is pretty telling.

And the problem with TNH_OS may be related. Some machines, especially turbines retrofitted with Mark V turbine control systems, did not use six turbine shaft speed pick-ups. They used the existing speed pick-ups, and usually wired the <R> & <X> and the <S> & <Y> and <T> & <Z> pick-ups in parallel in three groups, or some similar scheme because a TMR Mark V requires six speed signals, but it doesn't care where they come from (three, four, or six speed pick-ups). Some packagers of GE-design heavy duty gas turbines did not use six speed pick-ups for new turbines provided with Mark Vs and did a similar thing.

So, look at the Prevote Data Display again, and get us the values for TNH (or THN1) and FPRG. That should tell us a lot.

And, what Process Alarms are active when the turbine is running?

And look into resolving those Diagnostic Alarms.

 

CSA,thanks a lot for such a detailed reply ,I have checked the FPRG value in R,S& T and is same 18.28 while that of TNH is 99.18 in all the three cores and no fluctuation observed in R core for these values.

- have three speed pickups only.

- have noticed TNH_OS fluctuations in R core recently ,I really don't know since when same is happening.I think this could be resolved by replacing TCEA board of R core.Can it some how affect the servo current from R core.

- The resistance of servo coils was checked from MARKV panel itself and includes cable as well as coil resistance.The distance of cable is @400 mtrs

- We are not using any barrier in output as well as in feedback.

- As far checking voltages is concerned that we will do as and when opportunity is given to us.

thanks

 

Please, list all the Process Alarms which are being annunciated (including any which might be Locked). And all the Diagnostic Alarms.

Even if you think they might be relevant.

If there are only three speed pick-ups, it's likely the same one that's connected to <R>'s QTBA is also connected (jumpered) to "<R>'s" TCEA (<X>) at <P> PTBA-1 & -2. If <X> is having problems seeing the speed signal, it's likely that <R> is as well.

And if <R> is having a problem seeing it's speed, then <R>'s SRV servo current will not be stable either.

You can use a digital meter that measures frequency to check the inputs at <R> QTBA-51 &-52 and <P> PTBA-1 and -2 when the unit is running without tripping the turbine.

So, before you replace the TCEA, make sure it's not a speed signal problem. Could be loose crimps or loose screws on the QTBA and/or the PTBA! I'm not a fan of swapping cards only to fail another card if there's a problem with the circuit outside the panel.

You can even check the DC input voltage with respect to ground when the unit is running without tripping the turbine. (<PD> PTB-2 with respect to ground, and PTB-3 with respect to ground.)

You can use VIEWPV to monitor TNH1, TNH, FPRG, and FPG2 in <R>, and maybe TNH_OS (but that's a guess) at 32 Hz and see what the signals are doing. Again, looking at FAGR will only show a change every 1/4 second even though it can change as fast as 128 Hz. And with nothing connected to <R>'s SRV output, that wouldn't reveal anything.

If you were really bored you could use a reasonable 1K ohm resistor connected to <R>s servo-valve output in place of the servo and try to monitor current with one of the view tools; 1/4-second accuracy is better than none.

Lastly, 400 metres of cable is a LOT of cable. I think that is stretching the limits of what GE recommended. It could be that the extra resistance is just straining the servo-valve output power supply. And, perhaps those Diagnostic Alarms on power supply problems are trying to indicate that.

Good luck! Let us know what you find.

 

Thanks CSA,
We forgot to update the status for one of the issue which we raised wayback, really sorry for keeping the issue open for so long. We would like to share that we were able to locate the problem of SRV hunting to intermittent dip in P2 pressure of R core due to faulty terminal of one of three transmitter in field JB at Gas skid.

After rectifying we experienced no MW/SRV dips.

Regards,