MKV IDOS on a Frame 6B - IGVs which had previously been working went into position trip on Start-up. This initially looked like a typical Servo or LVDT failure. On arriving at the machine, AUTOCAL worked perfectly and IGVs positioned accurately both in Calibrate or Manual calibration. But here is the problem, immediately the IGVs were moved, L86GVA & L86GVT (position alarm & trip) operated. After much head scratching, a real time plot was made of CSGV & CSRGV and it was found that, although the IGVs would position correctly, CSRGV was not moving and remained at the closed stop of 34 Deg. Nice, the IGVs move but the Reference doesn't move??, of course this is the reason for the alarm and trip.

A bit of history - Two weeks ago the TCQA in <R> was replaced due to a failure and everything has worked perfectly since then with a few, trouble free, starts. Could this possibly be ribbon cable problem between DCC and TCQA or in the DENET ?? This a bit of a strange one and a first for me after many years. Of course the CSRGV reference is getting to R+S+T or the IGVs wouldn't move but it doesn't seem to be getting to the section of CSP that checks position Alarm & Trips ??.

The machine is now running and was started with L86GVT forced. Of the course the fault didn't appear on start-up, Murphy's Law never fails. I plan to bring the machine down in a few days and take <R> to bits and put it back together again.

Any other good ideas would be much appreciated.

(A prize should be given for the correct answer)

 

Hi Bob,

Interesting problem?

Software/MKV:
I assume that the jumpers on the TCQA cards are set as per spec. Did you check the status of the cards from the LCC/DCC display? How about diagnostic alarms? Faulty ribbon cables and any other communication problems between the LCC/DCC and the IO usually revealed by diagnostic alarms.

Normally, if there is a problem with the analog cards in any of the processors, you will be not able the start the GT after a trip or stop. Do you have this problem also if you will modulate the IGV without the <R> processor?

Did you check the CSRGV values from the pre-vote data display during calibration? What does it shows? Are these analog values frozen in the BBL's and calibration screen?

I suspect that this problem is related with the servo valve. Did you replace the servo with new from the OEM or refurbished from the third parties?

You may also consult the other Bob O

Note: Check whether the autocalib sequence is not interfering with the operational sequence. Ensure that the autocalib selection is not active!

Re-download the PROM software.

Good Luck,

Tempus Fugit...

 

Ali,

Good question about the status of I/O cards, because an I/O card can be at A7 and then go to another status, and the processor can remain at A7.

If any of the processors was not at A7, then the unit could not have been started. However, after a START in is progress, if a processor is less than A7 the start can continue.

Excellent question about the Diagnostic Alarms. It would be very helpful to know what Diagnostic Alarms are annunciated when the unit is running prior to the L86GVA and L86GVT alarms. It would also be helpful to know what Diag. Alarms are present when stroking the IGVs.

Good question about the Prevote Data Display values of CSRGV. I think that trends use information from the Designated Voter, which should be <R> if all three processors are running and healthy and all the cards are at A7. Once a unit is started, any single control processor can go to an I/O status of less than A7 and the turbine can continue to start/run.

Good question about the hardware (Berg) jumper positions.

The originator has said that he can stroke the IGVs, and when that's done it's done without CSRGV. If a User Defined (Demand) Display is used, then it's GSADJ that's passed to the SVO output. If AutoCalibrate is used then it's the signals from AutoCalibrate that are passed to the servo.

For a Process Alarm to be annunciated two of the three control processors must see the same alarm condition, if all three processors are running and healthy (at A7). I don't have a lot of experience about what would happen if one control processor was not at A7.

I haven't had a chance to look at a Mark V CSP to see what drives the L86GVA and L86GVT alarms. I can't think of a reason why CSRGV would not increase on two of three processors. So, if the alarm/trip are driven by the difference between CSRGV and CSGV it's not clear how CSGV could be changing unless the IGVs were moving before they were supposed to be moving (before CSRGV was moving).

I would also like to know if the IGVs were moving when they should have been moving when the alarm/trip was annunciated. In my recollection, the IGVs should stay closed until the unit reaches about 80 DGA, plus or minus a couple of degrees. And then they should modulate to the minimum operating angle, which is about 57 DGA, if I recall correctly. So, when did the IGVs move when the alarm/trip was generated?

All three control processors should calculate the same CSRGV when all three control processors are healthy. If one control processor was not at A7 (outputs enabled), it would not be outputting any servo current. I don't know if the output would be shorted or at max pos saturation (close reference). I believe that if the IGV output is connected to SVO5-8 then it can't be driven negative on a by a TCQA hardware relay.

I don't believe that CSRGV is "voted"; I think it's calculated independently in every control processor. If there are any inputs used in the positioning of the IGVs below rated speed (and I don't think there are; I think it's just Control Constants for minimum and minimum operating positions), then I can't understand how CSRGV would be different and how at least two processors were seeing movement before there should have been movement.

So, this is just a very strange problem; very strange, indeed.

Very strange.

I would like to know if the polarity of the servo currents being applied to the servo valve are correct for all three coils. This might be a combination of problems, not a single one. Such as a failure of one control processor during starting and a servo current polarity problem of another processor.

I would also like to know what the servo currents are right now for all three processors with the unit running at steady-state condition.

 

Dear Bob Johnston,

Did the IGV problem solve? If yes, HOW?? we are waiting to know more.

G.Rajesh