PPRA MARK VIe

Welcome back, ControlEng999,

Of course you have looked at the Mark VIe System Guide, GEH 6721, in the PPRA section, to see what the various Diagnostic Alarms mean and what troubleshooting steps are recommended (since that's the way to begin to understand Diagnostic Alarm messages which are cryptic and to decide what troubleshooting steps to take). [I believe with newer versions of ToolboxST one can also double-click on a particular Diagnostic Alarm in the display you captured, or perhaps right-click on the alarm, and go almost immediately to the same description in the ToolboxST 'Help' feature. But, of course, you already knew this, too. Sorry to be pointing out obvious things.]

What were the results of your troubleshooting?

What I/O is the PPRA pack handling? (It appears to be some kind of speed sensor(s).) That's always a good way to start troubleshooting, too--understanding the I/O connected to the I/O Pack which is exhibiting Diagnostic Alarms.

I don't have access to a Mark VIe System Guide or a version of ToolboxST at this writing (I'm presently working on a vintage Mark IV turbine control panel!!! Oh, how I miss those days (the days of Mark IV)). But, of course, you do (have access to the manual and ToolboxST's 'Help' feature). RTFM. (Read The F..... F..... Fine Manual) Of course, that's always the place to start when you are confronted with a new issue.
 
Welcome back, ControlEng999,

Of course you have looked at the Mark VIe System Guide, GEH 6721, in the PPRA section, to see what the various Diagnostic Alarms mean and what troubleshooting steps are recommended (since that's the way to begin to understand Diagnostic Alarm messages which are cryptic and to decide what troubleshooting steps to take). [I believe with newer versions of ToolboxST one can also double-click on a particular Diagnostic Alarm in the display you captured, or perhaps right-click on the alarm, and go almost immediately to the same description in the ToolboxST 'Help' feature. But, of course, you already knew this, too. Sorry to be pointing out obvious things.]

What were the results of your troubleshooting?

What I/O is the PPRA pack handling? (It appears to be some kind of speed sensor(s).) That's always a good way to start troubleshooting, too--understanding the I/O connected to the I/O Pack which is exhibiting Diagnostic Alarms.

I don't have access to a Mark VIe System Guide or a version of ToolboxST at this writing (I'm presently working on a vintage Mark IV turbine control panel!!! Oh, how I miss those days (the days of Mark IV)). But, of course, you do (have access to the manual and ToolboxST's 'Help' feature). RTFM. (Read The F..... F..... Fine Manual) Of course, that's always the place to start when you are confronted with a new issue.
HI CSA,
Yes, I have seen description of this trouble in GEH 6721, but it is common resolution like check wire, termination, or replace daugtherboard and check lenght of pins. What do you think about lenght of cable between sensor and i\o pack? and I know that during installation the installers shortened the cable.

PPRA is handling speed sensors for TNH and TNL.

Unfortunately, Unit is running, and at this resource i think there are some people who faced with such problems definetly.
 
ControlEng999,

"... at this resource i think there are some people who faced with such problems definetly. "

I yield to others who--of course--have definetly faced with such problems as this.

The GEH-6721, Vol. II, that I found on the World Wide Web doesn't have any section on PPRA. PPRF, but no PPRA (I was looking at Rev BR. So I don't know what version you are using.

But, if the installers cut the shortened the cable I would definitely be looking at their workmanship--particularly since you ave said the construction was not very good.

Again, I yield to all those on this forum who have faced this problem to tell you what their experience is and how they resolved their problem(s).
 
CSA, eventually they pulled all of the turbine specific IO (PTUR/PPRO/PPRA/etc) into a new volume - GEH- 6721 VOL III. So, you might want to check that.

ControlEng99, When do these alarms come in? Is it only during start up or shut down? Or periodically through baseload/part load operation?

The WREA is a repeater board that allows you to "forward" on the speeds that you get from the GT. The speed pickups are wired into the TREA board, detected by the PPRA IO module. You should be able to see this value in ToolboxST. Then these speeds are outputted on the J3 connection on the TREA board to the small WREA board and then wired out to somewhere else.
- Speed Probe ->TREA->PPRA->TREA->WREA->somewhere else.

If you get these alarms, that tells me that the inputs into the TREA board do not match the 'outputs' on the WREA board. So, it is possible something broke on TREA board before the J3 Connection, but doubtful. It is most likely something to do with the wiring from the WREA to 'somewhere else'. This could be for several reasons. Read the manual under TREA/WREA - Speed Repeater outputs. Some things that could be wrong
* Using RS232 comms and the cable is longer than 10m
* using RS485 comms and the cable is longer that 500m
* the WREA is broken
* 'somewhere else' and the TREA do not have shared grounding
* you double grounded the shielding at the WREA and at 'somewhere else'

Hope this helps
 
CSA, eventually they pulled all of the turbine specific IO (PTUR/PPRO/PPRA/etc) into a new volume - GEH- 6721 VOL III. So, you might want to check that.

ControlEng99, When do these alarms come in? Is it only during start up or shut down? Or periodically through baseload/part load operation?

The WREA is a repeater board that allows you to "forward" on the speeds that you get from the GT. The speed pickups are wired into the TREA board, detected by the PPRA IO module. You should be able to see this value in ToolboxST. Then these speeds are outputted on the J3 connection on the TREA board to the small WREA board and then wired out to somewhere else.
- Speed Probe ->TREA->PPRA->TREA->WREA->somewhere else.

If you get these alarms, that tells me that the inputs into the TREA board do not match the 'outputs' on the WREA board. So, it is possible something broke on TREA board before the J3 Connection, but doubtful. It is most likely something to do with the wiring from the WREA to 'somewhere else'. This could be for several reasons. Read the manual under TREA/WREA - Speed Repeater outputs. Some things that could be wrong
* Using RS232 comms and the cable is longer than 10m
* using RS485 comms and the cable is longer that 500m
* the WREA is broken
* 'somewhere else' and the TREA do not have shared grounding
* you double grounded the shielding at the WREA and at 'somewhere else'

Hope this helps
HI ME42, thanks for respond.
These signals appear during startup and shutdown, part load and FSNL and even zero speed, i have seen this resource GEH- 6721 VOL III, and solution that described there, but I emphasize that it is common solution and there are many places where fault can be, as result i have to look for information in specification of TREA WREA and PPRA and find requirement of cable lenght and other special requiremens.
I understand that you have faced with this trouble and got success in troubleshouting.

If it is true, what have you done?
Could you describe solution in details?
 
ControlEng999,

Sometimes it is the simplest things. At one site the remote operator interface module would experience frequent loss of communications—but only during the summer months and randomly as well. The cable was twin-axial (a bit unusual) but it meggared perfectly fine every time and the resistances were spot on and the cable connectors were found to be installed properly but were even replaced twice. The power supply was replaced. Twice. The comm cards at both ends were replaced. Twice. A separate cable was installed temporarily on the ground and there were no problems. After nearly three years we rented a time domain reflectometer and traced the problem to a spot in the outdoor overhead cable tray. This was the ONLY cable in the tray (12” wide, 4” deep). We rented a man lift to get access to the cable tray and found the electricians had used metal “zip ties” with a special tensioning tool to secure the cable to the cable tray at 18” intervals. EXCEPT the tensioning tool was set to use so much tension the cable was deformed and squeezed even tighter during hot weather in direct sunlight. It was pretty obvious when we put eyes on it, and we cut that metal tie off and thought we had finally solved the problem. Until about a week later when it lost comm’s again. We still had the time domain reflectometer and used it to find another location with another excessively tight metal tie. This time we cut every metal tie off along the 1100’ length of the cable. Never had another problem in twenty years.

The factory had sent people to site multiple times and tried new PROMs—even wrote a new software protocol.

I have seen loose crimp connectors and loose terminals cause plants to lose hundreds of thousands of dollars. And the control system was initially blamed every single time.

Never overlook the simple things. When it comes to serial communications a poor solder connection or a cable 8” too long can cause loss of communications. I’ve even seen 20 AWG cable that was twisted when pulled into the conduit damage the wire integrity (it was poor quality cable to begin with and and was poorly installed!).

You have said the construction practices were not very good. ME42 provided maximum cable lengths for 232 and 485 configurations. It’s also probably in the manual. And yet you are certain someone is withholding something more nefarious from you, yet you don’t want to check the obvious to prove them wrong (because they might be proven right, which would mean: you would be proven wrong).

You are going to have a rough career with that attitude. And you are going to find it difficult to get help from others when you reject what they are trying to tell you without reason—just your gut feeling that what you’re being told is not the problem. Sir—if you had solved the problem you wouldn’t be writing to strangers asking for help. Ignoring that help is not going to get you continued help.

I realize you have humbled yourself writing and asking for help, but you have some anonymity here. And what you really want is to get a unique resolution that no one on site has proposed that solves the problem and you become the hero (without mentioning where you got the information). I have seen this too often in my nearly 40 years in the field, especially in a certain middle part of the East, if you get my drift, as well as in large parts of the far part of the East. People who don’t have critical thinking skills but know what they’re being told is incorrect or that someone is withholding something or trying to cheat them. But, they really don’t know jack about anything. And they won’t admit it and they bully others.

Blessed day.
 
ControlEng999,

Sometimes it is the simplest things. At one site the remote operator interface module would experience frequent loss of communications—but only during the summer months and randomly as well. The cable was twin-axial (a bit unusual) but it meggared perfectly fine every time and the resistances were spot on and the cable connectors were found to be installed properly but were even replaced twice. The power supply was replaced. Twice. The comm cards at both ends were replaced. Twice. A separate cable was installed temporarily on the ground and there were no problems. After nearly three years we rented a time domain reflectometer and traced the problem to a spot in the outdoor overhead cable tray. This was the ONLY cable in the tray (12” wide, 4” deep). We rented a man lift to get access to the cable tray and found the electricians had used metal “zip ties” with a special tensioning tool to secure the cable to the cable tray at 18” intervals. EXCEPT the tensioning tool was set to use so much tension the cable was deformed and squeezed even tighter during hot weather in direct sunlight. It was pretty obvious when we put eyes on it, and we cut that metal tie off and thought we had finally solved the problem. Until about a week later when it lost comm’s again. We still had the time domain reflectometer and used it to find another location with another excessively tight metal tie. This time we cut every metal tie off along the 1100’ length of the cable. Never had another problem in twenty years.

The factory had sent people to site multiple times and tried new PROMs—even wrote a new software protocol.

I have seen loose crimp connectors and loose terminals cause plants to lose hundreds of thousands of dollars. And the control system was initially blamed every single time.

Never overlook the simple things. When it comes to serial communications a poor solder connection or a cable 8” too long can cause loss of communications. I’ve even seen 20 AWG cable that was twisted when pulled into the conduit damage the wire integrity (it was poor quality cable to begin with and and was poorly installed!).

You have said the construction practices were not very good. ME42 provided maximum cable lengths for 232 and 485 configurations. It’s also probably in the manual. And yet you are certain someone is withholding something more nefarious from you, yet you don’t want to check the obvious to prove them wrong (because they might be proven right, which would mean: you would be proven wrong).

You are going to have a rough career with that attitude. And you are going to find it difficult to get help from others when you reject what they are trying to tell you without reason—just your gut feeling that what you’re being told is not the problem. Sir—if you had solved the problem you wouldn’t be writing to strangers asking for help. Ignoring that help is not going to get you continued help.

I realize you have humbled yourself writing and asking for help, but you have some anonymity here. And what you really want is to get a unique resolution that no one on site has proposed that solves the problem and you become the hero (without mentioning where you got the information). I have seen this too often in my nearly 40 years in the field, especially in a certain middle part of the East, if you get my drift, as well as in large parts of the far part of the East. People who don’t have critical thinking skills but know what they’re being told is incorrect or that someone is withholding something or trying to cheat them. But, they really don’t know jack about anything. And they won’t admit it and they bully others.

Blessed day.
Hi CSA,
I would like to say that ME42 has experience as it seems to me he is right, i have not found time to check specification fot these boards, because of startup next unit first fire and etc., but this way of solution of this problem is more probable.
 
ControlEng999,


I agree; ME42 has a good deal of experience that has offered. An what have you done with that information?

Of course; you can--and most definetly will--believe whatever your heart desires. It seems to guide most of your thinking anyway (as opposed to logic and critical thinking).

Me? When I'm working on something I'm unfamiliar with (as you are) I choose to RTFM (Read The Fine Manual) and unless it just doesn't seem to be applicable or I can definetly rule out what it suggests when I'm unfamiliar with the equipment I will check the obvious, because if I have to contact the manufacturer for additional help I want to be sure I've already done what was suggested in the Fine Manual (instead of having to go back and do it when I can't explain why I didn't follow the manual's suggestions). But, hey--that's me. I'm a rebel. I read the manual. Often I read it several times. I consider the circumstances. I look to rule out the "obvious" first, instead of last, and it's worked really well for me for nearly 40 years.

Of course, each to his own. And yours is ... well, of course, your own. Definetly.

Blessed day.
 
Is there anybody who faced with such problems PPRA cards. I highlighted these fails. What could be the reason, and what is the solution can be?
Good day gents,

Can you tell us what type /model of the Gas turbine is it ...

As I Found on GE manual ( the right one that the alarm ID 53 /54 of WREA is defined as :
The speed repeater output does not match the speed input signal

Followings need to be checked ( possiblse causes) :
One of the speed sensor is not connected
The pins on the cable are shorted
The RS32-RS485 CHIP is not functionning

I advise you to check those things ...
if all ok so WREA Daughterboard may be need to be repaced...

Tomorrow I will add notes /tips on Dual speed sensor mismatch alarmI id definition and how to troubleshoot...

Looking to hear back from you soon!

Cheers

ControlsGuy25
 
Good day gents,

Can you tell us what type /model of the Gas turbine is it ...

As I Found on GE manual ( the right one that the alarm ID 53 /54 of WREA is defined as :
The speed repeater output does not match the speed input signal

Followings need to be checked ( possiblse causes) :
One of the speed sensor is not connected
The pins on the cable are shorted
The RS32-RS485 CHIP is not functionning

I advise you to check those things ...
if all ok so WREA Daughterboard may be need to be repaced...

Tomorrow I will add notes /tips on Dual speed sensor mismatch alarmI id definition and how to troubleshoot...

Looking to hear back from you soon!

Cheers

ControlsGuy25
Frame 5, Mark VIe,
Definetly, I need to check specification.......
 
Next time, I will get back here with solution and share with us
You got also to investigate on that ALarm ID 123 ..according to manual you need to verify the configuration of LedDiag parameter of the involved pack ...


For the Alarm ID 56 Dual speed sensors reported speed that differ than more than the configured dual_diff_limit...
Now it is up to you to investigate on these sides...

Cheers

ControlsGuy25.
 
Top