Skip to Main Content
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.

Status Declined
Created by Guest
Created on Aug 20, 2022

Properly handle Event Frame edits on Event Frames that are generated by the PI Analysis Service

Users manipulate open event frames that are generated by the PI Analysis Service. The manipulation can be: 1) Write to an attribute on the EF 2) Write an annotation 3) Acknolwedge the EF When these manipulations are being performed the Event Frame is checked out to the user performing the changes. From time to time, it happens that a closing event is received and the PI Analysis Service fails to close the Event Frame as it is checked out to another user. This causes the analysis to stop and the event frame remains opens. A possible solutions could be: Retry to close the Event Frame multiple times (configure a timeout or retry count limit)
  • ADMIN RESPONSE
    Aug 20, 2022
    As stated previously, the system is designed assuming that PI Analysis Service is the owner of the open event frame until it closes. If another user (human or software) disrupts this event frame while PI Analysis Service has it checked out, it will cause problems. We currently do not have any plans to change this behavior to support multiple users interacting with an open event frame.
  • Attach files
  • phsutter
    Reply
    |
    Aug 20, 2022
    What is very bad about the current behaviour is that it is not just one event frame that does not get closed, but that the analysis is stopped afterwards and no new event frames are created at all anymore as soon as this happened once. To correct the problem, you have to identify the stopped analysis, and manually restart it in PI System Explorer. As discussed with Techsupport, it currently is not possible to detect and correct this error otherwise (e.g. via a Powershell script etc.)
  • Guest
    Reply
    |
    Aug 20, 2022
    The current behavior assumes that PI Analysis Service is the "owner" of the event frame that it creates, therefore we assume that other users do not write to an event frame that doesn't belong to them. Similarly, for a PI Point, we assume the interface that is writing to a PI Point to be the "owner" of that data stream. We assume that two users, e.g. two interfaces, would not write to the same PI Point (data stream). Earlier in this discussion, it's mentioned that a custom application is being used to write to event frames. Can you describe what you're writing, the criteria that would lead you to start writing, and how often this is done?
  • phsutter
    Reply
    |
    Aug 20, 2022
    We use event frames to mark alarms (generated by event frame generation analyses), and a custom developed web application that allows our users to comment and acknowledge the alarms. Each alarm can be acknowledged only once, and commented multiple times. The time that an event frame is checked out is generally short (1-3 seconds), but that is enough to make this problem happen multiple times per month typically, with the amount of acknowledgments and comments that we currently have. If the PI Analysis service is the "owner" of the event frame, then it should be possible to comment on and acknowledge the event frame via the analysis service, but this cannot be done, we therefore check out the event frame from our application and check it in afterwards again. I can understand that a collision can always happen in this scenario (this is actually the exact reason for a check-in/check-out mechanism), but what is very unfortunate is that the event frame generation analysis breaks when such a collision happens. It stops working and never ever starts on its own afterwards.
  • phsutterRoche
    Reply
    |
    Aug 20, 2022
    A follow-up question would be: how does PI Vision handle the case where a user enters a reason, or acknowledges an event frame? I guess the event frame will be checked out for a short period of time by PI Vision, and the very same situation could happen here as well: an analysis could try to enter the event frame end time exactly during this short period of time where PI Vision has checked out the event frame to store the reason/acknowledgement. In that case, too, the analysis would fail and stay broken indefinitely.
  • phsutterRoche
    Reply
    |
    Aug 20, 2022
    So that means that an event frame should never be annotated nor acknowledged while it is not yet closed (because, as you mention, PI Analysis Service is the owner of the open event frame until it closes). This is creating problems for us, because we use event frames e.g. for alarms, and we therefore are not allowed to store a comment to an alarm on the event frame itself while it is not yet closed. However, this functionality is available in various clients independent of the state of the event frame. It might be the best then if you could disable annotating and acknowledging event frames in PI Vision and other tools for all event frames with no end time, otherwise the risk exists that we run into this problem.