"Outputs at Start"group

To answer the admin response above, the simple answer is that not all customers have unlimited PI tags and when applied to several thousand assets, this adds up to be allot of PI tags. Maybe that is AVEVA's goal? Not to mention the extra steps we need to take to create the PI tags and dump data to them. Why not just allow the option to send variables or data at the start of the event, or the end? I can't tell you how much time I’ve spent tinkering with things just to get the data at the start of an event frame.

Further after two years, why is the status "NO STATUS?" I really feel like AVEVA has not made many positive changes over the last 3 years. I used to think OSISoft was amazing responding to customers....

This has been out here two years! Most people want the data at the start of the event. I think its allot that we have to do all this "Magic" just to get values or valrriables at the start of the event frame. We should be able to return the start or end values. I don't think this is much to ask!

HI, I would like to capture the real startTime of the Event. In my example, my eventframe is like this: timeEq('tag','*','-10m',"On")> 600. So at Output Start I would setup something like EventFrame("StartTime") + '-10m'. And I am agrre with other comment. Same package, we don't have to create additional anlysis!. You have "Output at close", why you don't develop"Output at Start".

Hi admin,

Requirement:

PT5550>120bar or PT5551>120bar,and the two pressures keep 2hours , then trigger a event and send an email to the our cutomer.

we need a future timestamp (the event start time +45h) in the email . This timestamp is cutomer's delivery time. How to do it. Thanks.

if we have outputs of starts,Maybe the function is simple.

The Archived output timestamp for the event start time that mapped to a PIPOINT data reference attribute Written in the archive at the end of the EF. I need to use this value (the archived Event start time) for another analysis even if the event not ended yet and i can't do this now.

A limitation with a separate analysis that mirrors the EF Start Condition is that a normal analysis does not have the capability to easily do the "True For X" check that EF analyses provide.

The other workaround with using the EF start time in the "Output at Close" is also limited as the output timestamp can't be set. So you can write the value of something at the EF start time into a PI Point, but only with the timestamp of the EF end time.

Capturing values in an event frame also doesn't help, as those values are not easily available in the rest of the PI system.

The recommendation from the Admin is what we are forced to do now. Would much rather have the data available when the EF starts and ends instead of having to create multiple analysis

Event frames provide a means for "packaging" related data surrounding the event. An example might be calculating TagMax(), TagMin(), TagAvg(), etc. of a group of values just prior to EventFrameStart. Keeping the calculations within the event frame aligns the timestamps based on the event frame. This ensures that the results are sychronized by the event.

While this would work that fact that have to create additional Analyses is the main drawback. Its nice to have everything packaged up in a single Analysis that is related to what trying to accomplish. If there was an ability to Output at Start, then could calculate value(s) that were involved in triggering the EF and write the results to attributes on the template, all within a single Analysis.

If could do this on a single Analysis, which is possible with the Output at End function currently available, adding the ability for doing this on Output at Start would increase the usability of this while not creating multiple additional Analyses just to calculate a value (that I am already calculating on a different Analysis).

Justin Jackson
Ameren Generation OT Support
jjackson9@ameren.com

Help Desk: 314-554-4357
piregsupport@ameren.com

By this logic, you never would have created functionality for an output at close. From a management and readability standpoint, it makes more sense to have all outputs related to a particular event frame all contained in the same analysis. Cascading analysis are not easy to follow and troubleshoot.

Yes, we really need this function.

Yes! So many use cases to think of. In many cases you want to know something when it started, and at what time, not when it stopped.

Can you provide some example use cases?

I want to write to an output when the Unit comes offline. I also want to write to an output when the Unit comes online. I would like to do that with One event frame generation analysis, instead I have to have two. Offline Status analysis writes to the "lastonlinedate" output at the close of the event frame. The Online Status analysis writes to the "lastofflinedate" output at the close of the event frame.

You can do that with currently shipping software. Just configure an attribute with a Formula Data Reference and a %StartTime% or %EndTime% substitution parameter. This would not work if you wish to write the start and end time to a PI Point. If I have misinterpreted your needs, please let me know.

In response to Roger Palmen, "Yes! So many use cases to think of. In m..." In a more general sense i typically breakup logic into two parts: first determining if something is happening, when did it start and stop?, and secondly recoding an EventFrame on that. To determine when something happens i create an analysis and output the results to a PI Point. That allows me to answer questions like: how often did this happen? How long was this the case? What was the last occurrence? Those questions i can't easily answer within PI using EventFrames. The EventFrame i use to do, well, eventframe stuff, and i trigger this on the first PI Point. Having an option to have outputs at start allows to combine this logic into one unit instead of spread over two.   Take a simple batch as an example, i need both a PI Point (when is a batch running) and an EventFrame (batch reporting, visualization) to answer these questions.

In response to Jim Gavigan, "Yes, I will often save the start time of..." Exactly! Or monitor that a batch has been running longer than expected. Or no batch has been running longer than expected, or...

I use Event Frames to capture OPC AE events. Since i have a start condition that is the most important to capture and now i only can capture at close, it is necessary to have the option to capture "at start" conditions.

In response to Roger Palmen, "In a more general sense i typically brea..." Yes, I will often save the start time of an event as a PI tag and then have a running duration as a PI tag to show the operator....