We received the following two alarms:
D_3663_C Voter mismatch <S> Q_S_FDBK10
D_3656_C Voter mismatch <S> Q_S_POS19
Troubleshooting 101, what did you touch last? 24 hours prior to this alarm showing up, we had a contractor test our Chemtron CO2 system. They simulated all alarms, did a puff test, and tested other various things. This should have not caused the above issue, but this was the only thing that was touched on the system before the alarm came up.
After looking into the two alarms, I realized they stemmed from Regulator #10 on <S> Core from the TBQC card. When I opened up the prevote screen, under the signal names: Q_S_FDBK10 and Q_S_POS19, I noticed <R> Core was around -10 , <T> Core was around -10, and <S> Core was saturated at 128. Since we do not use regulators 9 through 12, nor have any signals terminate on that card in those positions, we ignored the alarms for a bit since we were in a week outage and had more pressing issues.
Our control system is a Mark V TMR.
On <S> Core, TBQC goes to TCQF for regulators #9 - #12. We do not use these.
On <R> Core, TBQC goes to TCQA for regulators #1 - #8. Standard for the gas valves.
The issue never really became a problem until the end of the week when we went to go auto calibrate the gas valves prior to introducing gas back into the system. The secondary gas valve, Regulator #6 Type 43, that terminates on <R> Core TBQC and goes to TCQA was having issues. It would not calibrate and I would get the following fault message:
"NOT REACH 50% TOWARD + SAT. WITHIN 5 SEC."
I had another worker go out to the valve to visually monitor the valve as I stroked it manually to various positions. I was able to stroke the valve at all positions at the required measurements.
Earlier this year we replaced the moog servo regulators and verified the stroke measurements by using a dial indicator. They all checked out just fine. Every year we measured the stroke and in my three years, we never had to adjust and the measurements were always just about spot on. We had atleast 100 runs, if not more, with the new moogs installed and never had an issue.
Below is a list of what I have tried already:
1. Took voltage readings on <S> TBQC Terminal 5 + 6 and had -2.4VDC and -2VDC. Again, nothing is terminated on this. This appeared to be rail voltage of an OP Amp and I thought that may be backfeeding from the terminal card to the board. I disconnected the ribbon cable (JFS) from <S> TBQC that goes to TCQF. That seemed to make the -10 values on <T> and <R> and they went to -25 but <S> core still was at 128 for POS19 on the prevote screen. With that said, it kind of proved to me that the issue lies within a terminal card, possibly the circuitry has a short in it.
2. I removed the ribbon cable (JUUS) from <S> TBQG that runs to TCQF. No change.
3. I removed 3PL from TCQF and <S> Core. No Change.
4. Replaced TBQC on <S> Core, no change.
5. Checked LVDT excitation voltage on all valves on QTBA <R> Core, all LVDTs metered around 7 VRMS. As we stroked the valve, we also metered the excitation voltage and no drop.
6. We disconnected each cores servo output from each respective QTBA card for regulator #6 and stroked the valve to all positions by ONLY using one core. Each core was able to fully stroke the valve without issues. This proved that servo current is good for each of <R> and <S> and <T>.
7. We had reconnected <R> and <T> servo outputs on QTBA and tried to perform an auto calibrate and we would still have <R> and <R> fail on auto calibrate.
8. We hooked up three multimeters in series with each cores QTBA servo output on the secondary valve and monitored current. Tested good.
9. I replaced TCQF on <S> core but our reconditioned TCQF card was defective. I had to swap back to the old TCQF card and a new one is on order.
10. I had another worker physically look at the valve as it went into all of its position and again, no issues. It was able to travel just fine. That ruled out any stop block issues, current issues, wiring issues, ect. I do not believe this valve has any physical issues.
11. Through I/O Configuration, I disabled regulator #10 on TCQF card, downloaded, and I was able to cure the 128 saturation issue, but the valve still had the same auto calibration issues. So this step proved to me that these two issues, voter mismatch and secondary valve not calibrating, are not related.
The only thing left on the list that I may do is change the TCQA card. I just cannot prove that this cards is the issue. There are no other signs that lead me to it. I would think that if TCQA had a problem I would get another alarm specifically for the secondary gas valve. But again, I get NO OTHER ALARAMS but the two I listed at the start of this.
Does auto calibrate use another set of reference setpoints vs. what I would enter for a manual setpoint?
I have a hard time believing that the secondary gas valve calibration issue is tied to the regulator 10 alarm issue but it is a Mark V so I am not throwing anything out. Has anyone has issues similar to this that could shed some light? I have spent more than two days trying to figure this out.
If only ... we always received such detailed descriptions of precisely what troubleshooting was done AND what the results were. (And if wishes were nickels I'd be a very wealthy man.)
But, alas, I digress.
It's always been my understanding that the AuotCalibrate function was contained in firmware on the TCQA card, and that the HMI screens were just a window into the TCQA RAM and a means to enable and use and disable the functions of the AutoCalibrate firmware on the TCQA card.
SO, it would seem you have exhausted the possibilities other than the TCQA card, leaving replacing the TCQA card as just about the last thing to do. I say "just about the last thing to do" because I would not discount the TCQC card yet.
I'm going to digress again and go to my usual rant about performing AutoCalibrations on a periodic basis. In your case, you seem to be fairly confident that the actual valve travel hasn't (and doesn't) change over time. So, since LVDT feedback calibration is NO DIFFERENT from verifying the as-found calibration of any switch or transmitter if you can physically stroke the valve and obtain results similar to, if not the same as, the previous calibration (or verification) then just note the as-found condition was within tolerance and move on to the next verification.
I know, you are being diligent and trying to resolve a problem that could cause future difficulties now--which is what any conscientious technician should do. Good on you for that.
The last thing i will add is that it would appear that <S> is not receiving feedback from the TCQC card in a timely manner. I have recently been to a couple of Mark V sites that had corrosion on the ribbon cable pins and/or receptacles that caused nuisance and intermittent problems. The grease supplied with spare or refurbished cards should always be used when replacing cards, and should also be replenished on a regular basis for ALL Mark V ribbon cables--at least every two years. In my personal opinion it's more important than any other periodic maintenance activity--especially as Mark V panels age. (Certainly more important than running unnecessary AutoCalibrations every maintenance outage.)
Hope this helps. I understand that maintenance"procedures" are cast in stone at some plants, but the best-run plants with the highest and best reliability and availability regularly review their procedures (maintenance and operations) to find efficiencies and to refine and improve them.
Please write back to let us know what you discover and how you resolve the problem.
One more thing, many years ago i was troubleshooting a similar issue at a plant on one of two GE-design Frame 6B heavy duty gas turbines and resolved the problem by replacing a card in a different processor than the original problem had manifested itself in. The best way i could justify it wad that the card in the other processor (which also received the same signal as the processor with the problem) was "dragging down" the signal but only one of the three control processors was detecting the low signal. Cable issues, or component tolerances--who knows in the end. But, the Customer was VERY happy--as was GE, because the problem was a warranty issues and I had spent a lot of time troubleshooting the problem--with support from the factory and we had been unable to solve the problem. You might consider swapping the TCQC cards of <S> with either <R> or <T> to see if the problem switches processors (and I'm presuming the ribbon cables--at/connectors are not coming corroded).
I appreciate the quick feedback. I try to research the best I can prior to posting. The MarkV Application/Maint GEH can only get you so far and after spending countless hours reading on Control.com about auto calibration on my iPhone in the PEECC with terrible service, it was finally time to post my own message. I do sense a trend after reading so many posts on Control.com , most people are brief with their issues as well as do nothing prior in terms of troubleshooting on their own. They are to quick to ask for help... I figured, the more information I can provide, the more willing someone may be to help. Anyways...
I was called in today since our new TCQF board shipped in. After that board was replaced on <S> core, it did fix the original mismatch problem. Regulator #10 on <S> TBQC POS19 and FDBK10 both went back to -25, -25, -25. Problem 1 solved.
I didn't have much time to spend at the plant but I did spend time once again, taking measurements on the secondary gas valve at various positions and at 100%, it measured .720". Right on the money from May of this year. I opened up the wiring box on the valve, checked each and every connection. - A-OK.
I manually stroked the valve again at various positions, went from 0 to 100 and back to 0 as fast as I could to try and simulate the auto calibration speed. It worked just fine.
I did set up my iPhone and captured a video of the valve during an auto calibration. I wanted to watch it in slow motion to see if I missed anything. What I saw was exactly what I was seeing on the valve calibration screen. The valve goes to its full open position and hits the stop block at .720", stays there, and then drops right down to 0.
That confirmed what I was seeing on the HMI.
I should have just replaced the TCQA card today, however, it is difficult to use a 5,000 dollar card when it really isn't an issue nor have any "alarms/faults/diagnostics" displayed to warm me, i should have, I just couldn't convince myself. It is just so odd why it is behaving like this. I will report back that we should change TCQA card and possibly TBQC. Ill let the bosses handle that decision. I wont be back into the plant until Wednesday, so we shall see what the answer will be. Hopefully another Tech can swap it out tomorrow morning.
In terms of the ribbon cable, we do have Nygel or Nyogel (I cannot remember the name) dielectric grease. I recently ordered it but I have yet to convince anyone that it should be applied. I believe a fellow poster, or even you, recommended that brand. I never did test the ribbon cable, we do not have any replacements on site that I could find.
In terms of the auto calibration, I think every post I read about auto calibration that you responded too, I can sense you frustration with Auto cal, haha. At our site, it has always been a "thing" to do after a core was shutdown or anytime the gas was isolated from the unit. I think this method may change after this instance.
I will let you know any updates I find. Thanks again.
Actually I don't have any frustration with AutoCalibrate--it works just fine (usually!). It's just how people use it--and their unreasoned expectations--that cause my frustration.
I suspect if the site hasn't been using the dielectric grease on ribbon cable connectors that could be part of--if not the entire--problem. If I recall correctly GE didn't discover the issue until after the production of the Mark V had ceased, and so it wasn't used at the factory during assembly.
And, yes, it's understandable that one doesn't want to replace a USD5,000.00 card if it's not necessary. One could just try (with the power to the processor off!) unplugging and plugging the cables to the TCQA (at both ends of the cable!) several times if management doesn't want to apply the dielectric grease just yet. Sometimes, just sliding the connectors over the pins several times can displace any corrosion (for a while...).
In a pinch, there is a manual way to calibrate LVDT feedback. Use the manual stroking feature to measure the 0% and 100% stroke voltages (I usually monitor and record them from the AutoCalibrate display while manually stroking the device) and record them, and manually enter them in the I/O Configurator and download and re-boot the processors. The SRV is more complicated (you have to change the regulator type to 43 from 77, which requires a download and a reboot BEFORE using AutoCalibrate), and then after determining the 0- & 100% stroke voltages and downloading them to the processors and re-booting the processors and verifying the calibration, the regulator type has to be changed back to 77 from 43, and that has to be downloaded to the processors and they have to be re-booted another time.
The IGVs are a little more complicated; the readings at minimum angle and maximum angle have to be recorded, and then they have to be extrapolated to 0 and 100 (DGA) and entered into the I/O Configurator and downloaded and re-booted. Most of us learned how to extrapolate values on a straight line in grammar or middle school, but few of us remember how to do it. (Thankfully, there is the World Wide Web these days!)
So, in a pinch, if AutoCalibrate isn't working for some reason it IS possible to manually calibrate LVDT feedback. (And re-learn something in the case of the IGVs.)
It's always best if one has tried to resolve a problem if the details of what was done, how it was done, and what the results were are included in a post to control.com seeking further help. I go to a lot of sites where I hear, "We already tried that!" (sometimes we here it here, too). And, then when all other possibilities have been eliminated (at great cost (time IS money, after all!)), we circle back to what was tried before and find it WAS the cause of the problem. But, because the "test" wasn't done properly or the assumptions made about how the device worked weren't correct it was incorrectly eliminated as a possibility.
Anyway, as you say, best of luck. And, do please let us know if the AutoCalibrate issue gets resolved--and how it was resolved.
I replaced TCQA and TCQC card today and it did NOT fix the issues with the auto calibration on Secondary Gas valve. I suspect that it may be an issue within the TCQA Prom Auto calibration program. I did what you said as well with the ribbon cables, that actually worked one time on another unit that continued to have Loss of IO Communications alarm frequently, hasn't come back since. Unfortunately, it did not fix this issue. My next move will be to move each cores TCQA Card to another unit on site and see if the problem moves. I am not to confident anymore that it is <S> core, it really could be anyone of them causing an issue. This test probably wont take place for awhile. The run reason is upon us but I hope to tackle this the next time I have atleast two units out and can isolate and vent the gas off.
As of now I manually calibrated the valve. I manually stoked each valve, confirmed the measurements, recorded voltage readings on the each LVDT feedback signal and compared them with the HMI readings and DVM readings, and updated the IO Configuration file. After updating the configuration file and restarting each core one at a time, I performed an auto calibration on each valve EXCEPT for the secondary gas valve for peace of mind. On the secondary gas valve I manually stroked the positions from -25% to 128% similar to what an auto calibration would do. All the gas valves lined up pretty darn close to the updated valves in the IO Configuration except for the SRV. The original values in the IO Config were:
LVDT #1 0% = .825 Now = .695
LVDT #1 100% 2.129 Now = 3.244
LVDT #2 0% = .700 Now = .797
LVDT #2 100% 2.000 Now = 3.206
And yes, on the IGVs, I needed to do the Y = Mx + B and take 32-87 degrees scale and plot it over 0 - 100 scale.
Appreciate the help and will keep you updated when ever I get another shot at this.
First, thanks very much for the feedback! And most importantly, for the excellent detail about what you've done and what the results were.
The LVDT feedbacks for the gas control valves are typically connected to the TBQC card on <R>, and then are "fanned out" to the three TCQA cards, where each TCQA card then converts the analog signals to digital signals and then compares the digital feedback signals to each other to perform the high selection. I can't recall if you said you've replaced the TBQC card on <R>, but that's a card that is common to all three processors, and at a minimum it would probably be a good idea to put dielectric grease on the ribbon cables connected to the TBQC on <R>.
I don't really understand the situation you are describing with the SRV. If you use AutoCalibrate to manually position the SRV, you don't have to change the regulator type (I probably wasn't clear on that). There is usually another set of displays for manually positioning the fuel valves and IGVs, in the User Defined Display Menu (sometimes called the Demand Display Menu). If you use those displays to position the SRV (or the Liquid Fuel Bypass Valve), you would need to change the regulator type to 43 in order to be able to stop the valve at some reference position to measure the actual position and compare it to the scaled feedback. But, if you're using the Manual feature of AutoCalibrate to stroke the SRV, it automatically changes the regulator type to allow positioning of the SRV at intermediate points.
Sorry for any confusion I might have caused!
Please keep us up to date on your efforts, too.
No problem providing the feedback, this site has helped me out many of times indirectly, it is time to repay the favor with my troubles.
I was aware that TBQC on <R> did fan the regulators out to each of the units, however, the only TBQC card I had in stock I used on <S> core. Little did I know that card had issues when I re-introduced gas back into the system. The terminals for FPG1 ended up only having 7vdc vs. 24vdc which caused a nice little problem prior to the test run. So I had to quickly replace <S> cores TBQC with the one I removed earlier and now I need to send this TBQC card out. I probably could have just moved the input to another set of empty terminals but I did not want to change the factory configuration.
I have not used the Demand Display for valve positioning/calibration, only the Valve Calibration screen. Your post cleared this up about changing the regulator type, I get it now. I will have to "explore" this option next time. I just looked at our demand display and it is set up in there. More or less a chance to learn another way.
I guess it was a bit confusing how I described the SRV calibration but Ill try again.
1. Measurements have already been confirmed on the SRV.
2. I stroked the valves to various positions using the manual setpoint feature.
3. I measured voltage at the Mark V terminal board as well as compare them to the voltage readings on the Mark V valve calibration screen.
4. I averaged the three cores together, and entered those numbers in the IO configuration program.
5. As a sanity check after downloading and rebooting the cores, I performed an auto calibration to see how close I was with inputting the number. I was pretty close. I know you shouldnt run an auto calibration after performing what I did but curiosity got the best of me.
Switching gears here and talking about the secondary valve. Since I could not run an auto calibration on it, the averaging of the voltage readings of the three cores at 0% and 100% and entering them in the IO config, I am tracking about 2% off. Reference is 30% and FBK is at 32% at 62MW. I know it is not a big deal, just my ego is hurt and my OCD. Hah.
As always, will keep this post updated. We have a CEMS server upgrade coming up in 2 weeks, I may get a chance to revisit this issue.
The problem started showing itself again... Any I finally solved it.
We started tracking a 4% error from the LVDT feedback (#1 and #2) to the reference point. It was made evident from an alarm on the HMI that appears when the comparison is 3% or greater from feedback to reference. Since both LVDT's were tracking the same, I had ruled those out.
I knew it could not be a MarkV issue anymore since we replaced several terminal cards last round it did not solve anything. So atlast, the I/C tech must think mechanical now.
I opened up the valve and measured the valve travel again, only this time, i noticed something unusual. When the drive command was at "-25", the LVDT feedback was .681. When I drove the valve to "0", the LVDT feedback went to .743. That should not happen. I drove the valve to "-4", LVDT feedback was at .691. Doing the math, it comes close to the 4% error we were seeing.
I hooked up the dial indicator on the valve to see if it was truly moving or just a LVDT issue. It did move. The LVDT's had some oil on them, cleaned that up, still the same result. However, the LVDT's should not have oil on them, that's another issue we have to look into. Something is leaking.
After remeasuring the valve, the total valve travel came out to .715 inches vs. .75 inches like it supposed to. While this is an issue, you can "trick" the MarkV to think it is .75 inches by just changing the IO CFG and/or run autocalibrate (I still couldn't autocalibrate at this time) to range 0-100% in the range of 0-.715. However, it is still wrong and still could cause damage to the unit. So once again i review the past paperwork and I don't know how I missed this last time, but ever since the plant was built (over 18 years ago), the valve was never stroked/set to .75 inches. It was always around .715 inches. Why? I don't know. Those people are long gone now. So i didn't adjust the valve stop block. This really only left one thing left, the Moog servo.
Even comparing the LVDT ranges to other units, this unit was around .681 to 2.015 vs. on the other units, .6999 to 2.08 and some at 2.1. It should have clicked in my brain 6 months prior something was off.
We had just changed the servos about 8 months ago. We have them rebuilt every 3 years regardless. I locked the system out, pulled the wires and test the resistance. In place, I was reading about 990 Ohms on all three coils. The new moog on the shelf was at 1030 ohms on each coil. When i removed the old servo unit and tested it on the bench, i was getting even lower ohms, about 920-930 for each coil... I had a bad moog.
I replaced the moog, stroked the valves and IT WORKED! All this time, all this effort, replacing cards, ect, and it was a mechanical issue. A bad MOOG.
A lesson to be learned is check the resistance prior to and after installing the MOOG. Maybe it was bad after the rebuild or we damaged the wires during install. Also, our PI trending program never had the points inputted to be able to historically track this issue, ensure you are tracking feedback and reference points in PI. Maybe we could have seen this coming or atleast know when it started happening.
As for the valve stroke issue, we are a little hesitant to change the stop block. The units have been tuned so it is quite possible they were tuned with the valve stroke at .715 vs. .75. Maybe we are not causing damage... Who knows! Might have to get an expert in to further look into it.
MORE importantly--Thanks for the feedback!!!
AS for the difference in stroke (travel)--between what the Control Specification (I presume) lists as the valve stroke and what you are actually seeing, many times the valves actually supplied by the vendor did not match exactly the information provided by the supplier to GE used to put information in the Control Specification. Often times, there were several months or more between the time the Gas Valve skid was ordered and when it was shipped and when the Control Specification was produced.
I'm a little unclear on the "damage" you think you might be causing.
Anyway, thanks VERY MUCH for the feedback! It will definitely help someone some day!!!
The constants for the valve travel is .75 inches (if you need the markV signal name, I can look that up). If the system is thinking that the valve is opening/scaled to .75 inches but really only able to move/scaled to .72 inches, My gas valve is essentially opening more than it should based on the fuel curves...
The secondary valve LVDT was scaled at .688 vrms at ZERO and 2.022 vrms SPAN.
If the valve was called to open at 40%, at a full stroke of .75 inches, my LVDT feedback would be 1.40 vrms.
At a full stoke of .72 inches, my LVDT feedback would be 1.43 vrms.
That is a 2.12% increase. Multiply 2.12% by the #/sec gas flow and you are putting in an additional amount of gas when its not needed. We can possibly be burning hotter in the cans.
Also, i did notice our absolute atmospheric pressure were calibrated to relative barometric pressure vs. absolute pressure. We are currently at 680 ft above sea level (around 14.3 psia), however, MarkV thinks we are at sea level, if not more. Often we see the MarkV reading at 14.8 to 14.9 psia. This for sure is possibly causing thermal stress. As I digress.
Maybe I am looking at this wrong.
I need to noodle this for a while. I would also be very curious to know:
1) What frame size machine(s) are you working on?
2) Which DLN combustion system do the unit(s) have (DLN-I; DLN2.6; or?)?
The gas control valves--are they the right-angle Woodward gas control valves, or???
1. Frame Size: 7EA
2. DLN System: DLN-1 Lo NOx
3. Gas Control Valves: Right Angle Fisher Valve EAB.
On a side note, this unit always ran at a higher TTRF. We have 2050 (maybe its 2055) combustion parts. But at normal load, we would see 2040 while our other three units would get 2020ish. Maybe this is in correlation with the secondary gas valve.
You have mentioned the SRV and the Secondary Gas Control Valve (which I presume is GCV2 of an independent gas control valve skid--one with three or four gas valves: an SRV (usually a rotary cam vee-ball style valve), and two or three right-angle gas control valves (GCV1, GCV2, and possibly GCV3). Early DLN-I units were supplied with an SRV, a GSV (Gas Splitter Valve) and often a GTV (a Gas Transfer Valve). In their efforts to standardize on a design for as many heavy duty gas turbine Frames as possible they went to what they called the IGCV design--which included three or four valves as initially described above. I'm presuming you have the IGCV design skid.
That means GCV2 (if I'm correct about the type of skid you have) is connected to the Secondary Fuel Nozzle manifold and Secondary Fuel Nozzles of the turbine. It is only sending fuel to the unit when operating in Lean-Lean (and Extended Lean-Lean) and Premix combustion modes.
No matter what the actual stroke is versus the "expected" or "documented" stroke, if the unit is operating with the proper emissions level(s) in Premix Steady State combustion mode--you shouldn't do anything. It's been tuned for emissions based on the current "configuration" and any changes now will require a re-tune--which can get VERY problematic, VERY fast. Best to let sleeping dragons lie. (In my personal opinion.)
The flow-rate through GCV2 is a function of the fuel split--the percentage of the total fuel going to the turbine. The total fuel, during acceleration from warm-up, and during synchronization, and during loading and unloading, and when operating at Base Load--is essentially closed-loop control. What that means is that there is a reference for each of those operating conditions, (acceleration rate reference; speed reference; Droop Speed Control reference; CPR-biased exhaust temperature control reference) and the total fuel to be flowing to the unit is "corrected" to be equal to the reference for the current operating condition.
So, whether or not the valve is at the exact correct position or it's 12% more open or closed than the "expected" position for the reference, the amount of fuel required to make the actual value (acceleration rate; speed; exhaust temperature) equal to the reference value is what is actually flowing. So, the unit isn't getting too much or too little fuel--it's fine. It's not going to burn down (unless the other inputs to the reference calculations are grossly wrong (such as CPD, and AFPAP, and CTIM, etc.).
You mentioned the AFPAP value(s) seem to be in error. Well, that's not uncommon at many sites. And, it's usually caused by poor installation and maintenance practices. Those 96AP transmitters are usually differential pressure transmitters, and they are usually calibrated to a range of atmospheric pressure (say 27 in Hg to 32 in Hg (just sample numbers; I don't have a CSPEC or I/O Configuration file to look at right now). And, the sensing ports of the transmitters are usually "open" to atmosphere somewhere--and those "openings" often get plugged by insects and/or dust and dirt. Sometimes there were sintered iron vent covers used; sometimes, I saw hand-torn pieces of Scotch-brite scrubbing pad in the ends of the tubing of the transmitter ports (supplied by the vendor who assembled the boxes).
Some sites also relocated the JBs to make maintenance outages easier--and when they did that many were relocated to ground level. The other tubing lines for the other transmitters in the JBs then should have had condensate drains tubes added to them, with drain valves which had to be periodicially opened. But, the drain tubes didn't get added, and if they were, they were rarely opened.
The point is: A lot of incorrect readings for the transmitters in the same JB as the 96APs were incorrect because of installation problems (original or relocation) AND because the sensing lines weren't maintained properly (inspected for insect nexts, dust and/or dirt--and kept clean; etc.).
The ambient pressure (atmospheric pressure--AP) transmitters are pretty critical to the operation of the unit. They help calculate TTRX, and even TTRF1 (if I recall correctly). So, they need to be properly calibrated.
You should have a document (sometimes called a "drawing") called the Device Summary. And, the Device Summary should list the calibration specifications for the 96AP transmitters (there was a period, during the Mark V production, when the Device Summary documents left a lot to be desired). If you have any questions, please provide the manufacturer and model number of the 96AP transmitters and someone here can probably help with the proper calibration specifications and procedure.
Finally, the SRV. Yes, the SRV has LVDTs. BUT, the calibration of the SRV LVDTs is NOT critical! That's because, unlike the other servo-operated devices on a GE-design heavy duty gas turbine which are position loops (meaning the reference is position, and the feedback is position). The SRV is a pressure-control loop--it's reference is P2 pressure (the pressure downstream of the SRV (and upstream of the GCV(s))--and the Mark* moves the SRV to whatever position is required to keep the actual P2 pressure (usually FGP2) equal to the P2 pressure reference (FPRG). And it doesn't make any difference if the valve is at 44.7% of actual stroke but the LVDTs say it's at 43.5% of stroke (or 49.2%)--as long as the actual P2 pressure is equal to the P2 pressure reference the actual valve position isn't critical. Not at all.
LVDT feedback calibration is important for the IGVs, and most importantly for GCV1 (during firing and warm-up). It's also important that it be linear for GCV2--for DLN tuning purposes. If it's not linear, there will be problems. If it's not exactly perfectly equal to the actual stroke or the expected stroke--it can often be tuned to make the desired emissions levels. But, it's not going to hurt the hot gas path parts during normal operation. (Extended Lean-Lean mode is NOT a normal operating mode, by the way; Lean-Lean and Premix are--for GCV2.)
I think that about covers it. I hope I have been clear and have added to your understanding. I think some, if not all, of the IGCV skid-equipped units used some sort of analog linear interpolation block for the gas control valves--because the flow through the valves was not always proportional to stroke (as the GE GCVs were). And, because different valves were used for different Frame size units, they used a software method for getting the desired flows out of the valves as necessary.