Diagnostic alarm

G

Thread Starter

guven

We have a GE frame6 gas turbine. For the last 3 days we have had a diagnostic alarm which is "Voter mismatch, <S> Q_C_MAO02" and also "Voter mismatch, <T> Q_C_MAO02". I couldn't find how this output is generated and what it controls. I checked the IO files but there is no device name for this output then i checked cabling diagrams but again no score. :( What can be the cause of it? Also can you give me information about the diagnostic alarm "TCCA Status S page xmit failure"?

Best regards.
 
The milliamp outputs of <C> are driven by <Q> (<Q> is the collective reference to <R>, <S>, and <T> in a TMR Mk V turbine control panel and <R> in a SIMPLEX Mk V panel). The assignments and scaling of the signals are made in MAOUT_Q.SRC (again, because the signals--even though they are terminated on the CTBA terminal board of <C>--are driven out of <Q>.

Q_C_MAO02 stand for: associated with <Q>'s CDB (Control Signal Database); terminated on <C>; milliamp output #2. (C_CD_CI84 would be read as: associated with <C>'s CDB; terminated on <CD>; contact input #84. And so on...)

It was very common for these outputs to be assigned in the field as some plant start-up person or plant DCS person (usually a Texas native working outside of Texas...What's up with that, anyway? If Texas is so great, why aren't they there?) said, "You MUST provide us a 4-20 mA signal for exhaust temperature or gas fuel flow-rate or speed or ... and you must do it immediately, if not sooner!" (usually because they forgot to specify it was needed during the requisition process...so poor planning on their part constituted an emergency on someone else's part!). Many times the start-up/commissioning engineer didn't make the necessary modifications to TC2KREPT.TXT (the "I/O Report" file) when this was done in haste. (TC2KREPT.TXT is one of the few files that isn't part of the "self-documenting feature" of the Mk V; oops, the questions are going to come fast and furious now!)

So, you need to look in MAOUT_Q.SRC to see what signal is assigned to Q_C_MAOUT02 (the second milliamp output of <C> processor, terminated at CTBA-3 & -4). Then make sure the scaling is correct for the actual values of the signal assigned to the output (for example, that the value in the Mk V isn't lower than the minimum scale or higher than the maximum scale as explained in the comments in the file). In other words, that the output isn't trying to be MUCH LESS THAN 4 mA or MUCH GREATER THAN 20 mA as defined in the file. (If you have questions, copy the contents of the file into a reply and let us know what the actual values of the signal assigned to the output are when the alarms are being annunciated.)

Lastly, you need to make sure that the terminations are all secure and tight, and that whatever is connected to the other of the wire terminated at CTBA-3 & -4 is working properly.

Remember, the Mk V supplies the loop power for these mA outputs. Also, some DCSs and PLCs can't accept a signal such as this from a source like the Mk V and require a loop isolator between the Mk V and the DCS/PLC. Perhaps there's a problem with the loop isolator if one is being used.

Please, let us know what you find in any case. Feedback is what makes forums like this work--so that people who search for problems like this can see if the recommendations/answers provided actually worked or were a complete miss!

markvguy
 
<p>The following is from one of the Mk V Diagnostic Alarm Help files which have circulated:
<pre>
---------------------
;TCCA Status S page xmit failure


CAUSE In transmitting a Status-S page to another processor on the arcnet, the TCCA has detected an transmit error. Possible causes are:
1. message to send is too large.
2. network is unstable.
3. ARCNET card not initialized.

The diagnostic alarm is cleared when a successful transmission occurs.

ACTION Check that the <C> processor has been powered up and is running.
Insure that the TCCA arcnet cable is correctly wired.

---------------------</pre>
<p>Status S is the protocol which is used on the StageLink (the ARCnet-style LAN (Local Area Network) which is used to connect operator interfaces, Mk V turbine control panels, and GE EX2000 exciter regulators) for Mk V turbine control panels to communicate with GE EX2000 exciter regulators. (In applications which employed GE EX2000 exciter regulators, the exciter regulator was a "node" on the StageLink, along with the Mk V turbine control panel(s) and the operator interface(s) (&lt;I&gt;s or GE Mark V HMIs).

<p>(That's right, two protocols can be used on the StageLink--one for operator interface to Mk V communications, and another for Mk V to GE EX2000 exciter regulator communications.)

<p>This alarm has been annunciated at many sites which were NOT equipped with GE EX2000 exciter regulators, annunciated intermittently--sometimes several times in one hour, then not again for several months; sometimes once a day for a week, then not again for another year.

<p>If your site does not have GE EX2000 exciter regulators, this is a nuisance Diagnostic Alarm, which are also affectionately referred to as "Diagnasty Alarms."

<p>If your site has GE EX2000 exciter regulators, this could represent a real problem. Many times this author has found very poor BNC connector terminations cause this problem, as well as poor overall StageLink communications between the other nodes on the network. Oddly, for some reason, poor terminations seem to affect the GE EX2000 exciter regulators and the Status S transmissions between the Mk V and the exciter regulators more than the Mk V communications with the operator interfaces.?.?.?

<p>Inspect the BNC connector terminations everywhere on the StageLink. Presuming your site has GE EX2000 exciter regulators, make sure the BNC connectors in the exciter regulator enclosure good and properly terminated and are securely terminated on the GE EX2000 exciter regulator terminal board.

<p>Bad or improper coaxial cabling has also caused this Diag. Alarm. Refer to the GE Mk Application Manual for details on the type of cable to be used, as well as the minimum cable lengths (1 meter if memory serves correctly). Inspect the cabling to be sure that all pieces of the cabling are the proper type and meet all the specifications. (It's not unusual for electricians to ass-u-me that one piece of coaxial is the same as another--especially if there's a rush to get the job finished.!.!.!)

<p>markvguy
 
<p>here is the MAOUT_Q.SRC file;
<pre>
;*****************************************************************************
;signal mA_channel min_cnt max_cnt
;---------- ---------- ------- -------
;Q_C_MA001 Q_C_MAO01 0 32767
DWATT Q_C_MAO02 0 3840
;Q_C_MAO03 Q_C_MAO03 0 32767
;Q_C_MAO04 Q_C_MAO04 0 32767
;Q_C_MAO05 Q_C_MAO05 0 32767
;Q_C_MAO06 Q_C_MAO06 0 32767
;Q_C_MAO07 Q_C_MAO07 0 32767
;Q_C_MAO08 Q_C_MAO08 0 32767
;Q_C_MAO09 Q_C_MAO09 0 32767
;Q_C_MAO10 Q_C_MAO10 0 32767
;Q_C_MAO11 Q_C_MAO11 0 32767
;Q_C_MAO12 Q_C_MAO12 0 32767
;Q_C_MAO13 Q_C_MAO13 0 32767
;Q_C_MAO14 Q_C_MAO14 0 32767
;Q_C_MAO15 Q_C_MAO15 0 32767
;Q_C_MAO16 Q_C_MAO16 0 32767
;
;-----------------------------------------------------------------------------
;
; The values of min_cnt and max_cnt should be calculated as follows:
;
; (desired output signal value at 4 mA) - Offset
; min_cnt = ------------------------------------------------ * 32768 COUNTS
; max scale type value [Gain from SCLEDATA.DAT]
;
; (desired output signal value at 20 mA) - Offset
; max_cnt = ------------------------------------------------ * 32768 COUNTS
; max scale type value [Gain from SCLEDATA.DAT]
;
;-----------------------------------------------------------------------------
</pre>
<p>Now alarm is not active. But I couldnt check the voted values when the alarm occured. I check the terminations and wirings. it is OK now. I wait for your advices. Thanks....
 
DWATT Q_C_MAO02 0 3840

From the info you sent, it appears the second <C> milliamp output is scaled for 0 - 60.0 MW ((512 * 3840) / 32767). Did the unit's output--as sensed by the Mk V--go much above 60.0 MW or much below 0.0 MW?

Some versions of PROMsets didn't handle signals which were more or less than the MIN and MAX values very well... The normal method of shutting down a GE-design heavy duty gas turbine from load via a STOP command is to unload it until a pre-defined amount of reverse power (negative MW) is detected and then open the generator breaker. Is this occurring when the unit is being shut down?

Some units have three megawatt transcuders, each connected to the QTBA on <R>, <S>, and <T>. Some units use only two megawatt transducers, with one connected to <R>, <S>, and <T> by paralleling the input points and only using a single dropping resistor and connecting the other transducer to one of the other 15 mA inputs to <Q>, and then doing a MAX select in the CSP to derive the value of DWATT.

Were there any other Diag. Alarms active before or during the one related to the second <C> mA output?

How many megawatt transducers does your unit have?

Are all the megawatt transducers working properly?

Was this happening when the unit was running or when it was shut down?

markvguy
 
our unit's output never went above 60MW or below 0 MW. as you explained during shut down unit output reduces until -2 or -3 MW then the breaker of the generator open. this alarm occurs while the system is running, when this alarm occurs there isnt any more alarms related to the second <C> mA output lastly we have three megawatt transducers but i am not sure whether they work properly or not.
 
Okay; the unit's output never went above 60 MW nor below 0 MW--except briefly during shutdown (which is normal). But, if one, or two, of the MW transducers is operating intermittently then that could be the source of the problem.

Sometimes, the MW transducers were "self-powered"--that is, they derived the power to operate and generate the 4-20 mA signal from the PT inputs. Sometimes, the MW transducers required 120 (240) VAC from some external source. Usually, Diag. Alarms would be generated if the MW transducer inputs were not working properly or were not agreeing with each other....

The alarm occurs when the unit is running; not when it's shutdown. It is presumed the alarm is continuing to be annunciated intermittently, and it wasn't just a once or twice occurrence.?.?.?

There are no other Diag. Alarms related to the second <C> mA output. Are there any other Diag.- or Process Alarms related to the MW transducers?

When the Diag. Alarm is active (i.e., when the Alarm's Status Bit is a logic "1"), you will need to use the Prevote Data Display to check the values of DWATT for <R>, <S>, and <T>. What are they?

Most (but NOT all) units with three MW transducers had them connected to the <Q> MAI16 input, which is terminals -63 and -64 on the QTBA I/O terminal board on <R>, and <S>, and <T>. It is believed that each processor then chooses the highest value of the three and writes that value to DWATT (kind of like "voting" and choosing the maximum of the three values as the DWATT value).

The OS (operating system) in the Mk V control processors then uses the information from MAOUT_Q.SRC to assign a signal to a <C> mA output and scale that signal based on the information in the file, and the three processors then "vote" on the value and send that value to <C>, where it is converted to a mA output. It is believed that the signal(s) from <Q> are sent to <C> "digitally" (i.e., in software).

You've already said you've verified the wiring output from the <C> CTBA terminal board to it's termination, and the integrity of the device which is using the mA output is good. Is the device actually experiencing any unusual operation when the Diag. Alarm is annunciated and is active?

This is a very perplexing problem, as it's not clear how the signal(s) from <Q> travel to <C>, except over the DENET (Data Exchange NETwork) internal to the Mk V, so it's not clear what card(s) should be replaced to try to resolve the problem. It is suspected that the TCCA card in <C> is probably where the software signal gets converted to a mA output signal.

You asked about -TCCA Status S Page Xmit Failure' Diag. Alarms; did this alarm start occurring at about the same time as the C_C_MAO02 Diag. Alarms?

Sometimes, I/O-related Diag. Alarms have a time delay on them, meaning the alarm condition must exist for some period of time before the alarm is annunciated (a way of preventing nuisance alarms). The time delay can't be determined nor changed, nor even confirmed for any Diag. Alarm...

Yes, this is a very perplexing problem. When the alarm occurs, what period of time is it active for? Does it "dither" (change states very quickly)? Or, are they active for several seconds, or several minutes? Are both the <S> and <T> Diag. Alarms ever active at the same time?

Sorry to be asking so many questions, but it's difficult to imagine how this alarm occurs, and how to attempt to try to troubleshoot it! As was said before, the alarm was resolved on some units by correcting problems with the circuit connected to <C>... and you've said there aren't any problems with that circuit at your site....

markvguy
 
Dear Sir,

First of al i want to thank you for your effort to solve our problem (actually it is not a big problem but mixes our mind :)). I was on holiday and i could not reply you sorry for this. Let me Answer your questions.

For the last 3 months this alarm occured 9 or 1o times and while it is active there were no other diag or process alarms related to MW transducers. I tried to see the DWATT values from the prevoted data display but because of the alarm is "dither" i couldnt catch the values. The occurence times of the this alarm and the other diag alarm (TCCA Status S Page Xmit Failure)are not identical i think there is no relation between them. Anyway iam persuaded that the problem is about MW tranducers (at least i hope so) during the next shut down i will check them. I will tell you the result.

Best Regards
 
Top