output of regulator type 00 in mark v

T

Thread Starter

TMR123

Control valve feedback (3rd lvdt defined in rgulator 8(type00) lvdt 15) is showing 00 (constant) in logic forcing but showing actual value in diagnostic counters. Control system is MARK V with TMR configuration.

Our steam turbine is controlled through Mark V with TMR configuration. For one of the control valves in our steam turbine there are three LVDT feedbacks defined as LVDT 3, lvdt 4 and lvdt 15.

Lvdt 3 and 4 are defined in regulator 2. the tcqa definition is given below for these feedbacks. now 3rd position defined in LVDT 15 (regulator 8 type 00) is showing 0 value always in Logic Forcing Screen but in diagnostic counters it is showing actual value as per the valve opening. for lvdt 3&4 the value is matching in logic forcing as well as in diagnostic counters. I would like to know how i can get actual value for lvdt 15 in logic forcing.

TCQA Card Definition - Socket 1 - Screen 5/21

Regulator Definition for Servo Output 2

Function type & sub-type: 49

Valid types <00, 2D, 2E, 40, 41, 43, 49, 51, 52, 53, 64, 65, 66>

Suicide enable :-
Current Fault: YES
LVDT/R fault: YES
Suicide position limits (%):: Low: -5.0 High: 105.0

Current Gain: (0 to 200% rated_cur./%pos.) 20.0
Current Bias: (0 to 100% rated [10,20,40]) 3.0

Note: For type 2D&2E: Position Bias (3.84 %) = 1.28 x Current Bias

Zero Stroke (0 to 6.667 Vrms) :-
LVDT 1: 1.6531
LVDT 2: 1.65 100% Stroke (0 to 6.667 Vrms) :-
LVDT 1: 4.406 LVDT 2: 4.386

<6> Pos limits (-128% to 128%) :- Low: 0.0 High: 0.0
<6> Integrator convergence gain (0 to 1 %/%): 0.0
<6,2> Position reference Gain (0 to 32 %/%): 0.0
<6,2> Position ref time constant (0 to 8 Sec) : 0.0
Note: for type 5 & 6, enter fuel flow data on Pulse Rate screen.


TCQA Card Definition - Socket 1 - Screen 11/21

Regulator Definition for Servo Output 8

Function type & sub-type: 00
Valid types <00, 40, 41, 43, 51, 52, 53, 64, 65, 66>
Suicide enable :- Current Fault: NO LVDT/R fault: NO

Suicide position limits (%):: Low: -5.0 High: 105.0

Current Gain: (0 to 200% rated_cur./%pos.) 0.0
Current Bias: (0 to 100% rated [10,20,40]) 0.0

Zero Stroke (0 to 6.667 Vrms) :- LVDT 1: 1.6559 LVDT 2: 2.0531
100% Stroke (0 to 6.667 Vrms) :- LVDT 1: 4.39 LVDT 2: 4.826

<6> Pos limits (-128% to 128%) :- Low: 0.0 High: 0.0
<6> Integrator convergence gain (0 to 1 %/%): 0.0
<6> Position reference Gain (0 to 32 %/%): 0.0
<6> Position ref time constant (0 to 8 Sec) : 0.0
Note: for type 5 & 6, enter fuel flow data on Pulse Rate screen.
 
TMR123,
I wish I had better news for you.

This is one of the "annoyances" of the Mark V. Especially with the regulators for steam valves with three LVDTs.

LVDT inputs are associated with servo outputs. For example, LVDT 3 & -4 are associated with Servo Output #2. For Regulator Type 49, LVDT 15, which is typically associated with Servo Output #8 is "re-associated" to Servo Output #2, along with LVDT 3 & -4, for a total of three associated LVDTs for Servo Output #2. Just as you have described.

I'll try to describe how LVDTs are read or written into the control signal database (CDB) for the dual LVDT arrangement and hopefully you can understand it for the three LVDT arrangement. Let's consider a type 43 regulator which selects the higher of two associated LVDT inputs. Further, let's call the first of the two associated LVDT inputs SV1POS_A and the second SV1POS_B, for example (these are the signal names they would be assigned in IO.ASG).

When looking at the LVDT feedback post-I/O card (meaning, after the input is read and scaled by the TCQA I/O card and is then read or put into the control signal database (CDB)), or in other words, when you look at it on any display other than Diagnostic Counters (and, I believe, Pre-vote Data), the value you see for the first associated LVDT will *always* be the high-selected value.

For our example let's say that SV1POS_A was indicating 67% stroke, and SV1POS_B was indicating 65% stroke. If you put SV1POS_A and SV1POS_B into Logic Forcing, SV1POS_A would indicate 67% and SV1POS_B would indicate 65%.

But, if SV1POS_A was indicating 73% stroke and SV1_POS_B was indicating 75% stroke, then *both* SV1POS_A *and* SV1POS_B would indicate 75% stroke if they were in the Logic Forcing display. Even though they're not really indicating the same value, the way the Mark V systems reads and displays the CDB values it will cause them both to *appear* to be indicating the same.

It's been so long since I've worked on a steam turbine valve with three LVDTs that I can't remember. But, I think it's similar, but from what you indicate it might not even be possible to see the value of a third associated LVDT in Logic Forcing (or Demand Display). Sorry; I just can't remember and I don't have a Mark V to play with any more.

The Mark V was designed primarily as a GE-design heavy duty gas turbine control system. It was later modified to be used as a steam turbine control system, and some of the modifications were not as good as they could have been. I believe this is one of those situations.

From what it sounds like, and you didn't say what the third LVDT's value was in DIAGC, but it sounds like the second of the first two associated LVDTs is reading higher than the first. Or, it might be that the third associated LVDT is reading slightly higher than the first two and that's why both of the first two assigned LVDTs are reading the same; but you didn't tell us what the third LVDT was indicating so we can't be certain.

There are just some things which can be viewed at the "I/O card level" with DIAGC which can't be displayed on a "normal" display like Logic Forcing or Demand Display or even a CIMPLICITY display, because they don't exist in the CDB, only at the I/O card level in RAM that is "before" or not read by the CDB for whatever reason.

DIAGC is a "window" into the RAM on I/O cards before the signals are read or written into the control signal database, which are the only signals that can be displayed on Logic Forcing or Demand Displays or CIMPLICITY displays. Not all I/O card-level signals are read or written into the control signal database. And some that are, are done so unusually.

It blows, but that's the way it is.
 
thanks CSA fir your reply,

but i have a question. in our steam turbine there are two main steam control valves and two Reheat steam control valves(IP turbine). all the four valves are having 3 lvdt feedbacks. so the third lvdt
feedback for each valve is defined in another regulator as type 00.

Now as we know for each regulator there are two LVDT inputs. so in case of type 00 regulator i am not able to see LVDT i/p 1 value in logic forcing or HMI Screen but for LVDT i/p 2 i can see the value in logic forcing screen.

now suppose for control valve-1 three LVDT feedbacks are v1, v2 (regulator 1) and v16(regu 8 type 00) defined in and for control valve-2 three LVDT feedbacks are v3,v4 (reg-2) and v15(reg-8).

so i am not able to see v15 value in logic forcing but ican see v16. same way if regulator 7 is defined as type 00 than i can see LVDT-14 feedback but can not see LVDT-13 in logic forcing. the readings in logic forcing and diagnostic counters will be like this (let us say for 50% valve opening.

diagnostic counters Logic forcing
v1 49.98 49.98
v2 49.90 49.90
v16 49.86 00.0
v3 50.01 50.1
v4 49.97 49.97
v15 49.99 49.99

i hope i have not made my question complicated and you have understood my question.
 
Sorry! I'm completely baffled by this question and the data that you are reporting. Also, this post is slightly different from the original post. Which is even more confusing for me.

I would not have even expected to see the results you are reporting for the other LVDT inputs based on my experience, so I can't explain why you are seeing what you have reported. It just doesn't match my experience, but I haven't seen everything and I learn something new every day. (Sometimes, two new things!)

It seems you can see one third associated LVDT value in the Logic Forcing Display but you can't see a second third associated LVDT value in the Logic Forcing Display. It seems the unit is running properly but you can't see the value of one of the third associated LVDTs in Logic Forcing.

It appears from the post that there are no related Diagnostic Alarms and no operational problems related to the fact that you can't see the value of one of the third associated LVDTs.

As was said before, sometimes not all values from I/O card-level RAM are read into or by the control signal database. That's just the way it was programmed. If the unit is operating properly, I don't know how to tell you to force the value to be displayed in the Logic Forcing Display.

Further, it's been said many times before on control.com: the number of people on this planet that can tell you if DIAGC.DAT is properly configured for the PROM and card revisions installed in your panel can be counted on one hand. It was very common for DIAGC.DAT to not be properly set up during commissioning or after commissioning if cards and/or PROMs were changed. So, the data reported by DIAGC can always basically be presumed to be suspect. If you have certain knowledge the DIAGC.DAT on the HMI you are using to view I/O Card-level RAM data exactly matches the PROM and card revisions of the Mark V panel, then you are a fortunate person. Very fortunate.

But, other than not being able to see all LVDT values in Logic Forcing, I don't see a problem.

What does AutoCalibrate report for these servo outputs and LVDT feedbacks? Was ACALIB.DAT properly configured for the site and application? I would tend more tend to trust what AutoCalibrate reported (presuming that it was properly configured for the site and application) than the data from DIAGC.DAT.

Is the unit operating properly?

Have you tried viewing the LVDT values on a Demand Display? If so, what were the results?
 
Top