We have Frame-6 GT M-IV controlled. Our <R>,<S>,<T>, IGV opening feedbacks are 71%, 83%,85% resp. In field local position shows 71%. Because of S & T processor final IGV feedback is 83% i.e full open condition. As a result we there is GT load limitation. We get only 22 MW against rated 30 MW. Can the problem be solved in GT running condition or Shutdown is must?

 

WOW!

As always with something like this: <b>When did this problem begin? After a maintenance outage? After an LVDT or servo replacement?</b>

The Mark IV handles LVDTs differently than later versions of Speedtronic panels. One processor looks at one of the two LVDT feedback signals and uses that one value in its determination of position and servo-valve output current.

A second processor uses the second of the two LVDT feedbacks and uses that single value in its determinations.

The third processor uses the high-selected value of the two LVDT feedbacks and uses that values in it's determination of position and servo-valve output current.

Which processor uses which LVDT values is done by the positions of hardware ("Berg") jumpers on the HSAA cards. And, it's not the same for every device with LVDTs, so one has to look at the Speedtronic elementary to make the proper determinations for each servo-operated device with LVDT feedback.

I suspect more than one problem at your site, and it will require a shutdown to investigate and resolve the problem(s).

I also suspect there are several Process- and Diagnostic Alarms related to this problem that you haven't told us about.

You haven't told us what the IGV reference is, usually signal name CSRGV (Control Stroke Reference, Guide Vanes). If you have Base Load Selected and the command is active, then the IGV angle should be approximately 84 DGA (or thereabouts), and if the IGVs are physically at 71 DGA then something(s) is(are) definitely amiss.

I would suspect incorrect servo current polarity on one servo coil and possibly an LVDT problem, maybe something as simple as a loose LVDT core jam nut. There may be a Mark IV card problem, but unless we know what Diagnostic Alarms are present it's difficult to say.

But, investigating <b>and resolving</b> this will require a shutdown; no question.

Please write back to let us know what you found.

 

> WOW!

> As always with something like this: ><b>When did this problem begin? After a
> maintenance outage? After an LVDT or servo replacement?</b>

----- snip -----

> You haven't told us what the IGV reference is, usually signal name CSRGV
> But, investigating <b>and resolving</b> this will require a shutdown; no question.

> Please write back to let us know what you found.

Thank u sir. I will write more afterwards

 

Thank You Sir,

Our Gas Turbine is still in operation and we have not taken S/D till today.

One more problem has occurred. One night suddenly Master Protective startup lockout alarm appeared along with number of diagnostic <R> processor alarms (@ 20). Our I/M dept told it's a failure of <R> processor.

But since then we have found our FSR has increased. At @ 24 Mw it used to 50~55 % which has increased to 70 % as same load.Also after this once when we reduced GT load to 12 MW IGV opening found 48 % and exhaust temp 560 Deg.C.

 

Your I/M dept is correct; <R> processor decided that the turbine should have been tripped. The best way to determine what caused that would have been to use the Auxiliary Display to view the Process Alarm drop numbers in <R> to find the condition that caused <R> to want to trip the turbine.

The Diagnostic Alarm printout could also be used for that purpose as in many cases there will be a Voting Mismatch Diagnostic Alarm for at least one value that will cause a turbine trip.

So, without knowing a lot more information, it's virtually impossible to make any more comment about that condition.

When a Speedtronic has as many problems as you are describing, there are bound to be some operating discrepancies.

Please don't ignore Diagnostic Alarms; they can be very telling about problems in a panel. Most people, and yourself included it seems, don't bother with Diagnostic Alarms because they are just "nuisance" alarms and don't trip the turbine. Ignoring Diagnostic Alarms can cause troubleshooting to take a lot longer than it should.

I'll admit the Diagnostic Alarm messages can be cryptic, and don't immediately or intuitively convey the problem. But, with a little research and "sleuthing" one can usually discern a lot of information from Diagnostic Alarms.

And, to a certain extent, Process Alarms can do provide similar information.

There is a lot of information you were asked to provide in an earlier post. Failure to provide all of that information will result in a failure to respond to your posts. Granted, each piece of information requested wasn't in the form of a direct question, but the implication was that the information would be necessary.