MarkVIe Deadbus Breaker Closure Simulation

Mark V TMR system is installed on our site for Frame V gas turbines. Mark V was initially configured with <I> but in 2008 <I> was upgraded to HMI (computer based and with cimplicity). Two gas turbines are installed at our site and each gas turbine has its own HMI in the GT compartment and we have one HMI in the control room for both the gas turbines for displaying data. The fuel used for the gas turbine is Natural Gas.

We are upgrading MarkV to MarkVIe on one of our gas turbines. I have already mentioned this in a post in June 2018. CSA mentioned in that post that we are going to find lot of undocumented changes in the new logic. He was absolutely right and we have started to notice a lot of changes although we are in commissioning phase yet. I want to mention here that keeping CSA's point in view we asked GE if there are going to be any changes in the logic and as expected their answer was NO. I am posting this just to give feedback to CSA. Dear CSA I am getting a LITTLE too fond of you, TECHNICALLY.

Well the logic is quite another issue. In this post I want to discuss the Dead Bus Breaker closure simulation. We have removed the old wires from the MarkV panel, removed that panel and installed the new panel with MarkVIe. The wires were re-terminated in the MarkVIe panel carefully. There was no change in field instrumentation except the flame scanners. Atlast we are able to getrid of 335V scanners. New scanners are installed and they work on 24V. The application code has been uploaded and HMI's are ready. We have done the offline washing of the machine and after that we have fired the machine and tested it upto the FSNL. While going to the FSNL we have noticed the difference in MarkV and MarkVIe codes. Some of the changes are acceptable while others or not. We are going to ask GE for the required changes.

Currently our GT is in OFF mode. The main BUS is live as we are getting power from other machines. We want to simulate the Dead Bus Breaker closure logic in this scenario. We have tried few things today. According to our understanding if L25A relay (it was L25X in MarkV) is actuated then we can Manually close the breaker. Dead Bus detection is in the logic of L25A (L25X) command. We racked out the 52G breaker and removed its cables from the breaker. We decided to force the L25A command and give manual breaker closure command and check whether the contact changes at the breaker end. To our surprise even after forcing L25A we the contacts of the relay were not changed, neither on breaker side nor on the terminals in the MarkVIe. Should we not force L25A in any case? Is it not allowed? Will contacts of relay not change even if we force it?

If we force the SYNCH CHECK PERMISSIVE and SYNCH CHECK BYPASS, As BUS is live and voltages are there and GT is in OFF mode can we swap the L3_GEN volts and L3_Bus volts? This will tell the L25A command that permissive are present and Generator Voltages are there and BUS is dead. It should actuate the L25A relay command? Am I correct?

If yes the what is the difference between forcing the L25A command AND the second activity? Are we not supposed to or allowed to force the L25A command? This card will actuate the relay ONLY if all PERMISSIVES whether you force it or not?

I hope that I am able to clarify the situation.

I'm very sorry to hear of your situation with the application code. The salespeople do not understand how the upgrade/retrofit process is performed by GE. (Actually, many of the people in the engineering department performing the upgrade/retrofit don't really <i>understand</i> the entire process, either. They just go through the motions they think they should be going through.) The salespeople are going to say whatever they need to say to get the sale. That's the end of their involvement in the project, and any problems then belong to another division of the Company. It's as simple as that. My bad--as I should have been clearer about that aspect of the upgrade/retrofit. At least you bought a "rip-and-replace" Mark VIe, and not one of the Mark V "Life Extension" or "Migration" systems.

Here's what I'm going to say about simulating breaker closures. It's dangerous, and, it's dangerous. It's also possible, but I'm NOT going to provide any step-by-step procedure--only the basics and some background.

To close any breaker that is connected to the Mark* synchronization function, it's necessary for the Mark* to see speed (turbine speed). If you look at the application code in the Mark VIe (the CSP in the Mark V), the synchronizing Big Block needs to see speed. And, usually, that means that speed has to be simulated to BOTH <Q> and <P>. (I don't have access to any Mark VIe manuals at this writing, sorry; so I can't provide the exact I/O terminal boards/screws.)

It's also usually necessary for the Mark* to see generator terminal voltage--so that means that some method of providing Generator ("Incoming") PT voltage input to the Mark must be provided. And, if it's desired to test the actual synchronization function then it will be necessary to provide simulated Bus ("Running") PT voltage--which means variable frequency signal and variable voltage as well. This is usually only possible with very expensive relay test equipment (such as some Doble test sets). I have seen people try to use autotransformers, but not successfully; the frequency must also be variable for the synch circuits to work--not just the voltage.

The Mark* synchronization Big Block compares turbine speed (YES--turbine speed!) to Bus ("Running") frequency, and then determines the appropriate time to send the breaker close signal based on generator PT frequency and Bus PT frequency. So, the synch function needs to see turbine shaft speed, real or simulated. And, because the synch function is also performed in <P>, it's necessary to also simulate speed to <P>. (If I recall correctly, the primary synch function in the Mark V was done in <Q>, and the synch check function was done in <P>. But, I think that's been switched in the Mark VIe--with the primary synch function done in <P> and the synch check function done in <Q>. BUT, I have been wrong before, and I will be wrong again (perhaps now, but certainly in the future!). Hence the need to simulate speed in both "places" (<Q> and <P>).

AND, when simulating speed to the Mark*, one realizes VERY fast: It's a VERY "dumb" control system--easily fooled into thinking the turbine is actually running simply by simulating speed! LOTS of things happen as the speed signal(s) are increased--so LOTS of alarms will be annunciated (Process and Diagnostic) alarms. (Motors are going to start, run, and stop; solenoids are going to be energized and de-energized; etc.) If the speed signal(s) are increased too quickly, the overspeed detection function can be triggered (by the rate-of-change detection), so it might be necessary to issue one or three MASTER RESETs once the speed signals get to 100%. For, this reason, it is important that lots of things need to be secured (the fuel, for example!, but many others). It's NOT usually necessary to initiate a START, but I have seen application code that DID require a START to be active. Again, it takes a pretty careful review of the application code to be really certain everything that is necessary, and even then, it's easy to overlook something.

And, it's easy to damage something when forcing logic....

It would be necessary to be able to see the Mark VIe application code, the synch circuit and gen breaker close circuit to be able to comment on an exact method--but the above should give you some idea of what's required if you want to get a gen breaker close output from the Mark*. (In the early days of the Mark VIe it was--UNFORTUNATELY--possible to force the gen breaker closure relay output. I SINCERELY hope that has been corrected--because it should never have been allowed in the first place.)

The generator breaker should be in the TEST/DISConnect position (meaning the primary (high voltage (high tension)) disconnects must NOT be connected to the bus bars, but the breaker control circuits must be connected and the breaker must be capable of being electrically opened and closed for any kind of simulation.

That's all I can really say about this without being able to see the site configuration and application code. PLEASE be very careful!

You need not to say sorry. You were the one who told me that we are going to face this. At least I was ready, although everyone else was reluctant to accept this. Now after seeing the application code everyone is noticing the changes.

We have not yet simulated the deadbus. I will give the feedback as soon as we will perform the simulation. Meanwhile I want to discuss the synchronization process.

I want to discuss the how synchronization in done MarkV and MarkVIe. I am not expert in this as I am going to read this first time in DETAIL. Please be patient if I am wrong anywhere.


In MarkV three relays are used for Auto/Manual synchronization. These relays reside on TCTG card. These relays are

1. 25 (Auto Synch Relay)
2. 25P (Synch Permissive Relay)
3. 25X (Synch Check Relay)

Although these relays reside on TCTG card, 25P and 25X are actuated (goes to "1") based on the logic in <Q> cores whereas relay 25 is actuated (goes to "1") by the <X>, <Y> and <Z> cores.
For auto synchronization Breaker Coil is connected across terminal 38 and 41 of PTBA card. Breaker voltages are come at PTBA terminal 35 and they will go to terminal 38 through logic in which all the three relays 25, 25P and 25X are in series for auto synchronization. All these three relays must be "1" for auto synchronization. (I will discuss later what logic will make them "1" and for how long they will remain "1".)<pre>
PTBA 35 25 25P 25X PTBA 38
o-----------| |----------| |---------| |----------o--------------------
(Breaker coil)
PTBA 41</pre>
For Manual Synchronization/ Dead bus breaker closure, Breaker Coil will remain connected across PTBA 38 and 41. We have Manual Synchronization / Dead bus breaker closure wire connected at PTBA terminal 42. The manual breaker closure command will go to the terminal 38 when the Manual Breaker Closure button is pressed and relay 25X is actuated (is "1") at that time.<pre>
PTBA 35 25 25P 25X PTBA 38
o-------------| |-------| |-------------| |---------o--------
| |
(Manual command) PTBA 42 o-------- (Breaker coil)
PTBA 41</pre>

<b>Mark Vie</b>

MarkVIe also has three relays for Auto/Manual synchronization. For MarkVIe these relays reside in TTUR. (MarkV has <P> core with TCTG and 3 TCEA cards (i.e. <X>, <Y>, <Z>). Emergency and Primary trip relays (ETRs and PTRs) were physically present in TCTG card in <P> core. Trip solenoid was connected to TCTG and trip was initiated either ETRs or PTRs were actuated. ETRs received signals from <X>, <Y> and <Z> while PTRs received signals from <R>,<S> and <T>. MarkVIe does not have <P> core. It has four cards for synchronization and tripping. These are TRPG, TREG, TTUR and TPRO. TRPG has all the PTRs and TREG has all the ETRs. Yes, one wire of trip solenoid is connected to TRPG while second wire of trip solenoid is connected to TREG card. I guess TCTG has been replaced with two cards (TRPG and TREG) in Mark Vie. TRPG receives signals from <R>, <S>, <T> controllers via TTUR while TREG receives signals from TPRO(<X>, <Y> and <Z> replaced with TPRO?)

These three relays are
1. 25 (Auto Synch Relay)
2. 25P (Synch Permissive Relay)
3. 25A (Synch Check Relay) {This relay was named as 25X in MarkV}

All these relays reside in TTUR. The breaker coil is also connected to TTUR.

Relay 25P is directly driven from controller application code. It is connected to the <R>, <S> and <T> controllers via IO Packs PTUR.

Relay 25 is driven from PTUR auto synch algorithm, which is managed by <R>, <S>, <T> controllers.

Relay 25A receives signal from TPRO (TPRO is connected to TREG and TREG is connected to TRPG AND TRPG is connected to TTUR).

In MarkV 25X is driven from <R>, <S> and <T> cores and its logic was present in CSP. In MarkVIe they have renamed it to 25A and it is driven from TPRO. It is also called backup synch check relay. Are relays 25P and 25 performing the same function? Were they having the similar function in MarkV as well?