Bonsoir a tous,
je viens par ce courrier vous soumettre une préoccupation que nous rencontrons depuis maintenant 2 mois sur une turbine de frame 6 avec le Speedtronic MARK V avec un interface opérateur HMI Cinplicity.
Nous constatons des alarmes diagnostiques sur le contrôleur S
Voir en fichier joint une vue sur les alarmes, bonne réception.

 

dsj,

Okay; while this doesn't seem to be a complete list of Diagnostic Alarms--it is a start.

Based on the partial page of Diagnostic Alarms provided, it looks like <S> processor believes the unit should be tripped, and so it's only the two-out-of-three hardware voting relays (physical, electro-mechanical relays) on the TCTG card in <P> which is keeping the unit running (because it won't start like this, unless you're doing some not-so-smart things....).

The big clue is the value of logic signal L4CT in <S> is different from the values in the other controllers. L4CT is a signal which comes from "The Customer" and is meant to trip the turbine. Usually, this signal is a discrete input (a "contact input) to the Mark* and it comes from a DCS (Distributed Control System), or BOP controller (Balance of Plant). If the gas turbine is driving a compressor it might be coming from the compressor control unit/system. In a TMR Mark* the discrete input signal which drives L4CT should be connected to the <QDn> core (either <QD1> or <QD2> as either of those discrete input cores will send the signal to all three control processors for each control processor to use to decide what action to take (in this case, whether or not the turbine should be tripped)).

There are several other signals which could also result in a turbine trip, not individually, but in conjunction with other signals--but in my personal opinion the "offending" signal is L4CT. Most of the voting mismatch logic signals are related to other discrete inputs (contact inputs) from other systems and field devices. So, it would appear that something is amiss with a component in the <QDn> core these inputs are connected to.

The inputs are terminated on the DTBA or DTBB I/O terminal boards in Loc's. 6 & -7 of the <QDn> core. You would do best to use an ASCII text editor (such as MS-Notepad) and open the file UNIT1\IO.ASG to determine which core these signals are terminated on, and which I/O terminal board they are terminated on. When you exit the file after finding the core and terminal board, close the file without saving any changes (if it asks--you shouldn't have made any changes, but if you inadvertently did then not saving them will protect against any future problems which might have been caused by inadvertently making any changes).

The discrete inputs are connected to the DTBA/DTBB I/O terminal boards, and there are ribbon cables that connect the DTBA and DTBB terminal boards to the TCDA I/O cards in Loc's. 1, -2 and -3 of the <QDn> core. I will guess that the TCDA in Loc. 2--which is connected to/associated with <S>--is having a problem. A COMPLETE list of Diagnostic Alarms from the GE Mark V HMI would probably have shown that there is some issue with TCDn for <S> (TCD1 would be the TCDA I/O card in Loc. 2 of <QD1>, and TCD2 would be the TCDA I/O card in Loc. 2 of <QD2>). The TCDA I/O card in Loc. 2 is mounted on the back of the first card carrier of the <QDn> core. So, you're going to have to open the appropriate <QDn> core door, slide the latches at the bottom of each side of the top of the core towards you, and carerully lift the first card carrier up and tilt it forward to be able to see the TCDA I/O card in Loc. 2 (the one connected to/associated with <S>). I would also guess that the LEDs on the bargraph in the corner of the TCDA I/O card in Loc. 2 are flashing in a different pattern than the LEDs on the bargraphs on the TCDA I/O cards in Loc's. 1 and -3 (which is another indicator that something is amiss with the TCDA I/O card in Loc. 2).

Now, you have a choice. You can--or at least you should be able to--replace the TCDA I/O card in Loc. 2 without shutting the unit down or tripping it. BUT, without being able to see the other Process- and Diagnostic Alarms which are active to be able to say if it looks there might a problem if you do that--I don't recommend trying that.

The next choice is to try re-booting the <S> processor--using the <S> processor's power switch in the <PD> core. This might reset the I/O card, and it might not, but if you can't shut the unit down it is an option. But, again, without being able to see the other Process- and Diagnostic Alarms it is risky and the unit might trip.

The last choice, and probably the most prudent one, is to shut the unit down in a orderly fashion (presuming you have a spare TCDA I/O card) and swap out the card with the spare. This involves powering down <S> processor (again, by using the switch in the <PD> core), removing the failed TCDA I/O card from the <QDn> core, carefully removing the two large integrated circuit chips from the card being replaced and carefully installing them on the spare card which is being installed (paying attention to be sure the chips are oriented properly on the sockets, and that no chip legs are bent or broken), installing the "new" card back in Loc. 2, and then powering <S> back up again. It IS NOT necessary to download anything to <S> before or after replacing the TCDA I/O card.

Now, all of the above is based on the information provided. You didn't say what troubleshooting had already been done--nor what the results of the troubleshooting were (both very important pieces of information). You didn't provide complete screen captures of ALL of the Diagnostic Alarms, and none of the Process Alarms. So, the above is a pretty basic description of what the problem MIGHT BE. Other circumstances which you didn't tell us about might change the recommendations above. But, the recommendations above are the best ones to be made based on the information provided.

Hope this helps! Please write back to let us know what your find and how you progress in resolving the issue.

 

Bonjour à tous
Pour la résolution des alarmes diagnostiques voici les différentes étapes qui ont été suivies:
Arrêt de la turbine et mise hors tension de l'armoire MARK V.

• Permutation des câbles plats dépendants DTBA du QD1 au contrôleur R et S: permutation au niveau de la carte DTBA des câbles JQR et JQS.
• Mise sous tension de l'ARMOIRE MARK V, constat: Les alarmes diagnostiques du contrôleur S ont tous disparue et apparition des mêmes alarmes diagnostiques sur le contrôleur R.
• Problème sur la sortie de la carte DTBA
• Récupération d'une nouvelle carte DTBA et comparaison avec la carte montée, constat: Relais débrochable KS dans une position renversée par rapport aux relais KR et KT repositionnement du relais KS et mise sous tension de l'ARMOIRE MARK V plus de présence alarme diagnostic sur les contrôleurs R, S et T. Merci pour vos réponses.
• 

 

Google Translate wasn't much with understanding this.

There should be at least two (2) DTBA cards in the Mark V turbine control panel (presuming it's controlling and protecting a GE-design heavy duty gas turbine)--one for <Q>, <QD1>, and one for <C>, <CD>. They should both be the same--physically and in every respect.

I have personally never examined the DTBA cards so closely, so, I can't say one one or another if this is normal or not. To my recollection, the yellow relays highlighted in you photo are NOT removable--they are soldered in place. Now, that may have changed with newer DTBA, but I think it's not very likely. (One has to remember, these same cards are used in TMR and SIMPLEX turbine contro configurations, so that may have something to do with the orientation of these relays. Just a SWAG (Scientific Wild-Arsed Guess).)

I don't have a recommendation or an answer--because I can't really understand what's happening. French is not my third, or even fifth, language. And, this is primarily an English technical forum (and Google is not all that good at translating technical sentences or words or terms or descriptions).

Anyway, I think if you think the problem is the orientation of this relay on one card is the source of the problem--you're wrong. But, again, since I don't really understand the problem or what you're trying to tell us with this post, I don't think I can be of any further help.

I suspect something is wrong with the DENET and/or the IONet. The DENET is what allows communication between the control and communication processor, and the IONET is what connects the I/O card associated with a particular control or communication to the I/O in other cores (for example, the <R> IONET connects it to the I/O on the TCEA in Loc. 1 of <P> and to the I/O of the TCDA card in Loc. 1 of <QD1>, and with the I/O of the TCDA card in Loc. 1 of <QD2> (if so equipped). The <S> IONET connects it to the I/O of the TCEA in Loc.2 of <P> and to the I/O of the TCDA in Loc.2 of <QD1 and the TCDA in Loc. 2 of <QD2> (if so equipped). And the IONET of <C> connects it to the I/O of the TCDA card in Loc. 1 of <CD>.

Failing that, I would think there's something wrong with the DCC/SDCC card or its PROMs in <R> and/or <S>, maybe even <C>. I can only imagine how many downloads you have done to <R>, <S>, <T> and <C> (a very high count, probably), and that not every download's messages were closely monitored for any error messages. We also don't know what other Diagnostic Alarms are present and unresolved.

If I recall correctly, the IONETs of <Q> pass through the TCQC card in Loc. 4 of each processor, and the IONET of <C> passes through the TCCA card in Loc. 2 of <C>. Those might also be suspect. But, I don't think a socketed (unremovable and unchangeable) relay on the DTBA is the source of the problem. We don't know what the entire part numbers of the DTBA card being removed and the DTBA card being inserted in it's place are. We also don't know about 125 VDC battery ground alarms on the panel and/or it's I/O, or other I/O connected to the same battery powering the Mark V in question.

There's just too much we don't know, and with the language barrier it's likely we aren't going to be able to do too much more to help. GE probably can't be too much help either, because they have lost or driven away most of the Mark V-experienced people in their employ--and they don't want to support the Mark V; they would rather sell you a Mark V-to-Mark VIe Life Extension, or a Mark VIe turbine control panel (do not buy the Life Extension product if you don't like the Mark V in its present form--you have been warned).

Best of luck; I hope you can write back soon with better news--but please do write back with details of how you fare in resolving this issue.

 

Good morning all
The problem of diagnostic alarms on controller S has been resolved. For the resolution, here are the different steps that were followed:
- Turbine shutdown and MARK V cabinet power off.
- Permutation of DTBA dependent flat cables from QD1 to the R and S controller: permutation at the DTBA card of JQR and JQS cables.
- Switching on the MARK V CABINET, observation: The diagnostic alarms of controller S have all disappeared and the same diagnostic alarms appear on controller R.
- Problem on the output of the DTBA card Recovery of a new DTBA card and comparison with the mounted card, observation: KS withdrawable relay in an inverted position relative to the KR and KT relays repositioning of the KS relay and energizing the MARK V CABINET more diagnostic alarm presence on the R, S and T controllers.
I confirm that the KR, KS and KT relays are removable.
Thank you for your attention.

 

Thank you for the feedback! It seems unusual for a Mark V I/O terminal board to have socketed components; that was not done in the early stages of the Mark V product life. It's even more unusual to find a socketed device that isn't keyed or designed to prevent improper insertion, but it's not unheard of, either.

Congratulations on finding the problem, and thanks very much for sharing the resolution with us!!!