MARKVIe Modifications

K

Thread Starter

k000

sir,

1. Exhaust spread 1/TTXSP1 is calculated by subtracting highest TC and Lowest TC values in markVI.

2. While the same is calculated by subtracting highest TC and SECOND Lowest TC values in markVIe.

Q1. Is point 2 true?
Q2. Is point 2 always true for any frame of machine?
Q3. If true,why there is difference in calculations in markVI and markVIe?

PS- i did not find the discussion related to this in previous posts . So apologies, if same has been discussed already and i could not find.
 
khoriwal000,

You would need to tell us what the names of the blocks are (such as TTXSPVn, where 'n' is the version number) in Mark VI and Mark VIe, <b>AND</b> the Frame sizes of the machines, <b>AND</b> the type of combustion systems used on the machine with Mark VI and the machine with Mark VIe.

Also, where were the Mark VI and Mark VIe turbine control panels configured and shipped from?

Please tell us the versions of Toolbox and ToolboxST used for the Mark VI and Mark VIe, respectively (unless the Mark VI has been upgraded to use ToolboxST--then tell the ToolboxST version being used for the Mark VI).

Can you tell us how the formulas appear in the Block Help for both Mark VI and Mark VIe? Can you post pictures of each of the appropriate sections of the blocks to a websharing site and then post links to the photos?

I don't have access to ToolboxST at the present time, nor any GT .tcw files, so I won't be able to respond for a couple of days until I return to my home base.

I would be surprised to find a change in the way the spreads are determined, unless the panel(s) were configured in GE Belfort. I might imagine there is a problem with the way the block is being depicted (it's essentially an ASCII text file representation). BUT, surprises always happen, and more so as time goes by. I have seen some subtle differences in the way that combustion trouble is detected in machines using DLN-I and DLN-2.6, but not in the way the exhaust T/Cs are sorted and compared when developing the three spreads (TTXSP1, TTXSP2 and TTXSP3).

So, please provide the requested information and we may be able to be of help.
 
sir,

>You would need to tell us what the names of the blocks are
>(such as TTXSPVn, where 'n' is the version number) in Mark
>VI and Mark VIe,

ans- blocks in both machines is same and named 'TTXSPV4'


< the Frame sizes of the machines,
ANS- both machines are of same frame size- FRAME 6

>> the type of combustion systems used on the
>machine with Mark VI and the machine with Mark VIe.

ans- both machines are equipped with DLN 1.0 type.

>Also, where were the Mark VI and Mark VIe turbine control
>panels configured and shipped from?
ans- this info is not available with me. But it was configured by BGGTS authorities.(BHEL-GE JV)

>Please tell us the versions of Toolbox and ToolboxST used
>for the Mark VI and Mark VIe, respectively (unless the Mark
>VI has been upgraded to use ToolboxST--then tell the
>ToolboxST version being used for the Mark VI).

ans-version 04.07.03C build 4

>Can you tell us how the formulas appear in the Block Help
>for both Mark VI and Mark VIe? Can you post pictures of each
>of the appropriate sections of the blocks to a websharing
>site and then post links to the photos?

ans. machine with mark VI does not have a block/item help option in the this block. Screen shot of mark VIe machine is as shown in link --- https://ibb.co/etv9sT
 
khoriwal000,

Can you please explain why you think there is a difference between the Mark VI calculation of TTXSP1 and the Mark VIe calculation of TTXSP1?

I cannot read the very bottom of the picture where it talks about how 'k' is determined. But, it's determined from the total number of exhaust T/Cs. The T/C values are sorted an array TTXD2[] from highest to lowest beginning with TTXD2[0] (the highest) and ending with TTXD2[k], and the physical T/C locations are sorted into an array JXD[] from highest to lowest beginning with JXD[0] and ending with JXD[k]. 'k' is going to be the total number of T/Cs minus 1, since the array starts at 0. So, if there are 18 T/Cs, then 'k' would be (18-1), or 17.

So, 0-k will be the highest minus the lowest (since the highest value/location is 0 and the lowest value/location is k). TTXSP1 is TTXD2[0] minus TTXK2[k], which is the highest minus the lowest.

Please--tell us why it's different in the Mark VI, and why you think in the Mark VIe it's the highest minus the second lowest. (Is it because k=17 when there is 18 exhaust T/Cs? REMEMBER: the array starts at 0, not 1. TTXD1[1] is the physical location of the first exhaust T/C; and TTXD1[18] the physical location of the "last" exhaust T/C when there are 18 exhaust T/Cs. When there are 18 exhaust T/Cs, TTXD2[0] is the value of the hottest exhaust T/C, and TTXD2[17] is the value of the coldest exhaust T/C.... And, when there are 18 exhaust T/Cs, k=17--because the array begins with 0, not 1. There are still 18 values in the array, from 0 to 17 (not from 1-18).)

Hope this helps!
 
yes sir,

i also understood the logic same way. But while i am looking at the outcomes of these calculations i.e. TTXSP1,SP2 and SP3, i was suprised.

Images for live values of inputs and outputs of block TTXSPV4 can be seen in the link - https://ibb.co/kZY0z8

Array TTXD2[] values at position 0,1,....,17 are as in link-https://ibb.co/dMJdmo

https://ibb.co/d0ZesT

as clear from images that SP1 is difference of 2nd highest and lowest ones.
 
khoriwal000,

What you are seeing is most likely latency (delays) in screen updates. If you used Trend Recorder on the highest resolution (40 msec) you would even still possibly see some disagreements, but the calculation is what is shown in the block.

HMI screen updates can take as long as 1 sec or more, and every data value on the screen doesn't get updated at the same time at all times. Especially when there are MANY data values on a screen.

<b>AND,</b> if there are issues on the UDH (which there usually are because of issues with CIMPLICITY configurations) then that can increase the time delays even more. If MODBUS is used on the HMI being used to monitor data values problems with MODBUS configurations can, and often do, cause problems with screen update rates.

When you are trying to capture data values, you should be using Watch Windows or Trend Recorder. AND, if you insist on or must use Toolbox, you should shut down CIMPLICITY and close all other windows and try to keep only the data values you want to monitor on a single window.

Now, I'm not saying there's not an issue, because stranger things have happened. I'm just saying that what you see at any instant on a display, particularly a CIMPLICITY display isn't always precisely what is happening in the Mark*. For Mark VI, the data values have to get put on an EGD page, transmitted over the UDH to the HMI, where TCI then has to serve up the data values to the CIMPLICITY project which then has to display them. (This is for "true" Mark VI applications running TCI.)

For Mark VIe, the data values have to be put on an EGD page, transmitted over the UDH to the HMI, where WorkstationST (ControlST) then makes them available over OPC to the CIMPLICITY Viewer which then has to display them on the screen.

There's a LOT that has to go on. Even with Toolbox/ToolboxST, which communicates directly with the Mark VI over the UDH, there can still be some latency issues.

I find the least issues with Trend Recorder, then with Watch Windows, and then with Toolbox/ToolboxST. And the most issues with trying to use data values on CIMPLICITY--which is NOT for high-speed monitoring or troubleshooting. It's a graphical user interface--which DOES NOT directly communicate with the Mark VI/VIe. It has to get data from either TCI or WorkstationST/ControlST.

Finally there's the hardware in the HMI CPU--the graphics card and internal buses. Yes; today's hardware is extremely fast. But, if there are CIMPLICITY configuration issues (which there almost always are--points being asked for which don't exist because the supplier uses templates and doesn't have a standard for removing unused points on displays), and if there are similar MODBUS issues--neither of these usually has a significant impact on the HMI displays and operation--then these can add up to cause problems when trying to monitor or troubleshoot high-speed data.

And, lastly, there's the screens themselves. Some have higher response times than others, and for most operations a fast display isn't really required, and since they cost more, they aren't usually supplied.

This isn't only a problem for GE HMIs and turbine control systems, it's similar for most control systems these days. The scan rates/execution is so fast in the processors that the HMIs can't really keep up in all cases.

Welcome to high technology!

Hope this helps!

Now, if you find when using Trend recorder and/or Watch Windows to capture data to a file on the hard drive the problem you are reporting is consistently occurring, you should provide all your data to BGGTS so they can communicate it to GE for analysis.
 
sir,

minimum interval in trend recorder was 250 mSec.
This is the link for the trend recorded - https://ibb.co/kJ3fj8

XD15 was highest TC, XD16 was 2nd highest, and XD18 was lowest.
for left bar

XD15-XD18=67.5=highest - lowest

XD16-XD18=60.1=second highest - lowest

TTXSP1=59.28 Which is more nearer to (second highest - lowest)

-trend shows that next peak of SP1 was near to 60degC. So even if data legging was there, SP1 should have achieved 67 degC peak value in next few moments.

same was for right bar also.

sir, would you still say it is data legging problem?
i am not satisfied sir.
 
khoriwal000, sir,

The "interval" for a Trend Recorder session is adjustable (and must be specified or changed prior to the start of a data recording session), and I believe 40 msec is the fastest (because it can't get too much faster than the application code scan rate, probably, which usually runs at 40 msec for most heavy duty GT projects).

As was said in the previous reply: Send your data to BGGTS/GE for further review and analysis.

It's impossible to tell anything from the photo that was posted. And, unless the cursors are over "diamonds" (which indicate a data point) any place in between a diamond is interpolated.

It is entirely possible you have discovered an anomaly in the software, unlikely, but possible. Send the data to BGGTS/GE and see if you find satisfaction with their response(s).

And let us know what you find.

(For the record, although I previously worked for GE for many years, I no longer work for GE and have little insight into how things work today. And, if I did work at GE in a management position, things would be very different. Which is why I don't have a management position at GE, or any other position at GE.)
 
To see if the block is working, you need the inputs (TTXD2 array) and TTXSPV4 block outputs from the exact same controller frame. You've got sreenshots of both, but probably from different points in time, so they don't match. As CSA pointed out you can't go by the HMI screens (even though both the inputs and outputs are shown) because they are not guaranteed to be coherent.

In your HMI screenshot, Spread #1 should be 61C based on the values shown in the screenshot but shows up as 58C. This does look like a typical display "aliasing" issue in HMIs that gets reported as a bug a lot ("Hey, my HMI says 1+1=3!"). There is also some unit conversion and rounding going on here that adds uncertainty to the numbers. Taken together, the SP1, SP2, and SP3 numbers on the screen are reasonably close to the data set, close enough I don't think there is a calculation error.

I setup a test case with the TTXSPV4 block setup exactly as in your block screenshot, and with the array values from your TTXD2 array screenshot, and got the values I expected to see for TTXSP1, 2, and 3 (109, 83, 76). This is reasonably close to your screenshot of the outputs (103, 77, 70) to be expected variations at a different point in time. So, again I don't see an issue.

If you can get the input array values and TTXSPV4 output values in the same screenshot from ToolboxST, they should match exactly, excepting any coherence/aliasing issues (which does occasionally happen in ToolboxST, though less visibly as the data collection rate is higher than the HMI).

Hope that helps!
 
kl000,

How many "failed" exhaust T/Cs is the machine currently running with?

Would you please post the 40 msec .trn file to a web-hosting site and post the link to the file on control.com?

It seems one respondent to this thread works for GE; perhaps that individual will provide a contact where you can send your information (including ToolboxST version and .tcw archive file) for some assistance with the problem you are reporting--<b>AND</b> reply back to control.com as well with the results of the analysis.

Personally, I suspect something is amiss with the configuration of the project file, but I don't have the resources to be able to help you get to the bottom of this dilemma. I suspect <b>only</b> GE can help you get the satisfaction you are so desperately seeking. And I suspect only GE would reply back with the full and complete analysis of this situation.

And, what's with the "sir"? We're all trying to understand and help you, so a poor attitude isn't conducive to getting your satisfaction. And not providing the 40 msec .trn file without being asked isn't helping your credibility, either.
 
>How many "failed" exhaust T/Cs is the machine currently
>running with?

Ans-> All the exhaust thermocouples are healthy.

>Would you please post the 40 msec .trn file to a web-hosting
>site and post the link to the file on control.com?

ans- https://ibb.co/bNvyBo
pl view the image in full resolution.
TTXD15 is highest one,TTXD16 is 2nd highest one,TTXD18 is lowest one.

>It seems one respondent to this thread works for GE; perhaps
>that individual will provide a contact where you can send
>your information (including ToolboxST version and .tcw
>archive file) for some assistance with the problem you are
>reporting--<b>AND</b> reply back to control.com as well with
>the results of the analysis.

ans- pl provide contact details. are u talking about demigrog2?
 
k000,

Post the .trn file--not a grainy, dark photo of one bit of data. From what I see you have set the left- and right cursors for approximately 0.040040 seconds--<b>BUT, THAT'S NOT 40 msec resolution.</b> The data does not appear to have been collected at a 40 msec rate.

The data in the 'Traces' tab will have diamonds where actual data was captured. Anything else is interpolated by Toolbox/ToolboxST.

If you post the .trn file, and the archived .tcw file, I believe that should give anyone looking to try to help and understand the information they are looking for.

But, you need to create a new trend recording session and specify 40 msec before you gather data. (I think you can open an existing .trn file, and before you start recording data with it you can go to "Settings" or whatever it's called and change the resolution. If you want to use the same .trn file so you don't have to re-enter all the pointnames, you can save it a file with a new name, then delete all the current data (if you want to do that), set the resolution to 40 msec, and then start recording data to the .trn file with the new <i>at 40 msec resolution.</i>)

Posting photos of what you want to point out as a problem isn't the right way to go about this. If you post a full .trn file (you're posting an image file; most web-sharing sites will accept ANY file, not just image files) with proper resolution that would help a lot. If you also archive the .tcw file of the turbine in question and post that also that should give anyone almost all the information they need to help.

Now, I have three final questions: How many Mark VIe-controlled turbines are exhibiting this problem? If only one turbine has a Mark VIe, tell us that, too. Because you said, if I recall correctly, you have both Mark VI and Mark VIe controlled turbines at the site, and only the Mark VIe control is exhibiting this problem.

Was the Mark VIe that is exhibiting this problem an upgrade from an older version of Mark* turbine control system? If so, which version?

And, lastly, is the Mark VIe that is exhibiting this problem a TMR, DUAL Redundant, or SIMPLEX control? And, if there are other Mark VIe's at the site, please tell us what type of control (SIMPLEX, DUAL Redundant, or TMR) they are, please.

We need <b><i>actionable data</b></i>, not dark, grainy photos of screens.
 
khoriwal000,

Try this: Open any .trn file. Select any bit of data, and don't zoom in on the data too closely. Then click on either the left- or the right cursor and drag it to the center of the data. Now, while watching the data values in the 'Traces' tab at the lower portion of the window press the left- or right cursor keys on the HMI keyboard. The cursor which you had dragged to the center of the screen will move to the left or the right, and as it moves, and you continue to watch the data in the 'Traces' tab, you will see small diamonds (I think that's what they are--I don't have access to Trend Recorder at this writing) appear in the 'Traces' tab next to the point name.

The "marker" signifies an actual data point that was taken during the trend recording session. ANYTHING between those data points with "markers" (the little diamonds) is interpolated by Trend Recorder and is NOT actual data, but it makes it possible to draw straight lines between actual data points.

So, only the data points with "markers" (little diamonds) are real, actual data points. If you place one of the cursors in Trend Recorder on one data point, and then move the other close to the cursor and use the keyboard cursor keys to move the second cursor to the very next data point (signified by "markers" (little diamonds)) and then look at the time between cursors at the lower right area of the Trend Recorder window it will correspond to the data-gathering rate of the trend recorder session, such as 40 msec, or whatever the rate was chosen to be. (Actually, I think once someone chooses a rate when setting up a Trend, that becomes the default rate unless someone goes into the Setting of Trend Recorder to change that, or unless someone uses the Trend Recorder Wizard, which I think, when being used to create a Trend Recorder session for the first time, asks the user to choose a data collection rate.)

Again, I'm NOT saying you haven't found a software bug--but I AM saying that you have not provided good, solid, actionable data for anyone to analyze.

Trend Recorder is a VERY POWERFUL "tool" to use for troubleshooting, and it is not that difficult to use. One should always be taking some time to gather data using Trend Recorder, and then making time to go back and find out all of the little tricks and features of Trend Recorder. It's possible to hide data points to narrow down what's shown on the display to a few important points. It's possible to change the thickness and color of the pens for individual data points, making it easier to watch what's happening. The little trick for making tiny moves of the cursors above is also very useful. And, the times shown in the bottom of the Trend Recorder window for the cursors is also extremely helpful.

But, none of this is intuitive or "natural." One has to use the Trend Recorder to discover and use the various features. One thing that most sites DON'T do is to make recordings of start-ups and shutdowns--good start-ups and shutdowns. These can be used to compare against trends of suspected bad start-ups or shutdowns.

Also, the Trend Recorder can be set up to run in the background and start when some specified event triggers it to start recording data. It really is a very powerful tool, if configured correctly and used correctly.

And, one has to remember when analyzing the data in any Trend Recorder file that every single point on any line is NOT real data--only those points which have the "markers" (little diamonds) next to them in the 'Traces' tab. AND, some data points can't be captured as quickly as they are being used in sequencing. For, example, servo-valve output current can change, in a Mark VIe, at the rate of 100 times per second (a 100 Hz rate). The REFERENCE for a servo-operated device (a fuel control valve; the IGVs) will only change at the project's scan rate (typically 40 msec for most GE-design heavy duty gas turbines, which is 25 times per second), but the servo-valve output card looks at the feedback value versus the reference value and changes the output as necessary to try to make the actual feedback value equal the reference value 4 times before the reference might change. And, these changes can't be recorded using Trend Recorder.

So, take some "down time" and learn to use Trend Recorder's features. If you do something to the file you are working on ("playing in") and don't want to save those changes, just exit Trend Recorder without saving the data! It's as simple as that. But, DO "play with" Trend Recorder, and it will become one of your most powerful tools for troubleshooting and maintaining a turbine.

Some sites have Historians; some use OSIsoft PI, others use PROFICY Machine Edition's historian product. BOTH of these require extensive knowledge of the product/application, and both require LOTS of configuration to get them to work properly. And, both of them are usually NOT useful for high-speed data acquisition and trending/analysis. And while these applications can be very useful for many troubleshooting activities, both have some very serious shortcomings, mostly around configuration issues (neither is usually properly configured from the OEM to provide truly meaningful data right "out of the box").

Hope this helps--and we are very much looking forward to seeing the .trn files from your site, AND to having the archived .tcw file to use to troubleshoot the configuration of the ToolboxST project file.
 
This thread caught my attention and I looked at 2 different generations of MK-6e 7FA controllers in our system.

I was surprised to find that for our MK-6e systems Spread1 is calculated using the 2nd highest and lowest exhaust T/C. Likewise, spd2 and 3 use the 2nd highest. This is true for a 2010 vintage plant with tool box 4.07.03 and the TTXSPV4 block as well as for 6 units at 2 other plants which were migrated from MK-5 to MK-6e and Toolbox 5.04.06 and the TTXSPV6_1 block.

I determined this using simulator dongles, we purchased MK-6e virtual controller dongles for both versions of toolbox. I have verified that the logic is not calling it failed.

The operator training and other documentation provided for these upgrades did not mention the change is philosophy for spread calculation. I have consulted other more experienced personnel than myself, including former long time GE employees and they have not heard anything of GE changing the spread calculation methodology.

I intend to look further into this, it is interesting.
 
I think this has been around since TIL 1524-3 which came out at least 10 years ago as a recommended (but I think optional) software upgrade. This upgrade allows one exhaust thermocouple to fail high. After the modification, the Spread 1 will be calculated as the 2nd highest minus lowest, Spread 2 as the 2nd highest minus 2nd lowest, and Spread 3 as the 2nd highest minus 3rd lowest. All other functions will remain the same.
 
Shortly after posting my previous, I found TIL-1524 issued in 2005 which offers the change as an upgrade.

Also, the TTXSPV6_1 block has a HIGHSEL parameter that defaults to false, which if true uses the highest T/C in the spread calc, the 2nd highest if false.

For ToolBox4 with the TTXSPV4 block, logic upstream and downstream of the block does the same thing in logic, manipulating th value of the first element of the TTXD2 array to make it the same as the 2nd, and then after the block sets it back.
 
sorry for the bad quality images.

Actually i have kept cursors(so that values can be checked at two sample points) over diamond shaped sample points which caused diamonds not to be appeared.

I will post .trn file as soon as possible.

> How many MarkVIe-controlled turbines are exhibiting this problem? If only one turbine has a Mark VIe, tell us that, too. Because you
>said, if I recall correctly, you have both Mark VI and Mark
>VIe controlled turbines at the site, and only the Mark VIe
>control is exhibiting this problem.

ANS- sir, Total 3 frame6B ,machines are there. machine1 and 2 are having marke6 while machine 3 is having mark6e. Only machine 3 (with mark6e)is showing the problem which we are discussing.

>Was the Mark VIe that is exhibiting this problem an upgrade
>from an older version of Mark* turbine control system? If
>so, which version?

ANS- sir, machine 3 was having mark V at earlier days and was upgraded to mark VIe after some times.
also machine 1 and 2 were having mark IV and these were upgraded to markVI.

>And, lastly, is the Mark VIe that is exhibiting this problem
>a TMR, DUAL Redundant, or SIMPLEX control? And, if there are
>other Mark VIe's at the site, please tell us what type of
>control (SIMPLEX, DUAL Redundant, or TMR)

ANS- only one mark6e , TMR
 
I'd still like to get the values for the input TTXD2 array and the outputs TTXSP1, TTXSP2, and TTXSP3 from the exact same frame. I've got a TTXSPV4 block right here in front of me (Mark VIe runtime V04.07.06C on a UCSA controller), calculating TTXSP1 correctly (highest-lowest).



 
Top