We have some older equipment and manual processes, which means that the timing of PI data around an event tend to have a spread (plus or minus several minutes, varying from event to event).
We are able to calculate the offsets between processes, and are hoping to use Relative Times within the Asset Framework to correct for the issues
While looking at Asset Framework attributes with Relative Times and offsets we have come across some inconsistencies in the returned data, when using relative times.
Here is a demonstration (not real data).
We have out data PI tag, our offset PI tag, and the offset data setup as AF attributes.
The 1st attribute is a PI Point that points to a PI tag that holds our data - in this case the minutes of the hour (01:00, 02:00, etc. = 0; 01:01, 02:01, etc. = 1; etc.) - so it increments from 0 to 59.
The 2nd attribute is a PI Point that points to a PI tag that holds a string representation of the relative time offset we would like. In this instance it is negative twice the minutes of the hour, so it decrements from -0m, -2m, -4m, ... , -118m.
The third attribute takes the value of the first attribute, with a time relative of the second attribute:
If we pull that data using the PI DataLink function PIArcVal, we get the behavior we would expect (the offset increases faster, so we get a decreasing value)
All other methods of data retrieval have a constant offset - the value at the range start time. Here are 2 different start times - note the different offsets.
So, the Timed DataLink function, in this case, does not return "actual or interpolated sample values for a PI point or PI AF attribute at specified time stamps" as the Live library claims.
Does anyone know - what is the expected behavior?
And if there is a way, outside of recalculating and storing all of our data at the offset, of performing analysis on the offset data?