AVEVA™ PI System™ Feedback Portal

Welcome to our 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.

Add a new idea Subscribe
Status Tell us more
Product AVEVA™ PI Server
Categories Analytics & Calculations
Created by Guest
Created on Aug 20, 2022

RELATED IDEAS

Override output timestamp when the output is also input for the analysis

If the output of your analysis is also used as an input for the analysis, the option offset the output timestamp relative to the trigger time is grayed out and you see the message "Cannot override output time stamp if any output is used as an input within an analysis". This protection makes sense sometimes because you could cause unsafe triggering scenarios, but there are also valid configurations that are blocked by this. It would be good if there was some way to override this protection in AF in certain situations. The PI Square post below also describes a similar use case: https://pisquare.osisoft.com/thread/15971-cannot-override-output-timestamp-if-any-output-is-used-as-an-input-within-an-analysis
  • ADMIN RESPONSE
    Aug 20, 2022
    For this particular use case, you should be able to use the TagTot() function which executes at 6:00am with an output timestamp override for 5:30am. It's not clear why you're using output as input. Can you provide an example?
  • Attach files
  • SteveTaylor
    Reply
    |     Oct 24, 2024

    Input checking is a totally normal aspect of building any analytic, and so it should be expected this may be used for any type of analytic. For example, I have an analytic which takes a complex Digital input showing a unit's live operating status, (including many states such as Pretreat, Operation, Backwashing, CIP, Offline) and uses various system parameters to create a simpler filtered output status, with just two or three statuses. The unit does occasionally run in unexpected orders if it has been manually shut down mid-cycle, and so the analytic needs to check the current value of the filtered output status as part of its logic to ensure that it is stepping to a sensible filtered state that will enable KPI calculation. The analysis output time may be selected to correspond to the original status change time, or may be adjusted if a conflicting indicator is detected (non-zero flowrate, for example).

    I have seen other cases where Analyses are designed to check some logic and then increment its output value, but have to send it back to the top of the current hour rather than the current timestamp. The analytic can only correctly increment the output value by reading its own previous output value.

    Occasionally analyses need to check the last value of their own output, and occasionally they must override their output timestamp. Plenty of engineers do come up against this limitation (layer of protection), and then purposefully design around it.

  • Pete Long
    Reply
    |     Aug 20, 2022
    One example of crazy time stamp shifting would be lab samples. Samples from the day before are tested some time, any time, later in the day or sometimes a few days later with the time stamp forced back to match the sampled time (i.e., using PutVal or DataLogger). The analyses need to wait for the samples to be entered, but then refer to them at the sampled time then apply it's override for final synching of the output.