Skip to Main Content
AVEVA Product Feedback


Status No status
Created by Guest
Created on Aug 20, 2022

Enhance functionality of NumOfChanges

By now the NumOfChanges Function in AF Analytics does not take into account the value at the start of the timerange. NumOfChanges only counts the amount of changed values of the recorded values in the given timeframe. If I query the NumOfChanges for today 12 am till now and my Archived Values are: Val1, 11:59 pm (day before) Val 2, 4 am Val 2, 12 pm Val 2, 8 pm the function will result in 0 although in the time from 12 am to 4 am there was Val1. Regarding TechSupport this is not a bug in the functionality, only a bad description of the functionality of NumOfChanges. For now I built a workaround: If TagVal(Tag,Starttime) <> NextVal(Tag,Starttime) THEN NumOfChanges + 1 ELSE NumOfChanges But I think such a missleading function should be changed.
  • Attach files
  • Guest
    Reply
    |
    Aug 20, 2022
    Is your PI Point configured with "Step" on?
  • Guest
    Reply
    |
    Aug 20, 2022
    In response to Stephen Kwan, "Is your PI Point configured with "Step" ..." Yes it is.
  • Guest
    Reply
    |
    Aug 20, 2022
    In response to Jürgen Schmidt, "Yes it is." We're investigating why NumOfChange is behaving this way.  Will respond back with more info.
  • Guest
    Reply
    |
    Aug 20, 2022
    In response to Stephen Kwan, "We're investigating why NumOfChange is b..." Ok, so I know what's going on here.  The NumOfChange function uses the user provided StartTime and EndTime and calls RecordedValues with the Mode of "Inside" on the underlying PI Point.  As a result, we get all the individual events within the StartTime and EndTime, then we sort through and figure out how many changes occurred.  As a result, we don't take into consideration the value at the start time (boundary condition).  There are other complications depending on whether the underlying PI Point is configured with Step = 1 or not.  In the case of a PI Point that is configured with Step = 0, we need to figure out if we should interpolate at the start time boundary or if we should extrapolate.   I've created a backlog item to correct this.  At this time, I do not have an estimate as to when we would be able to work on this.  It needs to be prioritized with all the other backlog items.   Please continue to use your workaround for this issue.