Hello,

I've run across an issue that piqued my interest whilst developing a VB.NET calculation for PI ACE.

In the setup used, PI ACE contains a calculation used by numerous contexts that each calculate a status for the current value of a tag and write the result to another tag. These contexts are scheduled every five minutes and have different offsets on which the calculation is to be run, this offset "cycle" is currently just over 600 seconds (10 minutes). The results that are written by all of the contexts are usede in ProcessBook and another ACE calculation.

For clarification, the tags who's values are used are compressed and stepped tags, compression being on for when the value remains the same.

That other ACE calculation is the one that is developed as new, it's responsibility is counting all of the different statusses that occured for a given timespan (1 hour, 8 hours or 24 hours) using the results written by the ACE calculation explained above. It tries to achieve this by retrieving all the values using the following statement and counting the occuring values in the array (the values written by the other ACE calculation).

'This method calculates the actual violations and returns a result in the form of a private class

Public Function CalculateViolations() As Result Dim periodEnd As Double Dim periodStart As Double Dim statusTag As PISDK.PIPoint Dim value As PISDK.PIValues Dim snapshot As PISDK.PIValue Dim result As Result result = New Result() ' ExecutionTime is the time of execution for the ACE calculation periodEnd = ExecutionTime periodStart = ExecutionTime - PeriodInSeconds For Each ... 'Retrieve all the values for the required period for the current tag values = statusTag.Data.RecordedValues(periodStart, periodEnd, BoundaryTypeConstants.btInterp) snapshot = statusTag.Data.Snapshot 'Implementation is not important for the question. it merely does the counting for a tag. CountViolations(result, value, tagModule, snapshot) Next Return result End Function

Where it gets tricky, is that the new calculation's results may vary depending on the time of execution. Meaning that for a given timespan (12:00 to 13:00) the results may vary if the calculation is executed on 12:00 exactly or 12:10. It happens in some cases, most of the cases return the correct result and we could not find a certain pattern. Therefore our assumption is that this discrepancy is caused by the fact that the old calculation may still write to the underlying dataset used by this new algorithm.

We've checked numerous possible causes (I.E. correct execution times, possible difference in time between the ACE and PI Servers, call used to the SDK(btOutside, btInside), etc.) and currently devised to shift our time window in the history but I was wondering if anyone has experience with an issue like this?

Thanks in advance.

Hi Kenneth,

First, let me make sure I understand your ACE operations correctly. When the new calculation is executed at 12:00, the calculation timespan will be 11:00 - 12:00 (assuming an 1 h interval); whereas when the new calculation is executed at 12:10, the calculation timespan will be 11:10 - 12:10. These calculation results should remain the same because the offset for data coming in is set to greater than 10 minutes. Am I understanding the issue correctly?

If so, what is the offset set to? It seems like you are working with a relatively small time window here, because a new calculation will be written shortly after 12:10. When you said the results vary if the calculation is executed at different times, are the results of the count off by 1? Which calculation is giving you the correct result, the one at 12:00 or 12:10? In addition, do the status tag get values from a data source on top of ACE? Do you get any values on the status tag between 12:00 and 12:10?

General comments on reasons for inconsistent calculation results from what I've seen:

Moving forward, are you going to perform multiple calculations over similar timespans? Or is this step mainly for data verification purposes?