Today is...
Thursday, March 21, 2019
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
EtherCAT with CTC’s master lets your multivendor network play well together...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Mark 5 Processor Showing Faults
Mark 5 processor showing faults and alarms after restart

Dear all,

Could you assist me to solve the problem with our Mark V control system for gas turbine. we restart our controller to install the new changes was done on the system. One of the 3 controllers was hang after restore the power and showing some faults alarms like A4,00,A7.

please guide me ASAP because its related for production

thanks

1 out of 1 members thought this post was helpful...

hamed87,

There is a procedure in GEH-5980 for using the LCC/SLCC display and keypad for troubleshooting failures to reach I/O State A7.

You need to determine which I/O card or -cards are at the lowest I/O State and then resolve that condition, until all the cards get to I/O State A6--and then they will all go to A7. REMEMBER: Not all I/O cards associated with control processors are located in the control processor. The respective TCEA cards in <P> are associated with the three control processors, and the respective TCDA cards in <QD1> (and <QD2> if so equipped) are also associated with the control processors (via each control processor's IONET).

You really provided very little information--what was the "change" that needed to be downloaded and the processors needed to be re-booted?

Did you check for Diagnostic Alarms before you started downloading and re-booting? Once a processor goes to I/O State A7, if any card associated with that processor goes to something other than A7 the LCC/SLCC display will still show A7--and there will be Diagnostic Alarms annunciated to indicate that the card is no longer at A7. During starting (booting) every I/O card associated with a processor has to reach A6, and then they will all go to A7. But, if an I/O card associated with a processor changes I/O State after all the cards went to A7, the LCC/SLCC display will almost always still indicate A7--BUT there will be Diagnostic Alarms to indicate the card/problem. Checking for Diagnostic Alarms BEFORE downloading and re-booting is a way to identify problems BEFORE they result in issues like the one being reported here.

So, use the LCC/SLCC display and keypad to check the I/O States of the various cards. WRITE DOWN the Socket Numbers (the number to the left of the card name), the card names, and the states of all the I/O cards as you use the INC and DEC keys to scroll forth and back through all the I/O cards. If you still require assistance, you will need to post the Socket Numbers, the card names, and the I/O States you wrote down.

The controller S on the keypad showing in the errors A4 .
I tried to delete or clear the error but its gone for a minute and appear again

1 TCQA A4
2 TCQB A3
4 **** A1
5 **** A1
6 **** A1
7 TCQB A3
8 LCCQ A4
12 DCCQ 00
13 I0MA A3
14 **** A1
15 **** A1
16 **** A1
17 **** A1

When we try power up the controller, other cards R and C in the same status.

Also we changed the P for power card.

Until now same A4 error is there and we don't have permissive to start the turbine.

REGARDS

1 out of 1 members thought this post was helpful...

hamed87,

What the I/O States function is telling you is: The RAM on the DCC/SDCC card is most likely NOT getting the information from the EEPROM during boot-up. When it loads the I/O Configuration from the EEPROM it knows ONLY which I/O cards it should see--and it's looking for all of the possible I/O cards right now, which is the default when it doesn't know what I/O cards should be present and communicating.

That more than likely means the DCC/SDCC card must be replaced, which means you have to swap the PROMsets from the existing DCC/SDCC to the new DCC/SDCC card, and then once you install the new DCC/SDCC card and re-start the control processor, you need to use the 'Voter ID' function of the LCC/SLCC card to set the voter ID of the DCC/SDCC card, and then re-boot the control processor.

It will still probably only go to A4, so you need to download the FORMAT partition to the EEPROM, then re-boot the processor (from the <PD> core), then download USER to the EEPROM, then re-boot the processor (from the <PD> core), and it should then go to A7.

This should be a lesson to all reading this post: Check for Diagnostic Alarms on any control processor BEFORE downloading to and re-booting the processor. AND, also check for I/O States before downloading and re-booting. It can save a LOT of time, frustration and aggravation.

Please write back to let us know how you fare in resolving the problem!

1 out of 1 members thought this post was helpful...

hamed87,

When re-booting from <PD>, be sure to remove the power to the control processor, wait approximately 30 seconds, then re-apply power to the control processor. Don't just cycle the power switch very quickly.... That's NOT GOOD for the power supply card or the electronics on the cards.

Also, DON'T use the little white switch on the DCC/SDCC card when re-booting the processor. Just don't do it. Always re-boot from the <PD> core.

Be extremely careful when unplugging the cable that runs between the LCC/SLCC card, the DCC/SDCC card, and the TCQA card (and the TCQB, if so equipped, I believe). There are NO pull tabs on that cable, and when unplugging the cable from the sockets on the I/O cards the connections between the cable and the connectors can be easily damaged--increasing the probability of problems. The 3PL cable has a very short distance between the connectors for the LCC/SLCC card and the DCC/SDCC card, and this is usually where the most problems occur. Just be cautious when unplugging this cable--and when plugging it back in to the sockets on the I/O cards press firmly all along the top of the sockets to be as certain as possible that the connections are as good as possible.

FINALLY, if you are replacing I/O cards you should be using the grease provided with spare cards on the ribbon cable connectors. TOO MUCH GREASE is worse than no grease at all! The tendency is to "slather" a bunch of grease on the male part of the connector and push it into the female socket. Just wipe a consistent amount of grease--but not too much!--along the male connector of the ribbon cable, making sure that all of the pin sockets of the male connector have grease over them. Then it's a good idea to push the connector into the socket on the I/O card, remove the connector and push it back into the socket, and maybe do the same a third time. This helps to remove any corrosion which might be present on the pins/sockets and to distribute the corrosion-preventing grease on the pins and sockets.

Corroded pins/sockets are the biggest cause of problems that mysteriously over time (if there hasn't been an electrical problem caused by a lightning strike or an overvoltage from a battery charger or an I/O wiring problem). It's an excellent maintenance practice to apply grease to every ribbon cable connector in the Mark V (and there are a LOT of them!) at least once every two years. When doing this as part of preventing maintenance, you should unplug the connector from the socket, wipe any old grease off the connector, reapply new grease, and plug and un-plug the ribbon cable connector a couple of times, again to distribute the grease as much and as evenly as possible.

This is also a good time to use a non-conductive brush on a vacuum cleaner to remove dust from the I/O cards. Dust and dirt combined with humidity are the second worst enemies of electronic printed circuit cards the semiconductor components on them. (Heat is the worst enemy of semiconductor and other components on printed circuit cards.)

(I would also suggest using the I/O States function on all the other control processors and <C> to check for any other problems. And, lastly, resist the temptation to re-boot the other processors "just because" someone thinks it's a good idea--especially without first checking for Diagnostic Alarms on the other processors, AND without checking the I/O States of each processor before re-booting!!!)

Hope this helps! Please write back to let us know how you fare in restoring the control processor to A7.

We had find the problem.

One fuse from TCQC for S controller. before that we notice that in the power card there is an indication missing different than the other power cards for controllers (T, C & R). we checked all the component related to the power in the associated cards for controller S. finally this fuse is blown from TCQC card.

when we replace it, we found the indication return back to healthy, and for making sure we download the backup to the S card to keep the data if the power failure for any reason.

thanks everybody for your assistance.

Hamed87,

Thank you for the feedback!