MARK-VI VPRO CARD DIAGNOSTIC ALARMS

Hello guys,

Yesterday we had a failure of VPRO ‘Z’ card on our GT-A. The Z card was completely offline despite power supply to it being normal. Reading the manual and the threads here at control.com, it was quite evident that there had been internal short-circuiting in the card and it was now to be replaced. Therefore, we arranged a new card from our inventory and replaced it (on the running turbine) as per the procedure given in GE Manual GEH-6421J Page 151. We ensured that the model of the new card was same as that of the old one. Everything went well, we ensured that jumper settings were same, powered on the new card, and downloaded the firmware and configuration in the new card. After download, we rebooted the card again and card successfully came back online with LEDs matching with jumper settings. However, the following diagnostic alarms still persist on the newly replaced Z card:

  • Fault Code 21: P6 ID Failure
  • Fault Code 20: P5 ID Failure
  • Fault Code 18: P3 ID Failure

The manual says that this is an indication of failed ID chip on connector J2/J5/J6 or cable problem. I find it very hard to digest that all three cables are faulty at the same time. We have checked the cable connection on all these connectors and all the cables are properly connected with their locks engaged. The VPRO 'Z' card is online and synched with 'X' and 'Y' cards and everything else is fine except for these diagnostic alarms. There are no diagnostic alarms on 'R', 'S' and 'T' controllers or VCMI also. I tried downloading firmware/ configuration and rebooting again but situation is same. I would really appreciate the help of you guys to understand what is going on here. These ID failure suggests that VPRO 'Z' is not communicating with TREG and TPRO boards and this poses a serious threat to our turbine operation. I am attaching the screenshot of diagnostic alarms as well. Thanks in advance.
 

Attachments

Makster,

Methinks you are reading too much (i.e., overthinking) the situation with the TREG and TPRO card communication with the VPRO. Some Diagnostic Alarms are less meaningful than others; in my personal opinion, these Diagnostic Alarms fall firmly in that category.

The ETR relays are on the TREG and I believe there are Diagnostic Alarms is the relays are energized when they shouldn't be by a particular processor, or vice versa (de-energized when they shouldn't be). So, if the <Z> VPRO wasn't seeing the proper state of it's ETR relays, then there would most likely be Diagnostic Alarms to that effect. (It also seems that the OEM, in later versions of firmware, enabled Voting Mismatch Diagnostic Alarms for all three processors when one disagreed with the other two, or when two disagreed with one--thereby increasing the number of Diagnostic Alarms (which at the overwhelming majority of sites in the world are routinely discounted and ignored--except, it seems at your site, which is most admirable, sir.)

I have seen these chip ID Diagnostic Alarms before, but, at the present time I can't recall how they were resolved. I seem to recall downloading topology to the associated VCMI was effective at one site, maybe others.

I do, however, wish to strongly caution you--and other readers of this thread--against downloading for download's sake, meaning downloading because it might work and one wishes to be perceived as ”taking action” to eliminate the alarm. This has, very often, led to many other problems--which are (always) blamed on the Mark*, and most often undeservedly so.

Hopefully someone (most hopefully MARKVIGUY) will respond with a good answer or recommendation. In the meantime, continue to monitor the situation and let us know if something changes.
 
Dear CSA,
We have an SLA with Baker Hughes (formerly a GE Company) for technical help on Mark-VI matters and I wrote the same to them as well. Turns out their hardware engineer also thinks that this is serious. I am copying their response below:

"Requesting to confirm if after the replacement of board ,download of Firmware and parameter went fine without any error. Also post download the board need to be rebooted. If the stated steps mentioned were done then this can be a hardware problem. To troubleshoot following will be my recommendation

  1. Reboot the board multiple time and see if the VPRO is able to read the chip ID
  2. If the problem still persist then try to swap the J5 and J1 cable at TPRO and see if the problem moves with cable or stays at location
  3. If the problem moves with cable the issue is with VPRO and same need to be replaced.
  4. If the problem stays at location then we have problem with Terminal board TPRO and \TREG same need to be replaced"

This response puts me in another conundrum as what are the probabilities of a new card having a hardware problem. And if the issue comes out to be with the terminal boards (which I think is NOT as X and Y boards are operating fine with no diagnostic alarms), it will be a worse headache as I can do nothing with them on running machine.
 
makster,

Ahhh, now I understand the preoccupation with Diagnostic Alarms.

I have pulled several "new" spares out of the warehouse/stores only to find they don't work properly. Mark VI is not a young control system (it's not that old either). BUT, the biggest problem I encounter when pulling cards from warehouse/stores is that many people are in a hurry to swap cards to resolve a problem, and often when they pull a card from the warehouse/stores and put it in the rack and the problem doesn't go away, they put the card they pulled from the rack back in the box and send it back to the warehouse/stores, and it might be bad, but it has been powered-up and working for some time and there's no guarantee it will be serviceable the next time it's pulled and swapped.... It happens A LOT--especially when the problem is NOT the card, but something in the field (and, usually, if there was a problem with the card there would be Diagnostic Alarms--and there are in this case, and the presumption is, as you have just said, it's a card "just pulled from inventory" and should be good....). That's just not always the case; especially if Sourcing buys "refurbished" cards from a source other than GE ("tested" and "GE tested" are NOT the same!).

Anyway, good luck with your troubleshooting. Please write back to let us know what you find and how you resolve the issue.
 
Hi guys,
Just to update further, we carried out following steps to resolve said issue:
  • Swapping of J5Z and J1Z with either J5X/Y or J1X/Y on TPRO was not possible as our GT is online
  • All three diagnostic alarms were still present on VPRO board (Board 1)
  • We issued another VPRO board (Board 2) from our inventory and replaced Board 1. After downloading and powering up, P3 and P6 ID alarms went away but P5 ID failure alarm was still persisting
  • We had one more spare board in our inventory (Board 3). We installed it in place of Board 2 and situation was same i.e. P5 ID alarm was still present
  • So now we have 3 different new VPRO boards that have not worked on our system:
    • Board 0: Failed and went completely dead
    • Board 1: Installed in place of Board 0 but giving P3, P5, and P6 ID alarms
    • Board 2: Installed in place of Board 1 but giving P5 ID alarms
    • Board 3: Currently installed in place of Board 2 but still giving P5 ID alarm

From above, it is pretty evident that now the problem lies with either the cable/ connector between VPRO and TPRO J5 slots or the JZ5 slot on TPRO. Problem is that I have no experience or information on the connecting cable/ connector between VPRO and TPRO nor do I have spares cables in inventory. I have checked the cables themselves and there are no part numbers mentioned on those to facilitate sourcing. Therefore, if anybody can help me out regarding the sourcing and health checking of these cables, it will be much appreciated. I don't want to shutdown the machine for TPRO replacement before ruling out cable/ connector issue!
 

Attachments

Hello guys,

Yesterday we had a failure of VPRO ‘Z’ card on our GT-A. The Z card was completely offline despite power supply to it being normal. Reading the manual and the threads here at control.com, it was quite evident that there had been internal short-circuiting in the card and it was now to be replaced. Therefore, we arranged a new card from our inventory and replaced it (on the running turbine) as per the procedure given in GE Manual GEH-6421J Page 151. We ensured that the model of the new card was same as that of the old one. Everything went well, we ensured that jumper settings were same, powered on the new card, and downloaded the firmware and configuration in the new card. After download, we rebooted the card again and card successfully came back online with LEDs matching with jumper settings. However, the following diagnostic alarms still persist on the newly replaced Z card:

  • Fault Code 21: P6 ID Failure
  • Fault Code 20: P5 ID Failure
  • Fault Code 18: P3 ID Failure

The manual says that this is an indication of failed ID chip on connector J2/J5/J6 or cable problem. I find it very hard to digest that all three cables are faulty at the same time. We have checked the cable connection on all these connectors and all the cables are properly connected with their locks engaged. The VPRO 'Z' card is online and synched with 'X' and 'Y' cards and everything else is fine except for these diagnostic alarms. There are no diagnostic alarms on 'R', 'S' and 'T' controllers or VCMI also. I tried downloading firmware/ configuration and rebooting again but situation is same. I would really appreciate the help of you guys to understand what is going on here. These ID failure suggests that VPRO 'Z' is not communicating with TREG and TPRO boards and this poses a serious threat to our turbine operation. I am attaching the screenshot of diagnostic alarms as well. Thanks in advance.
Hello all,

You stated as per manual :
The manual says that this is an indication of failed ID chip on connector J2/J5/J6 or cable problem.

I read on the GEH6421 Vol2 it saying that These "code Fault 18 is RELATED J3 CONNECTOR ..."

Can you tell us where do you see taht it is for J2 ....

I see that:
Fault 18 is related to J3 connector
Fault 20 is related to J5 connector
Fault 21 is related to J6 connector

It can be a sort of part list for purchasing such connector if it is the cause of these alarms code faults...

I will have a better reading on this thread and see how I can try to support you...


Thank you for your reply...

James
 
Can the original poster try to respond to the last thread ...
It would be much appreciated ! as we are not here to discuss in the wind !

I mean we make effort to reply so please try to do the same...gentlemen.

Thank you for your attention& comprehension

James
 
Hi James/ ControlsGuy25,
Pardon me if I failed to understand what exactly were you asking in your last post. I thought those were general statements stated matter-of-factly. I suppose you're referring to below statement:

Can you tell us where do you see taht it is for J2 ....
.
To answer this, well J2 was a typo and I meant to write J3.
 
Hi James/ ControlsGuy25,
Pardon me if I failed to understand what exactly were you asking in your last post. I thought those were general statements stated matter-of-factly. I suppose you're referring to below statement:



.
To answer this, well J2 was a typo and I meant to write J3.
Hi Makster,

Thank you for replying.

Well it is always good to get some clarifications ...so we can speak about same subject and indeed can get better picture on what is going on...

James
 
So guys, just to update further and close out this thread, I was able to procure J5 cable on urgent basis and got the opportunity last night to carry out the activity. Turned out that the issue was with both the J5 cable and also the JZ5 port of TPRO board (I swapped the JZ5 and JY5 cable on TPRO and fault travelled to VPRO <Y> card).
So I had to replace both J5 cable and complete TPRO board. Now all alarms are cleared and system is healthy. Cheers and thanks for all the support!
 
So guys, just to update further and close out this thread, I was able to procure J5 cable on urgent basis and got the opportunity last night to carry out the activity. Turned out that the issue was with both the J5 cable and also the JZ5 port of TPRO board (I swapped the JZ5 and JY5 cable on TPRO and fault travelled to VPRO <Y> card).
So I had to replace both J5 cable and complete TPRO board. Now all alarms are cleared and system is healthy. Cheers and thanks for all the support!
Hi
Thank you for these inputs!

Always glad to support and advise you here!

Controls Guy25.
 
Top