Control.com - Nerds in Control

Mark-V T-core I O status on LCC displaying
(4) **** - A1
(15)**** - A1

T-core should be in A7 status but it has stuck in A6 status.

There was lightning and thunderstorm yesterday in our area during which the machine tripped. There was no tripping alarm except - Generator breaker tripped from TCP.

After thorough check of process alarm, we started the machine but starting device tripped immediately on giving start command showing machine coasting down (with unusually TNH-RPM showing 50 RPM on the <I> station screen). On further check we found one speed sensor has got problem.

We reboot the Mark-V cores. After reboot the T-core status stood on A6 status, while all other cores (C, R & S) are on A& status.
We replaced TCEA (Loc-5) in P core and TCDA (loc-3) in QD1 core but could able to rectify the problem

Please suggest remedial at the earliest.

I believe (I don't have access to a Mark V operator interface at this writing) that Socket 4 is for the TCEA card, and Socket 15 is for the TCDA card.

The interesting thing here is that the IONET runs from the control processor (in this case <T>) to the TCEA in Loc. 5 of <P>, and from the TCEA in Loc. 5 of <P> to the TCDA in Loc. 3 of <QD1>. And you say you're replaced the TCEA in Loc. 5 and the TCDA in Loc. 3.

From the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195, and from Chapter 2 of the Mark V Maintenance Manual, GEH-5980, the IONET "originates" in the control processor on the DCC/SDCC card, passes through the TCQC card, then to the TCEA card, then to the TCDA card in <QD1>, and to the TCDA card in <QD2>, if so equipped.

It would have been nice to know what Diagnostic Alarms were present before the processors were re-booted, and after they were re-booted. (It's always good to check the Diagnostic Alarms, or at least to record them and put them in the post when posting to control.com.)

Without knowing what Diagnostic Alarms are present, my first guess is that the IONET cable that attaches to the TCEA card is either not properly connected to the TCEA card in Loc. 5, or the IONET termination resistors on the TCEA card in Loc. 5 are in the wrong position (they are IN when they should be OUT), or something is amiss with the IONET cabling between the TCQC and the TCEA. It could also be that the IONET termination resistors on the TCDA card are OUT when they should be IN, but that's a longshot though still a possibility.

Write back to let us know how you progress.

There was diagnostic alarms such as voting mismatches referring to <S>. but no unusual alarms.

We swapped the TCEA at loc-5 in P core and TCDA at loc-3 in QD1 core with the cards corresponding to R - core. While the R-core status came to A7, the T core status remained at A6 with earlier IO status.

From your view of signal flow, we swapped the SDCC along with SLCC of T-core with that of S-core. it was observed that while T-displayed A-7 status, S-core status stuck to A6.
The diagnostic narrowed to SDCC or SLCC card.

We now interchanged the SLCC card of T & S core. The status remained same i.e, T in A7 status and S in A6 status. This conformed that problem was in SDCC card.

We replaced the faulty SDCC card with new one in T-core. But LCC displayed - Bad EEPROM. When we replaced the U9 eeprom (which was originaly supplied with card) from the old/ faulty card, the status of core observed at A7 .

The diagnostic voter mismatch were due to faulty TCPS card as replacement of TCDA card does not changed the status of alarms. On replacement of TCPS card in S-core all alarms were reset.

Thanks for the feedback!