Mark V Diagnostic Alarms

I

Thread Starter

Ivan

Hello everybody,

Time to time There are two diagnostic alarms on Mark V TMR control panel:
C 3784 Voter mismatch, <S> SVL
C 4045 Voter mismatch, <T> SVL
C 3523 Voter mismatch, <R> SVL
C 3783 Voter mismatch, <S> DV
C 3522 Voter mismatch, <R> DV
C 4044 Voter mismatch, <T> DV

For example, SVL can appears for <S> and then disappears. Then it can appears for <T> and then disappears. Never it comes simultaneously for two or three controllers at the same time.
The same situation for DV.

I suppose that there are not any problem with PTBA, TCEB or <X>, <Y> and <Z> TCEA cards as all three controllers <R>, <S> and <T> have the same behaviour. Also, TCEB and one TCEA card were replaced few weeks ago due their failure. The same alarms were present before cards replacement as well.
All ribbon cables are ok and their contact/connection as well.

I didn't find any description for these Diagnostic alarms numbers in the HELP_QD file (what I have).

I have misgivings about the 125 VDC power supply quality only.
With oscilloscope I can see that there are some needle-shaped spikes with amplitude 5-9 Volts and frequency 100 Hz on 125 VDC (measured between positive and negative).

If someone have any ideas on it please advise.

With the best regards,
Ivan.
 
Ivan,

When do these alarms occur? During normal full speed operation with the generator breaker closed? At some point during start-up or shutdown? Some combination of the times?

Why did the TCEA cards fail?

You can trace the PT signals (SVL is the running or "bus" PT input; and DV is the generator PT input) in Appendix D of the Mark V Application Manual, GEH-6195 from the PTBA through the TCEB to the TCEAs. Has something changed in this circuitry recently (including the synchronizing circuit)?
 
CSA,

These alarms occur more often when generator breaker closed already (approximately every 2-3 hours). When turbine in stand-by only alarm SVL occurs very rarely (one time per day let say).

I was involved to troubleshooting on stage when they could not synchronize the unit.

I don't know the history how they damaged the TCEA card, but when I arrived to plant I found wrong signals for DIAG28 and DIAG29. Finally, I found that chip U34 (PI74FCT) on TCEA <X> is completely burned out. I have replaced this card, tested all termination and then unit was synchronized successfully.

Also, I solved some more issues to eliminate others Diagnostic alarms.
To get the Diagnostic screen empty I have to solve this issue with SVL and DV only :)

All terminations as per original design.

I traced all these signals from PTBA to all TCEA cards via TCEB and found all termination are ok.

I am going to check the GCPP panel side more deeply as well.
 
CSA,

Today I have investigated this issue more deeply by myself and found the next:
- All connections on the GCPP side are ok;
- Also, all connections in Mark V panel are ok as well.

I traced these signals from PTBA up to TCEA and TCQC cards and all connections are look ok.

Today, These alarms for SVL and DV were coming only for <R> module.
These alarms were coming every hour at 00 min 03 sec (only 16:00:03 passed without any alarms). During the time when alarms coming the Prevote Data Display shows that values SVL, DV and SFL2 for <R> module fall down to zero for few seconds.

Tomorrow I am going to check the SDCC card on <R> module.
 
Ivan,

When the generator breaker is closed it's typical for GE-designed synchronizing circuits (which is where the PT signals come from--on GE-designed systems) to open the Generator PT circuit, removing the generator voltage signal. This is because, essentially, the generator voltage is equal to the running (or bus, or grid) voltage so there will be little or no difference between the running/bus/grid voltage and the generator terminal voltage. So, that's probably why the DV Diagnostic Alarm doesn't toggle when the unit is running and the generator breaker is closed.

The TCEB and PTBA are common to the three TCEAs, so if the signal is coming in on all three processors it's possible that either the PTBA or the TCEB is damaged (you said you replaced the TCEB, but depending on the source of the TCEB it could be questionable; I've seen a lot of people take a card out of the warehouse, put in the panel and not see the desired change, and put the card they removed in the warehouse--when something else was wrong with that card. Then when that (supposedly good) card gets put in the panel at a later date for a different reason it's discovered the card is bad.

The two PT signals usually share a common neutral wire, so that could be the problem.

The signals from the TCEA cards get into <R>, <S> and <T> via the IONETs, but it's not really logical to assume the three IONETs are all experiencing intermittent problems (but--stranger things have happened!).

I can't think of too much else. The AC ripple on the DC supply could be coming from the filter capacitors on the battery charger; they do fail over time. Also, it could be that somewhere in the plant low voltage signal wires/cables are too close to high-voltage/high-current wires/cables and noise is being induced on the wiring. This can even happen with discrete (contact) input wiring--in fact, that's the most common cause of AC ripple and voltage on the DC supply (followed very closely by failing battery charger output filter capacitors).

I presume the DC supply does not have a serious, or intermittent, ground. Or, did it have a ground previously, for some time? (Usually, one only finds this out after a long time on site when people will begin to share more and more--and it conflicts with what was first told....)

Please write back to let us know what you find!
 
C
I once had a lightning strike in the switchyard and somehow voltage managed its way to the 125DC bus for breaker control 52G.

Similar problems as far as Diag Alarms.

Burned the terminal strip PTBA on <P> core. Spent a lot of time troubleshooting because the terminal strip looked OK until we looked at the back of it.

Looking at the back can be accomplished without lifting wires.
 
Often when cards are zapped by stray voltages, the isolation circuits (caps) can hold charge that affects reference level of some circuits.

Depending on the circuit, the threshold or trigger points then are affected.

Recent example. Troubleshooting a flow meter that was zapped by stray voltage, where it showed flow when there was none.

The fix...disconnect from power source and short circuited all pins to the circuit board common.
 
Ivan,

We had a similar problem last year. We we're getting Voter Mismatch alarms for SVL (Bus Voltage) and SFL2 (Bus Frequency). We finally traced the problem to the PTBA terminal board. Replacing the PTBA terminal board cured the problem.

Good Luck!
 
Hello everybody,

I investigated this issue with SVL and DV sirnals during these holidays on shutdown Unit and found:

- This is not problem with some terminations, interconnections on <P>, <R>, <S> or <T> modules. All of them are ok;

- There are not any problems with any cards;

- There are not any issues with some noise as well.

I fabricated the ribbon cable JDR (between TCTG <P> and TBQA <R>) with switch on wire #14 (BUS Voltage signal) to have a possibility to switch

off this signal for module <R> at time when I want it.
If switch off this line then two alarms will be generated by module <C> immediately:

C 3523 Voter mismatch, <R> SVL
C 3525 Voter mismatch, <R> SFL2

On Prevote Data Display these two values for <R> are falling down to zero as well. This is the normal operation of modul <C> to detect that something wrong with this signal on one of three modules.

In my case when Unit in stand by or in operation and synchronized with with the network this SVL alarm is coming exactly at the same time points

(almost EVERY hour at 00 minutes 03 seconds). Also, only SVL and DV signals coming without SFL2. It means that their source is ok.

It seems to me that module <C> is performing something at this time (self diagnostic, Denet test etc) and can't read properly those signals from

<R>, <S> and <T> modules. Because, the SVL alarm some time coming for <R>, sometime for <S> and sometime for <T>.

To simulate this time point XX:00:03 (to prevent wait 1 hour) I changed the system time for Mark V panel to XX:59:00 many times and then was

waiting one minute to point XX:00:03.

During these investigations were possible four situations on Prevote Data Display and Diagnostic alarm display:

1) SVL, DV, SFL2 for all three modules <R>, <S> and <T> are falling down to zero simultaneously and then no any diagnostic alarm were generated;

2) SVL, DV, SFL2 for all three modules <R>, <S> and <T> are not changing at all and then no any diagnostic alarm were generated;

3) SVL, DV, SFL2 are falling down to zero for one controller only. Two others controllers show normal values and then I receive the diagnostic

alarms for SVL and DV for that one controller only;

4) SVL, DV, SFL2 are falling down to zero for two controllers. Another controller shows normal value and then I receive the diagnostic alarms for

SVL and DV for this one controller.

I tried to swop SDCC and SLCC from module <C> to module <T> but situation with alarms is the same.
Probably, something wrong with software in EPROMs or some old version with bugs.
They are using on <C> next version of PROMs:<pre>
U11 DS200GASCF1BGB 02
U12 DS200GASCF1BGB 01
U22 DS200IOMAF1BDC 01
U23 DS200IOMAF1BDC 02
U6 DS200DENCF1BDB 01
U7 DS200DENCF1BDB 02</pre>
Can some one send to me their dumps of these version then I can compare to make sure that nothing wrong with my PROMs.

I could not find any checksum on their stickers and as result not able to conclude that they are ok.
 
Hello everybody,

I solved this issue by upgrading the Firmware of DENQ, DENC, IOMA to ver.4.5.

In the same time the Firmware for TCDA, TCCA and TCQA cards were upgraded as well.

With the best regards,
Ivan.
 
Ivan, thanks very much for the feedback. Glad to see you stuck with this and were able to find a resolution for the problem of those nuisance diagnostic alarms. Hopefully your feedback can help someone else in the future.
 
Top