Dear sir,

ours is a GE Fr5 - Mk6 speedtronic dual fuel system. Recently when the turbine was running at 8MW load on fuel gas mode and operator tried to change over the operation from fuel gas TO distillate fuel mode, the turbine load swing down below 1.5 MW and breaker opened on reverse power with turbine still running at FSNL. On checking the control system, slot5 VSVO had the following diagnostic alarms in all the 3 core R-S-T.and not getting RESET.

1. Servo current#2 disagree with reference suicide
2. servo current#1 disagree with reference suicide.
3. LVDT#4 RMS volt out of limits.

Under this situation, do I need to "disable" the suicide condition first and then proceed further to find the fault. Pls let me know the trouble shooting procedure. Thanx in advance...

 

ESKAY,

I'm not going to go into the issues with transferring fuels; they have been covered ad nauseum in many threads on control.com.

There is a lot of information that was not supplied that would be required to say for certain exactly what happened, but there is some information below which should help to understand what happens during a fuel transfer, and what might have happened during the event at your site.

As for how to reset the Diagnostic Alarms, you should NOT have to disable the suicide in order to reset the alarms. You will likely have to determine what is causing the LVDT Diag. Alarm and resolve that condition to be able to reset one of the other Diag. Alarms. And, you may need to use the 'Master Reset' function to reset the alarms, or the Diagnostic Alarm Reset function (there seems to be some units which require one or the other; consistently inconsistent, consistently).

So, you will need to determine which servo outputs are connected to the VSVO in Slot 5, and which LVDT is connected to the fourth LVDT input of the VSVO in Slot 5. Fix the LVDT alarm, and you will probably be able to reset one of the other Diagnostic Alarms.

In the worst case, you can try re-booting each control processor rack <b>one at a time</b>, waiting about three minutes <b>after</b> the re-booted processor has returned to controlling status before re-booting the next control processor.

But, only after you've resolved the LVDT Diagnostic Alarm.

The fuel splitter algorithm decreases the FSR of the fuel being transferred from at the same rate that it increases the FSR of the fuel being transferred to. The presumption is that for various loads the FSRs for the two fuels are roughly equal, meaning that the power produced by each fuel at a particular FSR are roughly equal.

If the fuel flow-rate of the fuel being transferred to can't or doesn't increase as the FSR for that fuel is being increased (as the FSR for the other fuel is being decreased) then the power produced by the turbine-generator will decrease because the total fuel flow-rate has decreased.

Depending on the mode the unit was being operated in (Preselected Load Control, or Part Load) and the type of droop control used in the Speedtronic, the Speedtronic may try to increase
the fuel flow-rate to try to maintain the power output. If this happens, then it's common for these types of alarms to occur because the Speedtronic is putting out more and more negative servo current to try to increase the fuel flow-rate and if the fuel flow-rate is not stable (such as when there is air in the fuel line or fuel filter) then it can be changing current output very quickly, and the feedback can be changing very quickly as well.

If the reverse power function was activated during the fuel transfer, then the "master" FSR value will be immediately decreased as the speed reference is reset to approximately 100.3% in an effort to prevent an overspeed. This could also be causing a problem with the reference and feedbacks not matching because both are changing very quickly. (Remember, the servo-valve outputs are changed at a rate of as much as 200 times per second in order to try to make the feedback equal to the reference, and if the reference changes very quickly, also, well, then issues can occur.)

The LFBV of a Frame 5 does not have an LVDT, so it's pretty likely that Diagnostic Alarm is not related to the LFBV servo output.

We can't know what those two outputs on the VSVO in Slot 5 drive; they might be the SRV/GCV, or the IGV and LFBV. And, we can't know what the fourth LVDT input is connected to. So, it's impossible for us to say exactly what happened.

We would also have needed to know what Process Alarms were annunciated at the time of the event and any other Diagnostic Alarms that were present or annunciated at the time of the event.

GE and packagers of its turbines recommend frequent and periodic fuel transfers for dual fuel units (gas/distillate) that must transfer fuels quickly in the event of a supply problem with one fuel or the other. This is to ensure that the liquid fuel system, particularly, is regularly exercised and that there is no air in the liquid fuel lines or liquid fuel filters, and that all the components of the liquid fuel system, the liquid fuel forwarding system, the liquid fuel purge system, and the atomizing air system all work properly when they need to in order to ensure a smooth and relatively "bumpless" fuel transfer.

Regular and periodic fuel transfers means approximately once per week.

Hope this helps.

 

Dear All,

ours is GE Fr5 Mk6 control (Dual fuel). Turbine was running on fuel gas mode at 8MW lad and when tried to change over from Fuel gas to Distillate mode, load starts reducing as the fuel FSR1 starts going up with FAL and fql_pr1/pr2 fluctuating. load starts recovering with the MIX operation. We are unable to monitor the dist.fuel parameters to ascertain the fault with in this short time of load reduction and turbine breaker tripping on reverse power when control selected from MIX to Dist.fuel mode.

On fault finding, there were diagnostics alarms from "T" controller as follws: -- voting mismatch for FAL-FAG-FAGR-LVDT RMS Volt out of limits {for GCV} and FAG/FAGR servo current suicided. suspect failure of VSVO card of "T". WE have NO spare card to "replace" and see the problem and either wish to "SWIPE" the card. I wud like to know, will there be any other problem related to this, other than card problem. "T" contoller switched ON and OFF few times and still same problem. Any of the Mk6 experts could suggest me better. Thanx...

 

ESKAY,

I believe what you are trying to ask is if you can <b><i>swap</b></i> the affected VSVO card with another VSVO, either in the same processor rack or another processor rack. This would allow you to determine if the problems "follow" the card or are in the processor rack slot where the affected card came from.

This is a common troubleshooting method, but you need to be prepared for the possibility that the problem is a failed card or a failed processor rack (the latter is not likely, but not unheard of either). This means you need to have another VSVO card or another processor rack "in the pipeline" (on it's way to site).

Without being able to look at the Trip Log data from the event, and any other data you might have, we can't offer much more in the way of troubleshooting.

Something you need to consider is how successful previous fuel transfers were versus this particular fuel transfer. If previous fuel transfers were fairly successful, and this one wasn't--with, <i>coincidentally</i>, a lightning strike--then you need to realize that every fuel transfer isn't going to be perfect. We don't have enough information about the time since the last fuel transfer and other things that were going on at the time of the event (such as an electrical storm, which might have had an effect on power distribution and system frequency).

If I recall correctly each VSVO card has only two servo outputs, and it's common for the SRV and GCV to be on the same VSVO card. So, it's likely that you have more than one VSVO card in all three processor racks. The FAG (GCV servo current) and FAGR (SRV servo current) would be related to one card, likely. FAL (LFBV servo current) would likely be related to a different VSVO card.

You keep talking about <b>a</b> (i.e., single) VSVO card failure, but you keep listing more than two servo values. If you're having problems with more than one VSVO card in <T>, that suggests something more "sinister".

You could try exchanging VSVO cards in <T> (again, I'm presuming there are at least two VSVO cards in <T>) and downloading to <T> and then re-booting <T> and seeing what happens.

But, we don't have enough solid information to be able to help you, and if you don't have a VSVO card (or cards) to replace defective ones (which could have been damaged during a lightning strike; possible, but not likely) then you're going to be in the same position you're currently in.

Lastly, if you have LVDT feedback problems and that is causing the suicide(s), then solve the LVDT feedback problems and that will likely resolve the suicides. That may be all that's required--solving the LVDT feedback problems causing the suicides.

I'm not trying to be harsh, here, but without more data (individual LVDT feedback positions and the .m6b file), it would be very difficult for us to help you via this forum. It sounds as if the Mark VI competence and confidence level at the site is low, so you might consider having a knowledgeable person come to site to assist with the issue if you can't make much more progress than you have.

But, again--if you, or a Mark VI-knowledgeable person--determines you have a VSVO card problem, or a processor rack problem, then you're going to need spares anyway.

We would be very interested to follow the troubleshooting and resolution, and to provide any assistance we might be able to. Please write back and let us know how the troubleshooting and resolution of the VSVO problem proceeds. As for the fuel transfer issue, I think you need to move past that for now and resolve the VSVO issue(s).

 

ESKAY,

I seem to have confused this thread with another when I mentioned a lightning strike.

Please disregard the lightning strike comments in my post to this thread.

Sorry for any confusion it may have caused; all the other information is pertinent to your query.

 

Dear CSA and all,

I would like to give you a clear picture on our servo system. We have two VSVO cards in each controller. one in slot#5 and the other in slot#7. the VSVO cards in slot#7 ARE NOT USED AND NEITHER CONFIGURED. The SLOT#5 vsvo has 3 regulators. Reg#1 used for the servo output#1 for FAGR (SRV). Reg#2 for servo output#2 for FAG (GCV). Reg#3 for the servo output#3 for FAL (65FP). which are controlled through TSVOs at position 1A3 (for SRV&GCV) and 1A4 for 65FP servo. All these signals FAG-FAGR-FSGR-FSG-FQL-LVDT are sent to core R-S-T and voted for the mismatching. Excitation voltage for the LVDT#4 is from "T" core, which is one of the LVDT of GCV.(REg#2). We get 7.0V 3.12Khz for LVDT1-2-3 which we get from Reg#1. and we get 1.23V RMS for the LVDT#4.LVDT ohmic value compared with the other and found to be OK. This generates a diagnostic alarm in all the 3 cores and as well, the diagnostic for the voting mismatch for the FAGR-FAG-FAL etc. All the diagnostics are pertaining to VSVO in slot#5 of "T" core. That’s why, I would like to replace the VSVO card of "T" core with the another one. In this case can I make use of the VSVO card in slot#7 to diagnose the fault?

kindly reply...

 

ESKAY,

This is very helpful, indeed. I have seen only two servos connected to one VSVO recently, hence the need for two VSVO cards. It seems odd there would be a second, unused VSVO card, but stranger things have happened.

And, it would seem you have arrived at the most likely cause of the problem: a problem with the LVDT excitation for input #4.

Yes; if there is a spare VSVO card in another slot of <T> you should just be able to exchange the two cards, then download the .m6b file to <T>, re-boot <T>, and proceed with troubleshooting.

Please write back and let us know the results of your efforts.