3 Replies Latest reply on Dec 12, 2017 4:04 PM by stuart.watson

    AF Relative Times - Inconsistencies in Data Retrieval

    stuart.watson

      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.

      2017-12-07_12-01-45.jpg

       

      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.

       

      2017-12-07_13-19-54.jpg 2017-12-07_13-26-53.jpg

       

      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?

        • Re: AF Relative Times - Inconsistencies in Data Retrieval
          bbregenzer

          Hi, Stuart.

          I haven't had much time to dig into this, but at first glance, it looks like it might be an issue with the By Time method.  Have you tried setting this to Time Range Override?  This should force clients to use the offset specified in the Relative time field rather than using one specified in the in the client (such as the time range of a Vision display).  Pleas let us know.

          1 of 1 people found this helpful
          • Re: AF Relative Times - Inconsistencies in Data Retrieval
            Roger Palmen

            Same here, did look over the post and did not spot any obvious issues. But relative time can be deceiving. From a big fan I now try to stay out of that.

            A good read on the unexpected details can be found here: Request Rejected

            2 of 2 people found this helpful
              • Re: AF Relative Times - Inconsistencies in Data Retrieval
                stuart.watson

                Very helpful article. Looks like the behavior is what is expected, just a bit counter-intuitive.

                It also makes the original intent (using RelativeTime to correct for machine timing inconsistencies) not workable.

                 

                One more fly in the ointment. Below is the output from PI CoreSight 2016 R2, plotting the tag, with the Offset, and also 2 attributes withwith TimeMethod= Before and After.

                We would expect for the Offset attribute (orange) to mirror the Tag (blue), but with an offset determined at the start time (which it does), and for the Before (green) and After (purple) attributes to overlay the Tag attribute.

                However, they don't, even though they claim to have the same value. They always start at 0 - even when I change the time range.

                Fairly sure this is not the correct behavior.

                 

                1 of 1 people found this helpful