Mark V panel supply was isolated for maintenance work. Power were restored on <R, S, T> core it had reached A7 status. When <C> core was power up it stayed on A4 status.

The <C> I/O status was checked and it responded below.<pre>
obj card maj min I/O cfg qst cfg cfg eep rsp msg msg
ID name rev rev stat stat ID flgs tics ofst type seq stat
-----------------------------------------------------------------
1 TCCA 04 06 A4 C2 20 01 0000 00 00 0000 00
2 **** FF FF FF 00 23 00 0000 00 00 0000 00
3 **** FF FF FF 00 24 00 0000 00 00 0000 00
4 **** 00 00 A1 00 21 00 0000 00 00 0000 00
5 **** 00 00 A1 00 21 00 0000 00 00 0000 00
6 **** 00 00 A1 00 21 00 0000 00 00 0000 00
8 LCCb 04 05 A4 C2 5 01 0000 00 00 0000 00
12 DCCb 07 04 00 00 26 00 0000 00 00 0000 00
13 IOMA 04 05 A3 00 21 00 0000 00 00 0000 00
14 **** 00 00 A1 00 21 00 0000 00 00 0000 00
15 **** 00 00 A1 00 21 00 0000 00 00 0000 00
16 **** 00 00 A1 00 21 00 0000 00 00 0000 00
17 **** 00 00 A1 00 21 00 0000 00 00 0000 00</pre>
There are two error found.<pre>
---- System error counters ----
System error cntr 34: 1 :- DCC IO reset
System error cntr 36: 1 :- --Default sys--</pre>

The Voters ID was checked and it has a 'C' id. The StageLink ID was the same as in the config.dat file.

The SDCC card on <C> core was replaced but give the same I/O status. To remove doubt whether the SDCC card replaced on <C> is working, I had removed the <T> core SDCC card which were having A7 status. Exchanging the PROMS and EEPROM on both card and installed SDCC from <T> on <C> core. The <C> core was rebooted and it has stay the same on A4 status. The removed SDCC card from <C> was installed on <T> core and it has reached A7 status when powered up.

The card id was checked but SDCC and TCDA responded without id.
System is Mark V, type 'B'<pre>
C-TCCATCCA 4.6 ) C-TCCB ) C-320b )
C-sLCCLCCb 4.5 ) C-sDCC ) C-TCDA )
C-IOMAIOMA 4.5 )

R-TCxxTCQA 2.6 ) R-TCxxTCQB 1.4 ) R-320bTCQB 1.1 )
R-sLCCLCCq 4.5 ) R-sDCCDCCq 7.4 )
R-IOMAIOMA 4.5 ) R-TCPA ) R-320p )
R-TCD1TCD1 3.9 ) R-TCD2TCD2 3.9 )
R-TCE1TCE1 5.3 ) R-TCE2 ) R-TCE3 )

S-TCxxTCQA 2.6 ) S-TCxxTCQB 1.4 ) S-320bTCQB 1.1 )
S-sLCCLCCq 4.5 ) S-sDCCDCCq 7.4 )
S-IOMAIOMA 4.5 ) S-TCPA ) S-320p )
S-TCD1TCD1 3.9 ) S-TCD2TCD2 3.9 )
S-TCE1TCE1 5.3 ) S-TCE2 ) S-TCE3 )

T-TCxxTCQA 2.6 ) T-TCxxTCQB 1.4 ) T-320bTCQB 1.1 )
T-sLCCLCCq 4.5 ) T-sDCCDCCq 7.4 )
T-IOMAIOMA 4.5 ) T-TCPA ) T-320p )
T-TCD1TCD1 3.9 ) T-TCD2TCD2 3.9 )
T-TCE1TCE1 5.3 ) T-TCE2 ) T-TCE3 )
</pre>The PROM set revision on <C> core were same as indicated in card ID. They were as below.
1. DS200GASCF1BGD
2. DS200IOMAF1BDE
3. DS200DENCF1BDE
4. DS200TCCAFIBDF
5. DS200TCDAF1BCI

The cards LCCB, TCCA, CTBA and TCDA were all replaced one at a time but there is no improvement on the I/O status.

The 3PL and 8PL ribbon cables were replaced from working <T> core. It ha no improvement as well on the I/O status.

The TCPS and SDCC voltage rating on test points were as per the table listed in GEK-5980.

The 8PL pin 1 was measured and got 3.3 Vdc from full up resistor of 330 ohms.

The DCCA PROM sets U11/U12 & U22/U23 with pre-programmed from GE of same revision but did not solve the issues.

The EEPROM chip (U9) on SDCC was replaced with new one. The Voters ID and Stage Link were set for <C> core. I had download the FORMAT and later the ALL options. Rebooted the <C> core but still remained in A4 status.

The card id was run and SDCC and TCDA still not reflecting the card id's.

I have tried all sort of troubleshooting which worked from other sites I have been thru but on these one exhausted all checks I had known.

Please help and guide me which I may been missing to correct the problem on this one.

 

benjovr,

Good information; thank you very much!

I wrote this information in another current thread:

http://control.com/thread/1451388037

But, it's easy to copy-and-paste, so here it is; I don't have any other ideas since the problem/site seems to be the same....

- - - - - - - -

WOW! If you've replaced all of those cards, and the PROMs, and the TCPS card, then I'm stumped, too, but I have some ideas--keep reading.

If the StageLink ID and Voter ID were wrong, you couldn't talk to the Mark V from the <I>/HMI. Have you used the SLCC keypad to check the I/O States of the cards?

As I say near the end, I would be trying to isolate <C> from everything else at this point. I would suggest reading through the ideas below, then developing your own "most likely to succeed" list of activities, and working through them one by one until you've tried them ALL. Just remember to write down every step you take--and the findings. It will be helpful as you try to restore everything when you've finally found and resolved the problem.

If there's an EX2000, have you disconnected that coaxial cable from <C> and tried cycling the power on <C>?

Myself, I have to believe it's a cabling problem--and I still suspect the 3PL cable. Either that or something is causing the power supply voltages on the SDCC card to be "pulled down" (less than they should be) on the SDCC, or on the SLCC. But, I've suggested some things to try below.

Have you tried unplugging the power supply cable from the TCDA in <CD> and also the <C> IONET cable? I think there are IONET termination resistors and hardware (Berg) jumpers on the TCCA card, you might also try temporarily setting those jumpers to IN and unplugging the IONET cable from the TCCA (presuming I'm right about the IONET to <CD> terminating on the TCCA; I don't any Mark V Signal Flow Diagrams to look at at this writing, and it might connect to the CTBA; you need to refer to the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195). This would completely isolate the TCDA from <C>, but it's only a long-shot guess at this point.

Are you absolutely certain that the TCPS in <C> is properly grounded (earthed)? In other words, if you disconnect the white ground (earth) cable (when the power to the TCPS is isolated from <PD>) and measure the resistance of the wire to ground (earth), it should be pretty near zero ohms.

I believe the 3PL cable connects the SLCC to the SDCC to the TCCA. And, it seems <C> can see the TCCA.... I'm just thinking "virtually" at this point....

I don't recall what the 8PL cable does; again, I don't have access to any Mark V manuals right now.

Have you tried using the SDCC card from <C> in <T>? You would have to change the PROMs and if you didn't change U9 you would also have to change the Voter ID, and FORMAT, then ALL. (Don't forget to upload the TOTD information first from <T>!). This would tell you if the SDCC card you are using for <C> is bad or not. It's a start, eh? If you're presuming the card(s) you've been using are good, and they're not, well then that's a problem. AND, if the card does work in <T> (<T> gets to A7) then you definitely know it's something wrong with power supply and/or cabling in <C>.

Have you tried disconnecting all of the I/O from the CTBA card? You can't unplug all the ribbon cables from the CTBA card, because at least one of them, I believe, connects the CTBA to the SDCC (perhaps through the or directly to the SDCC (I can't recall), but if there's some extraneous voltage or high-frequency signal getting into <C> from it's analog I/O....

Have you tried disconnecting the DENET cable from <R> to connects, I believe, to the TCCA card? I think it's an unshielded twisted pair cable, with a two-pin connector.

That's about it. If you can be certain the SDCC (and perhaps even the SLCC) are good (by substituting them into <T>), then it certainly seems it has to be cabling or power supply voltage(s). Unfortunately, you can't see Diagnostic Alarms in <C> (probably), so that's not going to help. Have you tried using DIAGC to look at any of the cards/PROMs in <C>?

I would be trying to just isolate <C>, even powering down <R>, <S> and <T> and <P>. You may even need to remove the power to ALL of the discrete inputs (including <QD1> and <CD>), and the solenoid output power (to both <QD1> and <CD> as part of this isolation of <C>.

I would also be trying to understand what changed during the maintenance outage that might have caused this problem. Have you looked at all the circuits that were disconnected and then reconnected during the outage when the power to the Mark V was removed?

Was anything else done in the Mark V during the outage--ANYTHING? Any wiring "disturbed" in the Mark V, or in the field?

I've just never run into this kind of problem before. Ever. I would suggest using the SLCC from <T> (since you've also borrowed the cables from that processor for this troubleshooting), but I'm worried about possibly damaging that card, but at this point, it's worth a try--but after first trying one of the SLCC cards removed from <C> in <T>. You'll have to change the SLCC PROMsets, but it's worth a try at this point. If the card(s) don't work in <T>, then that's something else you didn't know before. I don't know what it tells you--other than the SLCC cards are bad. Though not likely, I'm wondering .... about the only component you haven't tried replacing is the SLCC keypad....

It's a VERY long shot, but have you disconnected the coaxial cable from the <I>/HMI to the CTBA--at both ends--and meggared the main conductor to ground (earth), as well as the shield/connector body? Have you just left the StageLink (coaxial) cable disconnected from CTBA and powered-up <C>?

PLEASE write back with information--hopefully even the resolution. Perhaps someone else reading this can provide some ideas. I'll try to think of anything else to try, but at this point, I think trying to prove the SDCC and SLCC cards you're using in <C> are good, and by trying to isolate <C> as much as possible from everything else in the Mark V is the best course--about the only course I have to suggest. Unfortunately.

BEST OF LUCK!!!