6B SRV hunting on start up

We have a GE 6B dual fuel CT with MARKV controls that on start up our P2 pressure is hunting to extremes. Varies from 80 psi to 200, with continual hunting of the valve.
We have calibrated (checked the 3 P2 transmitters), replaced the filter on the SRV, changed the servo and checked polarity. What I would like is some input on which points I should trend on a start up to pinpoint our issue.
 
6Bturbinetech,

What Diagnostic Alarms are present (and possibly dithering (toggling quickly)) while this problem is occurring? (Please list ALL Diagnostic Alarms, even if you believe they are irrelevant.)

What Process Alarms are present (and possibly dithering (toggling quickly)) while this problem is occurring? (Please list ALL Process Alarms, even if you believe they are irrelevant.)

P2 pressure is a function of HP speed. FPRG=(TNH*FPKGNG)+FPKGNO

where: FPRG - Fuel Pressure Reference-Gas (in psig)
TNH - Turbine Speed-High Pressure Shaft (in pct)
FPKGNG - P2 Pressure Reference-Gain (in psig/pct speed)
FPKGNO - P2 Pressure Reference-Offset (in psig)



So, it's important to know if the HP speed signals are good and stable.

If you've replaced the servo valve and the problem continues, it could be a problem with the SRV hydraulic actuator. If the piston seals/o-rings are leaking, that could be a problem. There have also been MANY problems caused by the seal where the valve shaft passes through the assembly which results in scoring of the shaft and damage to the shaft, which have caused many problems. I have even seen two bent valve stems (don't know how they got bent, but they were definitely bent).

It's very misunderstood but the SRV regulator (the function that drives the output to the valve) is a pressure regulator with position feedback. That is--the SRV's PRIMARY function is to move to whatever position is required to achieve and maintain the P2 pressure reference. And, as an "added feature" for stability, the SRV has two (sometimes only one) LVDT that is used for an outer loop on the regulator. So, if the LVDT feedback is bad or failing or intermittent this can cause problems, though it's almost always accompanied by Diagnostic Alarms, sometimes dithering (toggling on and off quickly) but sometimes constant. So, failed or failing LVDTs (not usually both at the same time, but just one) can cause a problem--because the Mark V does a HIGH SELect of the two LVDT feedbacks, so if the output from one LVDT is unstable or failed or failing intermittently then this can cause problems. This can sometimes be difficult to spot if manually stroking the SRV using AutoCalibrate.

If the problem is the actuator or the LVDTs, one way to troubleshoot the problem would be to use the Manual positioning feature of AutoCalibrate to stroke the actuator slowly (by slowly changing the Manual Position reference value, and having someone (with a radio) watching the valve and reporting if there is any sluggishness or sticking operation or other unexpected operation.

There are also the 'Verify Position' and 'Verify Current' features of AutoCalibrate which can be useful when troubleshooting problems like this. There IS a caveat here when using these features: You need to perform an AutoCalibrate of the LVDTs of the device that is having the problem before these will work. This is important to know and understand. Because if one (or both) of the LVDTs is failed or failing this can cause problems with the AutoCalibration, which can lead to other problems. So, if you use either of these you need to perform an AutoCalibration of the SRV (in this case) immediately prior to actually using them in order for them to work properly. SO, that means you MUST make a back-up of some sort of the 0% and 100% stroke voltage values in the I/O Configurator for the SRV (usually SVO1 (Servo-Valve Output 1)), whether you write those numbers down or make a copy of the screen/display using the printer or your smarter-than-me phone's camera, you want to make sure you have those values just in case. Let's say you decide to use either of the 'Verify' functions (which are explained in the Mark V Maintenance Manual, GEH-5980, I believe--but it might be in the Mark V Application Manual, GEH-6195 (I can't remember anymore--it's been a LONG time)) and you isolate the fuel gas supply to the SRV, and vent off the pressure between the isolation valve and the SRV and then perform an AutoCalibration of the SRV and you get all manner of warning/error messages from AutoCalibrate (in the bottom of the screen there is usually a small status window where any warning or error messages are displayed), and things just don't work when you try to manually stroke the SRV or you try to run the 'Verify' tools. All you need to do is just re-boot the three control processors (<R>, <S> and <T>) ONE AT A TIME and that will copy the 0% and 100% stroke voltage values from EEPROM back into TCQA RAM for the SRV and you'll be "back in business." AND, you'll likely also know that there is some kind of problem with one or more of the LVDTs or the LVDT excitation or the LVDT feedback, or wiring, or something like that.

I have also seen the intervalve vent valve, 20VG-1 cause problems like this--when it was intermittently opening and closing. There is no limit switch on the valve, so one can't monitor position, but it is a solenoid-operated valve (usually an ASCO Red Hat valve) and they do go bad from time to time (the coils as well as the valve mechanism). The valve is supposed be Normally Open (Fail Open, as some like to say), and energized by the Mark V to close. There could be a loose terminal somewhere, or, a failing solenoid coil, or even the electro-mechanical relay on the relay board in the <QD1> core could be failed or failing, or a problem with the ribbon cable, or the DTBC or DTBD board.

I am presuming the GCV is stable during firing, warm-up and acceleration (signal FSG). I'm also presuming the gas fuel supply pressure is relatively stable during firing, warm-up and acceleration (sometimes signal FPG1, or FPG3)--sometimes when the SRV is a little unstable the gas fuel supply pressure starts oscillating and then the two start really oscillating and this may be a problem with gas fuel supply pressure regulator.

That's about all I can think of. You can put the SRV servo current into the VIEW file, usually signal name FAGR, but remember that the servo current's change at the rate of 128 times per second and the values of servo current only get written into the SDB (Control Signal DataBase) at the rate of 8 times per second (if I recall correctly), so it may look like the servo currents are relatively stable, but they may not actually be very stable--and that's just because of the way the signals are written to the SDB.

Please write back to let us know what you find. If you decide to use the 'Verify' features and you get a successful SRV LVDT calibration in preparation for using them, one of them changes the position reference at a constant rate and plots the servo current required to keep the actual position changing at that constant rate. So, if you see spikes or dips along the way up or the way down, that is likely an indication that something is wrong with the actuator or the servo (I know you said you replaced the servo and/or filter, but, dirt still has a way of being disturbed when changing servos/filters and runining new servos...). The other 'Verify' function puts out a constant current and plots the actual position. If the servo and/or actuator are working correctly and the LVDT feedbacks are also good the plots will be smooth, BUT if the LVDT feedback is unstable or intermittent as the device is moving the plots will have spikes/dips during opening and/or closing. The 'Verify' tools are VERY misunderstood and very unused, but very powerful. When you're done with the 'Verify' tools all you have to do to return the previous 0% and 100% stroke voltage values is to re-boot the control processors one at a time.

[Whenever one does an AutoCalibrate, the 0% and 100% stroke voltages in the upper part of the AutoCalibrate display will change, even if it's only just a little bit. So, it's a good idea to write down the as-found values of 0% and 100% stroke voltages BEFORE you begin the AutoCalibration, and then AFTER you complete the AutoCalibration, and compare them to see how much they might have changed. Interesting stuff for controls nerds...!]

Hope this helps--and, again, please write back to let us know how you fare in resolving this problem!
 
TNH (or TNH1)
TNH_OS
FPRG
FPG2
FPG1
FPG3
FAGR
FAG
FSGR
FSG
L20VG1
L20VG1X

Those are typical Mark* v CDB signal names. Your mileage may vary. ;-)

But, sometimes, it's a loose connection or a bad crimp, or a something OTHER than the Mark* V or the device, or the LVDT(s), or 20VG-1.

Also, there have been multiple times when the y-strainer ahead of the SRV has been so clogged that very little flow can get through it, and that makes holding a specific P2 pressure difficult.

When you get some VIEW2 data, post a file here so we can have a look.
 
TNH (or TNH1)
TNH_OS
FPRG
FPG2
FPG1
FPG3
FAGR
FAG
FSGR
FSG
L20VG1
L20VG1X

Those are typical Mark* v CDB signal names. Your mileage may vary. ;-)

But, sometimes, it's a loose connection or a bad crimp, or a something OTHER than the Mark* V or the device, or the LVDT(s), or 20VG-1.

Also, there have been multiple times when the y-strainer ahead of the SRV has been so clogged that very little flow can get through it, and that makes holding a specific P2 pressure difficult.

When you get some VIEW2 data, post a file here so we can have a look.
We are a peaking site and run infrequently. I have trends and view2's built. I will post data after our next run.
 
6BTurbineTech,

Thanks for the update. We were wondering.
Here is what I have for Diagnostic alarms
Voter mismatch <R> FPRG_INT
Voter Mismatch <T> FPRG_INT
Voter Mismatch <R> FSGR_B
Voter Mismatch <T> FSGR_B
Voter Mismatch <R> FSGR
Voter Mismatch <T> FSGR
Voter Mismatch <R> FP2LATCH
Voter Mismatch <S> Q_C_MAO04
Voter Mismatch >R> Q_C_MAO04

Trended my speed signals and the did not waver at all. I printed the trend I ran and can attach.
 
Here is what I have for Diagnostic alarms
Voter mismatch <R> FPRG_INT
Voter Mismatch <T> FPRG_INT
Voter Mismatch <R> FSGR_B
Voter Mismatch <T> FSGR_B
Voter Mismatch <R> FSGR
Voter Mismatch <T> FSGR
Voter Mismatch <R> FP2LATCH
Voter Mismatch <S> Q_C_MAO04
Voter Mismatch >R> Q_C_MAO04

Trended my speed signals and the did not waver at all. I printed the trend I ran and can attach.
Okay

Did you have read on OEM manual??
If yes what did you learn from this Diagnostic alarms?

Is FPRG_INT means that "Pressure actual value" is not following "Pressure reference"
The alarms is only shown on <R><T>...What about <S>
The other Q_C_MAO04 alarms may be related to DWATT transduceurs or other Intsrumentation I/O...

For FP2LATCH & FSGR i cannot state as i dont have OEM right manual..

Correct me if I am wrong ..

ControlsGuy25.
In your
 
ControlsGuy25,

You guess a lot. A LOT.

If you don't know, don't post or say you don't know when you post. It's much more professional and better.

Your research is very good, but--again, if you don't know say so. It's great to try to help as many posters as possible but it should be relevant, concise and detailed when necessary (which is pretty often lately).

Relevant. Concise. Detailed when necessary.

If you don't know, don't post or say so when you post and be brief. Offer suggestions for including more information so others may possibly add their knowledge.

Posting, for postings sake, is not helpful.
 
ControlsGuy25,

You guess a lot. A LOT.

If you don't know, don't post or say you don't know when you post. It's much more professional and better.

Your research is very good, but--again, if you don't know say so. It's great to try to help as many posters as possible but it should be relevant, concise and detailed when necessary (which is pretty often lately).

Relevant. Concise. Detailed when necessary.

If you don't know, don't post or say so when you post and be brief. Offer suggestions for including more information so others may possibly add their knowledge.

Posting, for postings sake, is not helpful.
Csa,

I am here to learn and share with people as best as i can .. ...

The thing is that I know the definitions and purposes of these diag alarms... , I wanted original poster to clarify some points...Some people doing that here and nobody tell them anything about it....

It is like open discussion...so we can discuss and then find solution ...

So you clearly incorrect by saying that " you guess a lot a lot"!!!

I can return this: " you writing a lot a lot without knowing anything...."

Since I came on this forum , I helped supported a lot o f people!!!

Even site issues have been resolved hence of my efforts!!!

So please do not say that "Posting, for postings sake, is not helpful. "That is not my goal here again!!

People here are doing things worst than that.....

They even now insulting us on a post by making jokes on the avatar......( thats another story but i will take care of it no problem .. I am better than him at this game!)

And nobody here react about it!!!

That's funny & not satonish me how people behavior can switch as fast as a Thunder lightning!!!!

BTW i don't take it personnaly , cause i know & I trust on my skills and competences , values in this world...

I am sure and I see that people are happy with my replies /support...So your comments have no place to be..

Again I take these comments as a misunderstood & misinterpretation from your part...

I know that saying "i dont know is not professionnal" but if you read clearly my post I didnt say "i dont know..." I said " i cannot state as i dont have OEM right manual.. " which is very different meaning.....and more professionnal !

Writing, for writing without asking /knowing why...is not professionnal at all

I know that you tried to advise me on that... so I dont take it bad..The thing is that after some times here, I know how misunderstanding & misinterpretation can be through forum communication ...!


Controls Guy25.
 
Another thing to add:

Do you think i come to this post by just sayin "I don't know"...
I am not so stupid to do such thing!

There are stupid people, on this world and this wonderful forum, specially like the one who is doing bad joke on Avatar..
I am not one of these stupid people ..

Also you could use PM as you did before for clarifying some points that you don't understand or misunderstand or if there is misinterpretation of my post..

BTW I see that you did'nt use PM ( which can be useful for clarifications) ...

ControlsGuy25.
 
ControlsGuy25,

PM is for wusses. Full stop. Period.

You DON'T KNOW what the Diagnostic Alarms are. Full stop. Period.

You are guessing. Full stop. Period.

Stop guessing. Full stop. Period.

Your initiative and drive is to be commended. But, you need to "stay in your lane." (In other words, if you don't know, stay out of the thread--or say so when you post (that you don't know).)

6Bturbinetech,

From the Diagnostic Alarms, it's very likely that the P2 pressure transducers (96FG-2A, -2B & -2C) are not properly calibrated, or not proper valved in. AND, it appears that one of the SRV LVDTs is not reading properly--at least in two of the processors.

The Gulton-Statham (Ametek) pressure transducers were known to drift--a lot. They cannot be calibrated on a bench while disconnected from the Mark V--they MUST be calibrated whilst connected to the Mark V with Mark V loop power. If the Mark V was a retrofit of an earlier Mark* turbine control system and the unit is using 4-wire trandsucers (usually with a 0-5 VDC output) it is still just as critical to use the Mark V loop power when calibrating the transducers.

It's also possible that one of the TCQA cards is having problems--which I can't say from the information provided. You might try replacing one of them at a time to see if the problem goes away. ALSO, sometimes the TCQC cards come into play in this circuit--so you might try swapping them out or moving them to a different processor to see if one of them is causing the problem.

If the ribbon cables in the Mark V haven't been properly coated with conductive grease recently, this could be part of the problem. Sometimes, just unseating and re-seating the ribbon cables in their connectors will also help (by removing/reducing the corrosion on the pins/receptacles).

But, it's nothing with the software--it's something hardware-related.
Csa,

By saying "PM is for wusses." you admit that you are a "wusse", so you speaking about you ...

How can you state that I do not know diag alarms...that's just a poor and without any argumentation.....
Again I am far away about what you wrote fortunately !

I knew that you will write some thing like this one day! I have more experience with people behavior than you think !

Stay out of my comments and post and leave me doing what I do and I do it well here!

You said that you have to retire well I see why ! You should get you retirement as you seems to be very tired and confused because of new people are coming here and doing good job!

BTW I am happy and satisfied to meet great people here, and share, even work with them...

Another thing parallel to this:
In fact I knew that you have a teeth against Belfort and now when you know that I worked with Belfort , you just trying to add more bad comments on my posts ....You could use PM but you are a " wusse" nothing more to add Basta!

So I never took it personnaly...

You want it or not Belfort sold many of units installed in the world even in USA....And they do better work that you guess & statements on their work...
And i am happy with that since I can meet and work with multi disciplinary people around the world!

Keep cool relax yourself & enjoy the time as we gonna all pass the way one day!


ControlsGuy25.
 
Top