How to increase Mark VI/MarkVIe Data Historian captured live data
- Thread starter Josefzky
- Start date
To my knowledge the Trip History period is fixed and can’t be changed.
Depending on how your HMIs are configured there may be one week’s worth of one hour “Live Data” files captured on a rolling seven day period.
Because of the inconsistent way GE HMIs are configured it’s not possible to tell you you where to find the files. They will usually have .dca or sometimes .dcaST file name extensions and are found in a group of seven folders corresponding to the days of the week. Double-clicking on the filename will automatically open the file using Trender or Trend Recorder.
BUT the files get automatically overwritten every seven days—unless someone manually saves them to another location on the hard drive or a removable drive.
I seem to recall there is some kind of script or configurable way this feature is implemented so it might be possible to increase the period the files are saved without being overwritten. But that’s just a scientific wild-arsed guess from deep memory folds.
Depending on how your HMIs are configured there may be one week’s worth of one hour “Live Data” files captured on a rolling seven day period.
Because of the inconsistent way GE HMIs are configured it’s not possible to tell you you where to find the files. They will usually have .dca or sometimes .dcaST file name extensions and are found in a group of seven folders corresponding to the days of the week. Double-clicking on the filename will automatically open the file using Trender or Trend Recorder.
BUT the files get automatically overwritten every seven days—unless someone manually saves them to another location on the hard drive or a removable drive.
I seem to recall there is some kind of script or configurable way this feature is implemented so it might be possible to increase the period the files are saved without being overwritten. But that’s just a scientific wild-arsed guess from deep memory folds.
Hi @WTF? , thanks for your reply, unfortunately it is saving for 48hr only and I hope it has the 7days saving time frame like you have. I tried to understand the GE manual GEI-100278B for historian settings but still not confident to work on it to our present controller setting. I read some tread about it and yes, most of the guys said its a bit tricky to configure and no one been tried before on how to reconfigure it. I attached also snap shot on historian setting but not sure if this is the right path.
Attachments
I think the Controller Live Data is not the same as the Trip History--but I might be wrong, and GE may have changed the way the two operate. There are Trip History blocks, and you may find some similar way to change the storage time for those blocks; I don't have access to any Mark* VI/VIe VMs at this moment, nor any instruction manuals.
Can you post a copy of GEI-100278B?
How long are thinking of stretching the data collection to? Are you trying to create some kind of historical trend using Toolbox/ToolboxST?
Can you post a copy of GEI-100278B?
How long are thinking of stretching the data collection to? Are you trying to create some kind of historical trend using Toolbox/ToolboxST?
HI @WTF? , we are looking on how to extend the collected E:\GEWorkstationST\RecorderData\G2\TripLiveData file which as per log is only up to 48 hour to at lease a week. Yes I can share the file, see attached.
I hope someone from Control.com made this change and it will be a big help.
I hope someone from Control.com made this change and it will be a big help.
My guess is it's not that difficult.
!!!MAKE A BACK-UP OF THE .m6b FILE FIRST!!! Store it somewhere on the HMI you're using. (Actually, I'd make a back-up of the whole folder with the .m6b file and any subfolders, too, just to be super safe.)
The instruction in the document you sent is for setting up a new configurations (in this case, a Controller Live Data capture configuration)--you don't need to do that. All you need to do is change the one value (Storage Time) in the dialog box for an existing Controller Live Data Capture configuration. (You may want to increase the Collection File Space (MB) as well....)
So what you want to do is to find the existing Controller Live Data capture configuration (if you can find the .reb file you can probably double-click on it) and then open the Controller Live Data controller (probably the same name as the .reb file) and then find the Properties tab and make the changes in the field(s).
Here's where it gets a little sketchy for me... There is an explanation of the steps involved once a NEW Data Historian configuration is complete on Page 4 of the document you attached in the previous email. The difference is that based on the information in Step 4 you're not changing anything else (if I understand correctly) so you don't need to do a Auto Configure (since that's only for a Trip Log that is being created), you don't need to do a Get from Database (since that's already been done and you're not changing the signals that are being capture, if I understand correctly). You will need to do a Validate, Build and Download. Then Step 5 says you will need to Put In Database "... if you intend to trend live data from this Data Historian."
BUT, this is a GE document--and as such, BOUNCES all over the place with steps and instructions and information. (And has been written many times before on Control.com, bad documentation is almost worse than no documentation. And this may be a good example of that (not a perfect example, just a good example ;-) ). So, this is the reason why you want to make back-up(s) before you begin this.
I'm hoping MIKEVI will chime in here and add something if he has some knowledge or information on this. He's a huge fan of Data Capture buffers, for troubleshooting. But, I venture you are trying to create an inexpensive data historian (which you will probably keep tinkering with until something breaks) and I've never tried to do that. And, I'm not a fan of GE's PI-based Historian (it's WAY MORE TROUBLE than it's worth, unless you have years to dedicate to learning OSIsoft PI and all of its nuances and tricks and tips).
Hope this helps. That's all I can add. As you said, maybe someone else has some experience with this, but I rather think not because the documentation is not very good and most people don't write down the steps they take to use for future reference (hint, Hint, HINT!!!).
Please DO write down the steps you take as you work through this, and share them here when you're done. It would be a great help to others--which is really the beauty of forums like this, and in particular, this forum, Control.com.
!!!MAKE A BACK-UP OF THE .m6b FILE FIRST!!! Store it somewhere on the HMI you're using. (Actually, I'd make a back-up of the whole folder with the .m6b file and any subfolders, too, just to be super safe.)
The instruction in the document you sent is for setting up a new configurations (in this case, a Controller Live Data capture configuration)--you don't need to do that. All you need to do is change the one value (Storage Time) in the dialog box for an existing Controller Live Data Capture configuration. (You may want to increase the Collection File Space (MB) as well....)
So what you want to do is to find the existing Controller Live Data capture configuration (if you can find the .reb file you can probably double-click on it) and then open the Controller Live Data controller (probably the same name as the .reb file) and then find the Properties tab and make the changes in the field(s).
Here's where it gets a little sketchy for me... There is an explanation of the steps involved once a NEW Data Historian configuration is complete on Page 4 of the document you attached in the previous email. The difference is that based on the information in Step 4 you're not changing anything else (if I understand correctly) so you don't need to do a Auto Configure (since that's only for a Trip Log that is being created), you don't need to do a Get from Database (since that's already been done and you're not changing the signals that are being capture, if I understand correctly). You will need to do a Validate, Build and Download. Then Step 5 says you will need to Put In Database "... if you intend to trend live data from this Data Historian."
BUT, this is a GE document--and as such, BOUNCES all over the place with steps and instructions and information. (And has been written many times before on Control.com, bad documentation is almost worse than no documentation. And this may be a good example of that (not a perfect example, just a good example ;-) ). So, this is the reason why you want to make back-up(s) before you begin this.
I'm hoping MIKEVI will chime in here and add something if he has some knowledge or information on this. He's a huge fan of Data Capture buffers, for troubleshooting. But, I venture you are trying to create an inexpensive data historian (which you will probably keep tinkering with until something breaks) and I've never tried to do that. And, I'm not a fan of GE's PI-based Historian (it's WAY MORE TROUBLE than it's worth, unless you have years to dedicate to learning OSIsoft PI and all of its nuances and tricks and tips).
Hope this helps. That's all I can add. As you said, maybe someone else has some experience with this, but I rather think not because the documentation is not very good and most people don't write down the steps they take to use for future reference (hint, Hint, HINT!!!).
Please DO write down the steps you take as you work through this, and share them here when you're done. It would be a great help to others--which is really the beauty of forums like this, and in particular, this forum, Control.com.
Hi @WTF? , unfortunately when I talk to my other collogues which is working on MarkVI toolbox apps, they said it cannot be change and if ever we need to increase the data collection, we need to have separate Historian server. So Ibelieved the Manual that we are having is for the Historian application server set up. I guess.. since that window (snap pic) which I posted last time is not available on the Mark VI toolbox.
So probably to make this task easy, we may ask our IT support to create a script for copying the folder before it deleted.
Thanks for your time and replies..
So probably to make this task easy, we may ask our IT support to create a script for copying the folder before it deleted.
Thanks for your time and replies..
Toolbox (and ToolboxST) can be very deceiving and finding configuration information buried several layers down in nested screens can be both challenging and frustrating. Just because a setting or window or dialog box doesn’t pop up quickly when digging through the configurations doesn’t mean it doesn’t exist—it has to exist somewhere or else it wouldn’t capture any data or it would be continually capturing data.
Have you searched for the .reb file? When you find it double-click on it and then start looking through the settings (start by going through the toolbar drop downs (File, Edit, etc.) then by going through the nested configurations on the left-most pane of the Toolbox/ToolboxST window.
And don’t believe everything you’re told. People say a LOT of things about Mark* turbine control systems, and much of what is said is not true and incomplete and some of what is said is just plain false. The GE publications don’t help when they’re so poorly written and incomplete and incoherent.
But if you’re trying to turn Trip Logs into a Historian, while you might succeed in capturing data over longer periods of time that data is uncompressed and will consume large amounts of hard drive and RAM. And, where will you store older files for later comparison/analysis?
Toolbox/ToolboxST isn’t designed for long-term, high-speed data capture and storage and retrieval. It’s designed for high-speed data capture for troubleshooting operational issues and problems of a much shorter duration (such as during starting or acceleration or loading or shutdown), not long term trending using high-speed data.
Trender/Trend Recorder has several options for triggering trends running in the background or slowing the rate of data capture from milliseconds to seconds or even minutes in some cases, but it’s not designed for capturing low-speed data over long periods of time for trending purposes (for example trending compressor discharge pressure and MW over weeks and months and years).
One has to think about the capabilities of the data capture and analysis and what it was designed for versus how it can actually be used for other purposes (that is, short term versus long term). Historians are good (but not great) for long term data capture and analysis but really crappy for short term high-speed data analysis—and Operations Managers and Plant Managers are always confusing the two when trying to troubleshoot problems—either short term or long term. They forget an adjustable wrench isn’t the best tool for tightening or loosening a nut or bolt. Sometimes a box-end wrench or a socket wrench or even a torch is a better tool depending on circumstances. A wrench is a wrench, but there are many different types of wrenches for different needs and uses.
You may be on to something, but you still have some digging and considering to do to achieve your goals.
Have you searched for the .reb file? When you find it double-click on it and then start looking through the settings (start by going through the toolbar drop downs (File, Edit, etc.) then by going through the nested configurations on the left-most pane of the Toolbox/ToolboxST window.
And don’t believe everything you’re told. People say a LOT of things about Mark* turbine control systems, and much of what is said is not true and incomplete and some of what is said is just plain false. The GE publications don’t help when they’re so poorly written and incomplete and incoherent.
But if you’re trying to turn Trip Logs into a Historian, while you might succeed in capturing data over longer periods of time that data is uncompressed and will consume large amounts of hard drive and RAM. And, where will you store older files for later comparison/analysis?
Toolbox/ToolboxST isn’t designed for long-term, high-speed data capture and storage and retrieval. It’s designed for high-speed data capture for troubleshooting operational issues and problems of a much shorter duration (such as during starting or acceleration or loading or shutdown), not long term trending using high-speed data.
Trender/Trend Recorder has several options for triggering trends running in the background or slowing the rate of data capture from milliseconds to seconds or even minutes in some cases, but it’s not designed for capturing low-speed data over long periods of time for trending purposes (for example trending compressor discharge pressure and MW over weeks and months and years).
One has to think about the capabilities of the data capture and analysis and what it was designed for versus how it can actually be used for other purposes (that is, short term versus long term). Historians are good (but not great) for long term data capture and analysis but really crappy for short term high-speed data analysis—and Operations Managers and Plant Managers are always confusing the two when trying to troubleshoot problems—either short term or long term. They forget an adjustable wrench isn’t the best tool for tightening or loosening a nut or bolt. Sometimes a box-end wrench or a socket wrench or even a torch is a better tool depending on circumstances. A wrench is a wrench, but there are many different types of wrenches for different needs and uses.
You may be on to something, but you still have some digging and considering to do to achieve your goals.
