Hello,
We have a AF SDK based WPF application which retrieves the tag data for a given interval of time. Below is the code.
var config = new PIPagingConfiguration(PIPageType.TagCount, 10000);
IEnumerable<IDictionary<AFSummaryTypes, AFValues>> listAvgResults =
pointList.Summaries(myTimeRange, span, type, AFCalculationBasis.TimeWeighted, AFTimestampCalculation.Auto, config);
IEnumerable<AFValues> afValues = listAvgResults.Select(pointResults => pointResults[type]);
foreach (AFValues pointValues in afValues)
{
// constructing the data table here
}
for less number of tags and time interval for 1 hour this code works fine. But when the time interval is for 10 sec for 3 weeks and number of tag is 20, this foreach runs take lot of time to execute (min 1 min) .
while searching i came across OLE DB where there is access to PI archive for getting data..Since the output from the query is directly in DataTable, should I use this ?
And please provide the download link for OLE DB enterprise 2017,
Download links in the below URL are broken
PI OLEDB Enterprise - Announcements
Thanks
Mike
Hello Mike,
The general recommendation is to break larger requests for data into smaller chunks e.g. by creating multiple smaller PIPointList objects or by breaking a larger AFTimeRange into smaller ones. Because you like to display data in a table and I expect you do this with a single Timestamp column and one column for each PI Point, the second option is likely the preferred choice.
When asking for recorded values, the challenge is that you usually do not know the sampling rate of single PI Points which makes it a little difficult to estimate what the TimeRange for a single query should be. The PIPointList.Summaries overload you are using expects an AFTimeSpan which is used as the sampling interval for summaries. With this information and the amount of PIPoint objects in your PIPointList you could calculate the amount of values returned by the summaries call upfront and use this information to break a larger TimeRange into smaller ones. It may be necessary to find a good value for the amount of values to ask for a single call by testing what works. I would start using something between 10,000 and 100,000 values in total.
For PI Points that receive updates at a high frequency, there is still the chance a summary could fail e.g. because the amount of archived events for the TimeRange used exceeds ArcMaxCollect which is a Tuning Parameter intended to protect the PI Data Archive against expensive queries. ArcMaxCollect limits the amount of archived events that can be retrieved with a single call to PI Data Archive. My suggestion is to use TimeRanges of 3~7 days to be on the safe side.
I have checked the download links you mentioned to be broken and found them to work. When checking why they may not work for you, I found that your SSO account is not linked to any site which means you don't have access to any install kit. Please note there was recently a change and these days Developer Technologies are no longer freely available. Please refer to AL00342 - Developer Technologies returning to being distributed with regular licenses.
If you feel your SSO account should allow you to download, please shoot me a private message.
Your application is working with PIPoints. PI OLEDB Enterprise is the Asset Centric OLEDB provider. It does not offer direct access to PI Points. Queries for time series data like recorded values and summaries will have to include AF Attribute references. There is another OLEDB provider also referred to as PI OLEDB (Classic) Provider which offers access to the PI Data Archive. PI OLEDB (Classic) Provider is built against PI SDK which means it does not offer bulk calls. Bulk calls allow asking data for multiple data items (PI Points or AFAttributes) where introduced with AF SDK and are only existent in the library also referred to as RDA (Rich Data Access). Examples for bulk calls are the PIPointList data calls like Summaries and RecordedValues. While it is possible to execute a query against PI OLEDB (Classic) Provider for multiple PI Points, they will result into multiple PI SDK calls - one for each PI Point. ArcMaxCollect limitations need to be considered with PI SDK and PI OLEDB Providers too.