We have Mark-VI Control System installed on Hitachi H-25 Gas Turbine. There were no prior Process/ Diagnostic alarms existing on the machine. These are single fuel turbines on gas.

Recently, we had an issue where the turbine tripped on generator lockout relay burnout. The same was checked and restored to healthy by our Electrical team; however we started facing issues on the control end detailed as follows. This resulted in T-core diagnostic alarms prohibiting machine start-up.

Repeated Alarms displayed were as follows:
VCMI IO State Exchange for <T> Failed
VPRO Communications Fault
XMIT Suspended. CPU Switched (reset immediately each time)

Turbine was started by forcing the signals to contribute in removing TCP minor trouble fault. Currently following alarms are displaying as Process:
UCVx Overtemperature
UCVx Airflow or overtemperature trouble
TCP Minor Trouble

Diagnostic:
<T> Slot 6 VSVO Diagnostic Alarm (interestingly, VSVO card in actual is installed on Slot 5)
<T> Slot 1 VCMI Diagnostic Alarm

Details on diagnostic faults in Control Toolbox:
VSVO: VSVO card not online. Servos suicided (code= 46)
VCMI: IONET-1 Communication Failure (Code= 45)
Using DEFAULT Input Data, Rack R0 (Code= 49)

Also, there is some haphazard behavior on timing and the dates being displayed against these alarms are not the actual ones but going back to 1989!

Also, on control toolbox T controller is showing Boot status.
Additionally, physically on T Controller VCMI card IONET 1, no LED is blinking and M-Var and voltage indication from system going to DCS are also in bad PV (these signals are going from Analog card installed in Simplex at the T controller only).

As rectification measures, before turbine start-up; VSVO card was replaced; power down of T-controller and respective Protection controller (Z); however the problem is persisting. Field signals for VSVO from IGV, GCV and SRV for servos were also verified and found OK. The turbine is now running for 4-5 days with no other abnormality other than the observations detailed above. There was an idea to download the logic again onto T-controller, however i do not think that this would be an issue since other two controllers (R & S) are working fine. Most likely to me it seems to be either VCMI card issue or some problem with the VSVO particular slot.

Would appreciate some insight and probable reason into these existing and diagnostic alarms.

 

There are few of the alarms that you have mentioned has been faced by me and most of the time it is the VCMI card which is the major culprit in this type of situation.

>VCMI IO State Exchange for <T> Failed
>VPRO Communications Fault
>XMIT Suspended. CPU Switched

>VCMI: IONET-1 Communication Failure (Code= 45)
>Using DEFAULT Input Data, Rack R0 (Code= 49)

>physically on T Controller VCMI card IONET 1, no LED is blinking

In last two years with this type of alarms I have replaced 4 VCMI cards in Mark VI system and problem solved.

Also there may be probability of IONET cable fault, but as you have informed that <T> core is giving alarm i.e., VSVO card not online. Servos suicided (code= 46), but VSVO card in actual is installed on Slot 5. The probable issue may be with VCMI card.

As Mark-VI other cards communicate to UCVX processor card via VCMI card through backplane and IONET are used to communicate with its dedicated VPRO and other two processors.

The increase number of VCMI and VPRO card failure is due to the socket base chip installed in the VCMI and VPRO cards of earlier version. GE released a TIL regarding the same last year and advise for replacement of the same with new soldered base chip.

 

Thanks for the response BN. Yes, VCMI appeared to be the suspected culprit but i was not sure.

However, i don't think my Operations team will let me change it online now!

Also, do you think that this could be the reason causing time haphazard issues because i think that that is something being contributed by the software side (Cimplicity) on the HMI or does it have anything related to this suspected VCMI problem?

 

Online replacement of VCMI can be done as the system is already running on R and S processors as I think your T core is already power down.

Convincing the operation group is a really a big task as something goes wrong they will also has to give answers to plant higher levels, that's why they also not prefer for online download.

But I have downloaded the VCMI card online without any issue and the procedure given in GE manual is straight and simple. However there are few issues that has to be considered before powering down a third processor is that whether the Moog valves, LVDT, and other 2oo3 voting instruments are not having any issue.

For timing issue, whether your PC is time synch with any external clock source or GPS system??

What is the controller time now showing in toolbox. If there is any time error, download the same to the controller via View and set time option under download.

Whatever will be your finding please report the same.

 

Yes, technically T-controller is down.

As regards time, PC is running on localized clock and not synched with GPS System.

For the Controller time, i need to check that.

Will definitely share the findings when i get the opportunity to replace the VCMI card.

 

Was reading this thread and one question comes to my mind.

There was a mention of Lockout Relay burnout just prior to the issues with the Mark-VI System. Could there be a connection between these two faults like a common root cause or one leading to the other or is it merely coincidence that these occurred simultaneously?

 

Just to update, we went ahead with the VCMI card replacement in Outage last week and condition has been returned to normal.

Also, for the time issues; it was identified that all 03 times (HMI, Controller & Ex2100) are at different times, so they have been synched up as well.

However, we have come up with some new issues on the turbines, but not really related to the issue in this thread.

@aabbask>> i am really not sure about the answer to your question. Perhaps someone more knowledgeable on the forum can shed some light on it.

Thanks all for the support.

 

srh,

Thanks for the feedback! "Feedback is the most important contribution!"(c) here at control.com--it's what differentiates this forum from so many others, being able to see what worked--and what did not, and what was useful--and what was not.

 

Hi,
Which plant are you from? Country? My friend from a plant in the middle east had the same issue.