The unit was running on FSNL for about 5 minutes and then tripped on exhaust temperature spread.

We checked the trend and deduced about 200 F diff on TTXD 9,10,11,12 and 13 from the other TTXDs

Oir engineering recommended we check SRV GCV and IGV stroke and calibrate if needed.

Now in the Toolbox we did the force list for the SRV to start strokning but noticed we cannot launch the regulator as it was grey and not clickable, putting in mind that we are in the correct privilege level. After some digging, <S> and <T> controllers were yellow but still can be connected to.
On the toolbox app, controllers status are:
R : green , boot, equal 98%
S : yellow, boot, equal 94%
T : yellow, boot, equal 97%
all percentage values are increasing and decreasing by .1%

All signals are unknown, but we can connect to any controller at any instance.
Complicity graphics are all black.
We did reset VCMI by reset button

So does anyone have any idea of what is going heren or what we did wrong?

Thanks

 

The unit was running on FSNL for about 5 minutes and then tripped on exhaust temperature spread.

We checked the trend and deduced about 200 F diff on TTXD 9,10,11,12 and 13 from the other TTXDs

Oir engineering recommended we check SRV GCV and IGV stroke and calibrate if needed.

Now in the Toolbox we did the force list for the SRV to start strokning but noticed we cannot launch the regulator as it was grey and not clickable, putting in mind that we are in the correct privilege level. After some digging, <S> and <T> controllers were yellow but still can be connected to.
On the toolbox app, controllers status are:
R : green , boot, equal 98%
S : yellow, boot, equal 94%
T : yellow, boot, equal 97%
all percentage values are increasing and decreasing by .1%

All signals are unknown, but we can connect to any controller at any instance.
Complicity graphics are all black.
We did reset VCMI by reset button

So does anyone have any idea of what is going heren or what we did wrong?

Thanks

What kind of "forcing list " you are referring to?

You mean Cimplicity not complicity .. views are black? is there some # signs on the display/view values..

 

What kind of "forcing list " you are referring to?

You mean Cimplicity not complicity .. views are black? is there some # signs on the display/view values..

Forced list:
L4_XTP
L20tv1x
L20vg1x
L3ADJ1
L20fg1x

*Yes sorry I meant the Cimplicity program
*Yes all signals have hash marked<#>

*All logic point in the toolbox are <0U>

 

Okay

Any diagnostic messages/alarms from toolbox ?

 

Okay

Any diagnostic messages/alarms from toolbox ?

Nothing, other than at the buttom right corner when connecting to each contoller separately it shows:

On the toolbox app, controllers status are:
R : green , boot, equal , 98%
S : yellow, boot, equal, 94%
T : yellow, boot, equal, 97%
Designated controller is the <R>

Basically the control state of all controllers is "boot" it looks like it is trying to boot but stuck on boot.

Is there a sequence to resetting the controllers?
Like powering down certain modules to fully reset the system?

 

Yes there is a procedure when you downlowading topology and application code on the controllers

Look on the GEH-6421 vol 1 Page 144 and page 232 it is clearly written to power down controller and not using reset button as you mentionned

 

Yes there is a procedure when you downlowading topology and application code on the controllers

Look on the GEH-6421 vol 1 Page 144 and page 232 it is clearly written to power down controller and not using reset button as you mentionned

I saw that, whta I'm saying is i had perfect RST controllers in <control> state. Now they are all in <boot> state

How can I but them back to <control> state?

 

I saw that, whta I'm saying is i had perfect RST controllers in <control> state. Now they are all in <boot> state

How can I but them back to <control> state?

Well you asked how to reboot Controllers and manual sayin that power cycle is needed to reboot controllers that why I asked this question

Who is packager of this unit?

Don't you got kind of procedure from OEM for MarkVI operation & maintenance like O&M manual?

 

Power cycling the controllers alone didn't fix the issue.
I Had to power down The VPRO modules too and sequence Power all of them up again.

Now i Can't use any regulator to calibrate the valves, Bytting in mind everything is healthy and clear no alarms. Controllers are all equal and in control state.

 

Your engineering department are idjits. If the unit is burning natural gas how can the SRV or GCV out of position (which would result in at least a couple of Process Alarms warning of the condition(s)) cause several consecutive exhaust T/Cs to differ by so much when the fuel nozzles are fed from a common manifold and the pressure and flow in the common manifold is controlled by the two valves? AND, the IGVs control air flow to all the combustors not just a few? “Check the valve and IGV calibrations,” is code for, “I don’t have a gawd damn clue what the problem is, so do something that makes it look like we’re taking action and hope that the problem resolves itself.” In other words, “If we can’t dazzle them with brilliance, we’ll baffle them with bullshit.” No logical thinking resulted in this order. None. Zero. Zilch. Nada. Niente.

I’m confused about how the processors got to boot status from an Equal and running condition.?.?.? Was that caused by trying to reboot the controllers when rebooting the VPROs? If you tried to download to the processors you have probably screwed yourself and others. Downloading for this kind of issue is useless—and shows a further lack of logical thinking. The instructions below presume no downloads were attempted.

What is the condition of the .m6b file you are using? Is it read/write or read only? Often, if the file is read only you can’t do some functions. Files get to read only when they aren’t closed properly—usually.

Forget stroking the valves and IGVs—it isn’t going to tell anyone anything.

You need to do a proper reboot of the Mark VI—and that means the unit has to be taken off cooldown and many of the MCC starters have to be racked out (main circuit breakers opened) because when you power down the processors many motors will start at the same time and the plant might go black. Don’t believe me? Don’t rack out the breakers. But keep a flashlight close at hand.

Then you need to start powering down the three control processors and the three VPROs. And then after they are all powered down for about five minutes power-up the three VPROs and wait for one minute. Then power-up the three control processors one right after the other. And wait. And wait. And wait patiently some more. It will probably take 6-10 minutes for the panel to get back to Equal and running status.

Then you need to take the unit off cooldown (because it defaults to COOLDOWN ON when it boots back up from a powered-down status). That may take some logic forcing, but it’s doable.

Then you can start clearing Process and Diagnostic Alarms.

Then you can rack in the MCC motor starter breakers.

Then you can put the unit ON COOLDOWN to make sure everything is good.

Then you can start looking for why the fuel flow wasn’t sufficient to keep flame in all the combustors. That investigation won’t find anything.

Then you can consider that possibly there is a problem with the cross-fire tubes between a couple of combustors, or the combustion liner or transition piece of a couple adjacent combustors are damaged. Or the fuel nozzles of a couple of adjacent combustors are plugged. Because either the fuel flow to a couple of adjacent combustors was choked or too much axial compressor discharge air got into a couple of adjacent combustors and caused the flame to go out. Or some liquid in the natural gas fuel line got into a couple of adjacent combustors and blew the flame out.

But it’s damn sure the SRV nor the GCV nor the IGVs being out of “calibration” didn’t put the flame out in a couple of adjacent combustors.

If the unit was being started immediately after a maintenance outage, there are all kinds of mechanical possibilities. But not the SRV or GCV or IGV “calibrations.”

Then the Plant Manager will decide that no mechanical inspections are going to take place and the unit needs to get re-started—and now.

Best of luck. Hope no one tried downloading.

 

Your engineering department are idjits. If the unit is burning natural gas how can the SRV or GCV out of position (which would result in at least a couple of Process Alarms warning of the condition(s)) cause several consecutive exhaust T/Cs to differ by so much when the fuel nozzles are fed from a common manifold and the pressure and flow in the common manifold is controlled by the two valves? AND, the IGVs control air flow to all the combustors not just a few? “Check the valve and IGV calibrations,” is code for, “I don’t have a gawd damn clue what the problem is, so do something that makes it look like we’re taking action and hope that the problem resolves itself.” In other words, “If we can’t dazzle them with brilliance, we’ll baffle them with bullshit.” No logical thinking resulted in this order. None. Zero. Zilch. Nada. Niente.

I’m confused about how the processors got to boot status from an Equal and running condition.?.?.? Was that caused by trying to reboot the controllers when rebooting the VPROs? If you tried to download to the processors you have probably screwed yourself and others. Downloading for this kind of issue is useless—and shows a further lack of logical thinking. The instructions below presume no downloads were attempted.

What is the condition of the .m6b file you are using? Is it read/write or read only? Often, if the file is read only you can’t do some functions. Files get to read only when they aren’t closed properly—usually.

Forget stroking the valves and IGVs—it isn’t going to tell anyone anything.

You need to do a proper reboot of the Mark VI—and that means the unit has to be taken off cooldown and many of the MCC starters have to be racked out (main circuit breakers opened) because when you power down the processors many motors will start at the same time and the plant might go black. Don’t believe me? Don’t rack out the breakers. But keep a flashlight close at hand.

Then you need to start powering down the three control processors and the three VPROs. And then after they are all powered down for about five minutes power-up the three VPROs and wait for one minute. Then power-up the three control processors one right after the other. And wait. And wait. And wait patiently some more. It will probably take 6-10 minutes for the panel to get back to Equal and running status.

Then you need to take the unit off cooldown (because it defaults to COOLDOWN ON when it boots back up from a powered-down status). That may take some logic forcing, but it’s doable.

Then you can start clearing Process and Diagnostic Alarms.

Then you can rack in the MCC motor starter breakers.

Then you can put the unit ON COOLDOWN to make sure everything is good.

Then you can start looking for why the fuel flow wasn’t sufficient to keep flame in all the combustors. That investigation won’t find anything.

Then you can consider that possibly there is a problem with the cross-fire tubes between a couple of combustors, or the combustion liner or transition piece of a couple adjacent combustors are damaged. Or the fuel nozzles of a couple of adjacent combustors are plugged. Because either the fuel flow to a couple of adjacent combustors was choked or too much axial compressor discharge air got into a couple of adjacent combustors and caused the flame to go out. Or some liquid in the natural gas fuel line got into a couple of adjacent combustors and blew the flame out.

But it’s damn sure the SRV nor the GCV nor the IGVs being out of “calibration” didn’t put the flame out in a couple of adjacent combustors.

If the unit was being started immediately after a maintenance outage, there are all kinds of mechanical possibilities. But not the SRV or GCV or IGV “calibrations.”

Then the Plant Manager will decide that no mechanical inspections are going to take place and the unit needs to get re-started—and now.

Best of luck. Hope no one tried downloading.

Thank you for the helpful information. Now we actually didn't download at any point. The thing is I think you mentioned something interresting. The .m6b file in the Toolbox is showing read only, however I can still perform forces.

 

If the .m6b file is read only, you need to close out of Toolbox without saving any changes and go to the folder where the .m6b file is located and right-click on the file and change properties to read/write. If you don’t know where the file is before you exit Toolbox you need to click on File on the menu bar while the file is open and check the path to the.m6b file.

WhenToolbox is reopened the file should not indicate read only and things should be better. You should find that the regulators are not greyed-out. BUT time will certainly be wasted if the valves & IGVs are stroked.

There’s simply too much we don’t know about the conditions of the unit, the fuel supply, the way the machine is operated, the time since the last maintenance outage, what was done since the last maintenance outage, how long since the machine was last started, why the unit wasn’t synchronized soon after reaching FSNL, etc., etc. If the unit tripped on high exhaust temperature spread there was an alarm about 9 seconds before the trip warning of Combustion Trouble. What other alarms were active/annunciated during the start?

Is there a reason why the engineering department thought the fuel valves or the IGVs might have caused the problem? Were the fuel valves and/or the IGVs “calibrated” recently? But, still—the unit reached FSNL and was running for approximately five minutes, and, again neither the fuel valves nor the IGVs can restrict the fuel flow or change the air flow to a couple of adjacent combustors only. That’s just simply not possible.

Ask the engineering department to get out their swirl angle chart/calculator and determine which combustors lost flame and think about what might have caused the flame in those particular combustors to be extinguished. Are those couple of combustors near the spot where the natural gas enters the fuel ring manifold (usually at or near the bottom of the manifold)? If so, a slug of liquid in the natural gas fuel supply could have made its way into those combustors first and caused the flame to be extinguished. Are there knock-out drums in the fuel line? Was an off-line water wash performed just before the machine was re-started?

Did the other exhaust temperatures drop at the same time, just not as precipitously? If so, was there a problem with the natural gas fuel supply pressure or flow?

Anyway, hope the .m6b file gets restored to read/write condition and the processors all return to equal and controlling.

Without more details there’s not a lot more to add. Re-start the machine and if it gets to FSNL and the exhaust temps are good then there’s probably nothing wrong. On the other hand if there are high spreads in a similar pattern during the re-start then there’s something mechanically wrong and some difficult decisions need to be made. Or, while it’s HIGHLY UNLIKELY there could be a T/C wiring issue (like burned insulation)—but that really isn’t very likely.

Please write back to let us know what, if anything, was found regarding the high exhaust temperature spread trip. If you provide a lot more information we might be able to offer some more ideas. But we’d need a lot of information.

Finally, even if the processors aren’t equal and controlling Toolbox should still be able to communicate with them. If it couldn’t then troubleshooting or configuring would be extremely difficult. Let us know, also, if the processors got back to equal and controlling. (It shouldn’t require downloading….)

Best of luck.

 

Hello dear guys!
We have the same problem with processors, all three processors write Boot. I tried rebooting Mark 6 completely, turned off all three controllers and turned off vpro. I left the Mark 6 turned off for a day. A day later I turned on vpro first, then controller R, then controller S, then controller T. Even after this, I still have errors. If anyone had this problem and you solved it, please help.