Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Status No Status
Created by juergen.b.schmidt
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?
  • juergen.b.schmidt
    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.