Today is...
Sunday, July 15, 2018
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
MARKVIe Modifications
Why SP1 is calculated differently in markVIe?
0 out of 1 members thought this post was helpful...

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.

0 out of 1 members thought this post was helpful...

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, AND the Frame sizes of the machines, AND 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.

AND, 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.

0 out of 1 members thought this post was helpful...

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.)

1 out of 1 members thought this post was helpful...

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!

sir,

I recorded 40mSec interval trend. Same problem is observed.

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--AND 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 only 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--AND 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--BUT, THAT'S NOT 40 msec resolution. 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 at 40 msec resolution.)

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 actionable data, not dark, grainy photos of screens.