Recently there was a problem on processor T of Mark V control system on a frame 9 power plant with state A8. changing the processor and Lcc/Dcc card and downloading the software on it did not fix the issue. Therefore the system was working with R and S processors since then.

Today we had to make some simple changes in the control sequence. After making the changes and compiling and them downloading to eeprom of R and S, everything seemed normal. but when we reset them, both of them remained in A8 state. The bigger problem is we can not download to them any more. since we didn't change any io configuration, this seems strange. Even the key pad on these processors does not work.

Any help is appreciated.

 

First question. Why are you continuing to operate without all 3 cores.
A8 I/O card initialization failure I/O card does not match type specified in configuration file.

Repair T core. Since Q is the collective of RST, I believe that the problem resides in T because i/o config(Q) programs all 3(RST).

 

This is interesting. The fact that the same problem is now being experienced on all three cores is indeed very odd. Very odd, indeed.

A8 is usually not a good indication, and if the keypads don't work as you say, then something is definitely amiss. I don't presently have access to and Mark V documentation, but I believe there was some information in the Mark V Maintenance Manual, GEH-5980, about I/O state indications and what they indicate.

There is a cable, 3PL I believe, that connects the LCC to the DCC to the TCQA, and the TCQB if it's present (if I recall correctly). I'm going to go out on a limb here and say that corrosion has developed on ribbon cable connectors/pins of the various processors, and most likely the 3PL cable, and this is inhibiting communications between cards over the interconnecting cables.

You might try (with the power to the processors off), carefully unplugging each ribbon cable connector and then plugging it back in and removing it again and plugging it back, repeating several times on each cable and each connector of each cable, to see if that has any positive effect. And I wouldn't just do this with the LCC and DCC cards and connectors, but would do it with all the cards and connectors in the panel.

Better yet, if you have some conductive grease (usually provided in the boxes with spare cards) you can try applying a thin film to the female end of the ribbon cable connector and then plugging it in to the connector, repeating the unplugging and plugging a couple of times to try to clean any corrosion and get the conductive grease to coat all of the pins and the insides of the connector sockets.

We can't know how clean the Mark V panel and cards are, nor how they have been maintained over the years, but dust and humidity and heat are not good to cards over time. It's just very odd that they have all chosen to exhibit the same behaviour at approximately the same time.

The only other thing I can think of is that there is something corrupt about the IOCFG portion of the EEPROM download that is causing the processors to think they are something they are not or that some card is present that isn't. But I have never actually seen a problem like this, I'm just thinking "out loud".

Oddly, you haven't mentioned anything about <C> and whether or not it's working properly. <C> and <Q> all communicate over the DENET, so that is something that's common to all the processors.

This is indeed very odd.

Please write back to let us know how you fare in your troubleshooting.