C
Hi,
We recently had a unit trip (steam turbine/comp drive) due to the failure of a single VPRO card in <X>.
The control system is a TMR GE Mark VI. We are running UCVG processors with VCMI H2Bs (I believe) in each core. We recently experienced an unexpected trip of the unit. The problem was resolved and the unit was restarted after the <X> VPRO was changed with a new one. The following things were noted during the intial troubleshooting efforts:
All (3) processors (r,s,t) were found in the "Boot State". IO State 0x67 and Boot state 0xc3. Also was saying "Missing any IO NET Connections" or something (don't have my notes at home with me). Not sure what caused them to reboot??
All (3) processors (r,s,t) could be pinged sucessfully and response received.
No diagnostic alarms on UCVG. Only diagnostic alarm on VCMI (all three cores) was "using default data rack r8". Of course this is why we decided to change the <X> VPRO.
Toolbox was able to view diagnostic data for all vme cards excluding the <X> VPRO. <Y> and <Z> displayed no diagnostic alarms.
Mark VI HMI was not displaying any live data. Only showing #### signs. There were a few alarms active such as "125VDC ground", "AC source #1 lost", "AC source #2 lost", and "125VDC source lost". Not sure why these alarms were active, we have no indication that any power sources "blipped" and it seems even odder since the HMI was not communicating with the processors. There was another alarm indicating that the HMI link to the Mark VI was lost and cimplicity was not communicating.
Upon review of the processor diagnostics we found that "XMIT SUSPENDED. CPU SWITCHED" diagnostic alarm toggled a couple times before the unit tripped. We also received deviation alarms on a 2oo3 temperature trip that is executed in the <P> core. The trip log did not capture data since the Mark VI lost comm before L4 changed states.
Also, the input impediance of the IONET connector on the bad VPRO was approx 100mega ohm while it was approx 140 kilo ohm on the good VPROs.
In the past, we have successfully changed VPROs while the unit is running without affecting unit operation. Has anyone seen a similar issue before? Is it possible that the VPRO caused an IONET failure resulting in the reboot of <R> <S> <T> processors? They are supposed to be "completely" independent.
Thanks,
Chris
We recently had a unit trip (steam turbine/comp drive) due to the failure of a single VPRO card in <X>.
The control system is a TMR GE Mark VI. We are running UCVG processors with VCMI H2Bs (I believe) in each core. We recently experienced an unexpected trip of the unit. The problem was resolved and the unit was restarted after the <X> VPRO was changed with a new one. The following things were noted during the intial troubleshooting efforts:
All (3) processors (r,s,t) were found in the "Boot State". IO State 0x67 and Boot state 0xc3. Also was saying "Missing any IO NET Connections" or something (don't have my notes at home with me). Not sure what caused them to reboot??
All (3) processors (r,s,t) could be pinged sucessfully and response received.
No diagnostic alarms on UCVG. Only diagnostic alarm on VCMI (all three cores) was "using default data rack r8". Of course this is why we decided to change the <X> VPRO.
Toolbox was able to view diagnostic data for all vme cards excluding the <X> VPRO. <Y> and <Z> displayed no diagnostic alarms.
Mark VI HMI was not displaying any live data. Only showing #### signs. There were a few alarms active such as "125VDC ground", "AC source #1 lost", "AC source #2 lost", and "125VDC source lost". Not sure why these alarms were active, we have no indication that any power sources "blipped" and it seems even odder since the HMI was not communicating with the processors. There was another alarm indicating that the HMI link to the Mark VI was lost and cimplicity was not communicating.
Upon review of the processor diagnostics we found that "XMIT SUSPENDED. CPU SWITCHED" diagnostic alarm toggled a couple times before the unit tripped. We also received deviation alarms on a 2oo3 temperature trip that is executed in the <P> core. The trip log did not capture data since the Mark VI lost comm before L4 changed states.
Also, the input impediance of the IONET connector on the bad VPRO was approx 100mega ohm while it was approx 140 kilo ohm on the good VPROs.
In the past, we have successfully changed VPROs while the unit is running without affecting unit operation. Has anyone seen a similar issue before? Is it possible that the VPRO caused an IONET failure resulting in the reboot of <R> <S> <T> processors? They are supposed to be "completely" independent.
Thanks,
Chris