3 Replies Latest reply on Oct 15, 2018 3:38 PM by skwan

    Avoid Saving Values at Same Timestamp, Instead Save at Next Available




      To preface my question, we have 5 alarm PI tags for our system. These tags are being populated with values from our EMS. From those alarm tags, I am using the Analysis function for String Search (InStr) to find specific alarms that are then used in some filtering equations I have set up. Essentially, if there is maintenance work going on, then there will be an alarm that comes in before the circuit gets de-energized. I have alarms set up to send alerts when circuits are de-energized and I am using the alarms to filter out the planned outages.


      The issue I'm having is that it is entirely possible (and common) to receive multiple alarms at the same timestamp, even down to the millisecond level. The way our interface and tags are set up is that it saves all of those values at the same timestamp. The functions for the analysis are only able to handle one value per timestamp (KB01667). Thus, if there is an alarm I want, but is stored at the same timestamp as another, the one I am looking for is ignored by the analysis, and as a result I get an alert for an outage that was planned.


      I've done some looking and found a discussion on maybe changing the config to ARCAPPEND or something like that, but I haven't been able to quite understand how to implement it (How to avoid two values with same timestamp ).


      Ideally, what I want it to do is to check if a value exists at that timestamp, then if one does, it will add one millisecond and try again. Is that doable via a setting change somewhere? Or would I need to use some other method such as PI ACE?


      Any help would be appreciated, I'm fairly new to this Admin role so I'm still trying to learn all the ropes with the configuration stuff.



        • Re: Avoid Saving Values at Same Timestamp, Instead Save at Next Available

          So this boils down to PI Analysis Service not designed to trigger off multiple inputs at the same timestamp.  The current behavior is that we would trigger off the 1st value and ignore the rest, if they are at the same timestamp.


          However, if you use AF 2018, you can use the new RecordedValues() function to retrieve all the archived values within a time range, even if there are multiple values at the same timestamp.  You can then use the new FilterData() function to filter out the specific alarm that you are looking for.


          What I don't understand is why you would want to add one millisecond to the data?  By doing so, you've changed the fundamental property (time) of the data.


          Steve Kwan

          2 of 2 people found this helpful
            • Re: Avoid Saving Values at Same Timestamp, Instead Save at Next Available



              I didn't necessarily "want" to add anything to the data, but it was the only workaround I could think of for my problem. For the most part, we only look at the second level of granularity on our pi tags so adding a millisecond doesn't pose any major issue to us unless there were 100 entries at the same time. Also, these are alarm tags so the value stored is a string that includes the original timestamp in it, so the only thing we really care about is that it is stored and we can retrieve it.


              And thanks! I didn't know there was a new function that could do that. We're currently on AF 2017 R1, but this marks 2 important things that 2018 would fix for me, so I'll have to see about making a push to upgrade.