Hi,

We are facing R processor diagnostic issue due to which it seems R processor in unable to obtain values for associated R core IO packs and as a result a number of USCB-R IO alarms appear. The issue is occurring since past 30 hours and at times gets reset but on certain occasions remains persistent. During the condition when the fault is persistent and is not reset, SW-1 and SW-2 connected to R core appear to be healthy and we tried pressing the RJ-45 cables for any potential issues but no difference was observed on the diagnostic LED on R processor.

We have a TMR configuration installed on Gas Turbine application and what is strange is that when connected through designated controller, the only difference that appears is of R processor Diagnostic. However when connected through R processor, it shows difference in I/O Equality as well as Diagnostic alarm.

Would appreciate any help on the subject.

 

Hi,

Looks like this is serious case/issue to be fixed..

Questions:
Is that unit is equipped with original Mark6e or is that a migration/upgrade..

Looks like these relays are for Soe.

Did you check Magnetic pick up speed sensors...

James

 

Hi,

Looks like this is serious case/issue to be fixed..

Questions:
Is that unit is equipped with original Mark6e or is that a migration/upgrade..

Looks like these relays are for Soe.

Did you check Magnetic pick up speed sensors...

James

Hi James,
The relays are for interunit communication of alarms to other control systems at site so these are not of concern. They will give an alarm whenever Mark-VIe faces any alarm. As far as the Magnetic pickups are concerned, these are also of lesser concern as they pertain to starting steam turbine whose valve is slightly leak through hence the steam turbine rotates once in a while (and is decoupled from the system).

The real concern is the loss of IONET1. This is a migration where mark-V was upgraded to mark-VIe 3 years ago.

 

Hi MnM?

Thank you for these clarifications...


Is that a combined cycle that you have...since you mentionned gas turbine in the first post and now you mentionnning Steam turbine..

I have seen some sites having troubles with I/O nets ...issues....

Will have a better look on Oem manual and come back asap..

Any time!
James

 

Hi MnM?

Thank you for these clarifications...


Is that a combined cycle that you have...since you mentionned gas turbine in the first post and now you mentionnning Steam turbine..

I have seen some sites having troubles with I/O nets ...issues....

Will have a better look on Oem manual and come back asap..

Any time!
James

Hi James,
Actually we have a steam turbine starter which is what I am referring to

Regards,
Mohsin Mukhtar

 

Hi Mohsin,

Thank you for clarifying..

When migration was performed ...

Any change/work have been done on controls system these last days..

We will be glad to suppport you by adding these informations..

OEM manuals can help but you need to read the right one...

Would try to check PPRO correct working too..

Any time!
Regards,
James

 

Hi James,

Really appreciate your response. There was no work done on the system recently at least to my knowledge.

What checks do you recommend on the PPRO working?

Regards,
MnM

 

MnM,

This does not appear to be a Mark V-to-Mark VIe Migration--which is when the I/O cards in the Mark V control panel processor cores are replaced with Mark VIe-compatible cards. Those cards have very different "names" (usually beginning with an M, I believe), and those cards typically use the Mark V I/O terminal boards (DTBA, QTBA, etc.). Also, there aren't very many I/O Packs in a Mark V-to-Mark VIe Migration. And, the descriptions of the locations (Back Panel, Left Panel, Right Panel) all seem to be related to the locations of Mark VIe terminal boards, with typical Mark VIe I/O Packs (PVIB; PPRO; PTUR; etc.). So, this may be a a "new" type of Mark V upgrade, one that might still use the original Mark V turbine control panel but all of the Mark V hardware is removed and replaced by "real" Mark VIe hardware and I/O packs (instead of the Mark VIe-compatible cards).

At any rate, you seem to have something of an unusual problem, made all the more unusual by the fact that you say nothing has changed and/or no work was done recently.

I can't tell if the unit is running continuously, or if it starts and stops, or what has really been done to try to troubleshoot the problem from your description(s). My educated guess based on the information provided is that something is amiss with the IONET for <R> (IONET1)--either there's an IONET1 Ethernet switch problem, or there's a cabling problem (Ethernet cabling) or there's some issue with the cables that run between the TRPG and TREG (I'm presuming the system uses one or both of these I/O terminal boards for control and protection).

It could also be a 28 VDC power supply issue for <R>, but I would expect there would be Diagnostic Alarms associated with that, and it doesn't look there are.

This is a tough one based on the information provided. It's going to probably be a process of elimination rather than a do this or do that situation. I suggest you very carefully write down each step you take--AND THE RESULTS OF EACH STEP (and not just "it didn't work; details about any changes, expected or unexpected). Because if you end up having someone knowledgeable with Mark VIe come to site (and I suspect you will) if you can give them good information about what you've done, how you've done it, and what the results were (DETAILS are really good here!) you will not watch them (and pay them) to do what you've already done in their troubleshooting process.

Please write back to let us know how you fare in resolving this issue!!!

Best of luck!

 

Hi James,

Really appreciate your response. There was no work done on the system recently at least to my knowledge.

What checks do you recommend on the PPRO working?

Regards,
MnM

Hi MnM

I suggest you to try a I/O pack diagnostic on all i/o packs not only PPRO see if which faukt code it will return then....

Any time!
James

 

Looks like it is a time out issue for R controller ...You need to troubleshoot it by using I/O packs diagnostic window /interface

It will be a very good assistant for solving this issue..

Have a search on document on How to troubleshoot it ..

 

This is I/O PACKS Diagnostic feature:

Can you use this function and share here a screenshot ...So we will be in better position to troubleshoot ..remotely!

 

 

Is that copy-righted material from the ELC???

 

Actually I do not have a clue ...i just try to give a support to MnM..showing him and all users here that is possible to use mark6e Features...for good /best troubleshooting

 

MnM,

This does not appear to be a Mark V-to-Mark VIe Migration--which is when the I/O cards in the Mark V control panel processor cores are replaced with Mark VIe-compatible cards. Those cards have very different "names" (usually beginning with an M, I believe), and those cards typically use the Mark V I/O terminal boards (DTBA, QTBA, etc.). Also, there aren't very many I/O Packs in a Mark V-to-Mark VIe Migration. And, the descriptions of the locations (Back Panel, Left Panel, Right Panel) all seem to be related to the locations of Mark VIe terminal boards, with typical Mark VIe I/O Packs (PVIB; PPRO; PTUR; etc.). So, this may be a a "new" type of Mark V upgrade, one that might still use the original Mark V turbine control panel but all of the Mark V hardware is removed and replaced by "real" Mark VIe hardware and I/O packs (instead of the Mark VIe-compatible cards).

At any rate, you seem to have something of an unusual problem, made all the more unusual by the fact that you say nothing has changed and/or no work was done recently.

I can't tell if the unit is running continuously, or if it starts and stops, or what has really been done to try to troubleshoot the problem from your description(s). My educated guess based on the information provided is that something is amiss with the IONET for <R> (IONET1)--either there's an IONET1 Ethernet switch problem, or there's a cabling problem (Ethernet cabling) or there's some issue with the cables that run between the TRPG and TREG (I'm presuming the system uses one or both of these I/O terminal boards for control and protection).

It could also be a 28 VDC power supply issue for <R>, but I would expect there would be Diagnostic Alarms associated with that, and it doesn't look there are.


This is a tough one based on the information provided. It's going to probably be a process of elimination rather than a do this or do that situation. I suggest you very carefully write down each step you take--AND THE RESULTS OF EACH STEP (and not just "it didn't work; details about any changes, expected or unexpected). Because if you end up having someone knowledgeable with Mark VIe come to site (and I suspect you will) if you can give them good information about what you've done, how you've done it, and what the results were (DETAILS are really good here!) you will not watch them (and pay them) to do what you've already done in their troubleshooting process.

Please write back to let us know how you fare in resolving this issue!!!

Best of luck!

Hi CSA,

Thank you for your detailed response. With the migration philosophy you mentioned, yes it was not a Mark-V to Mark-VIe migration rather a new Mark-VIe where all control system side hardware was replaced with Mark-VIe.

The system is running since the faults first appear and we cannot take it down without taking a power load debit on our facility. The system has both TRPG and TREG boards for control and protection. We checked for ground fault but found 28V supply to be healthy on all IO packs.

We have followed the below steps so far without any success:

1. Unplug the <R> controller to IONET#1 Switch cable from existing port and plug it in spare port. Diagnostic alarms were not cleared.
2. Unplug & Plug-in the IONET#1 cable on <R> controller. Diagnostic alarms did not clear.
3. Replaced the Ethernet cable between <R> controller to IONET#1 switch but Diagnostic alarms did not clear.
4. Recycled power of IONET#1 switch#1. Diagnostic alarms did not clear.

We plan to do teh following next:

1. Reboot the <R> Controller by pressing the white button located at the bottom of UCSB.
2. If alarms are not cleared, we will replace the IONET#1 Switch#1 and check if the diagnostic alarms are cleared though space congestion will be a big issue due to location of the switch.
3. Lastly if nothing works, we will replace the processor and download the application again.

Another item to note here:

UCSB.T also noticed communication error with R pack IONET#1. However this is intermittent and restores. Fortunately both UCSB.T and UCSB.R errors have not occurred together otherwise I believe Unit could have tripped. But why is IONET#1 healthy even after power cycle? Even the cables are separate for Both R and T controllers on IONET#1 switch.

 

View attachment 1387

Hi ControlsGuys25,

We checked the diagnostics and when connected through R Controller and it shows all IO packs as unhealthy mainly due to ToolboxST application connection between JR(1) and controller.

 

Hi ControlsGuys25,

We checked the diagnostics and when connected through R Controller and it shows all IO packs as unhealthy mainly due to ToolboxST application connection between JR(1) and controller.

View attachment 1390
View attachment 1392

Hi MnM,


Thank you for the inputs so at least now you got Alarm ID and can refer to OEM manual for description of the Alarm/fault id ...

I advise you now to do Controller diagnostic ...so we can have a better overview of whats goin on with that IO nets /controller issue....

Any time!
James

 

Hi MnM,


Thank you for the inputs so at least now you got Alarm ID and can refer to OEM manual for description of the Alarm/fault id ...

I advise you now to do Controller diagnostic ...so we can have a better overview of whats goin on with that IO nets /controller issue....

Any time!
James

Hi James,

Attached please find advanced controller diagnostics as well as controller diagnostics in the zip file. It is interesting to note pre-vote status of any IO (both digital and analog) on JR1 when connected through R controller as well as when connected through designated controller (S in this case). Somehow I get the feeling something is wrong with the controller and it needs to be either rebooted or replaced. Is there any button on the controller to reboot or power cycle is the only way to reboot the controller?

 

Hi MnM

Thats ok now you can track the default by performing also advanced diagnostic alarms controller...
Have a look on the help folder it can be a good assistant..

Is that possible for you to reply to my Private message....

James

 

Hi MnM & all!


I Found some notes regarding controller & I/O pack communication issue...
and how to solve it...Would you plz try to reply to my messsage here....