Is there a better formula to get the max value?

Currently we have this formula set up. It basically just gets the Max value of the 3 raw tags to get the count.
Current Formula to get the Max.png
Our issue is for some reason it doesn't match the count of the Raw tags and the Analysis tags.

Analysis tag count:
Analysis Tag Count.png
Raw tag count:
Raw tag Count.png
 

and also whenever I checked in Preview Result it gives me 348 count.

We have tried backfilling it and it works but it keeps on recurring so I don't think backfilling always would be efficient.

 

Can you guys help me or suggest what else can be done to get a more accurate readings.

  • Hi.

    First of all, I'd like to discourage the use of the TagVal function with the '*' as timestamp. What you really want is to replace TagVal('Plt_Va','*') with just 'Plt_Va'

    The reason for this is that the TagVal function returns interpolated values if you provide a timestamp that doesn't match the timestamp of any archive value, and this could lead to confusion. By just using the attribute in single quotes, you'll get the value for this attribute using the default 'At or Before' behaviour in the PI System. You'll either get the value exactly Now or the previous archive value.

     

    For the maximum part, I'd probably rather change the analysis type from 'Expression' to 'Rollup', and use the built-in Maximum function there. Configure the analysis to look for attributes in the same element (instead of the default selection of looking in child elements), and use the attribute filter Plt_V? (or Plt_V*) to match the three attributes by name.

  • Thank you for the suggestion and help. I tried this and it does pull out the same output but still having the issue of the raw isn't the same count for the analysis.

     

    Do you think the formula isn't the culprit of why the analysis count isn't the same as the raw count? We are suspecting that because of the data ingestion the hardware wherein the analysis services is choking because of the amount of data ingestion going in. Hence, why the count of analysis isn't the same as the raw count.


  • Event-triggered.png
    Correct me if I'm wrong, from what I understand if we use analysis triggers base on inputs switching the IsLoadSheddingEnabled settings shouldn't make any difference?

    I checked that and it was in False and i switched it in True.

  • If your analysis is time scheduled, it could be subject to load shedding - if the analysis service is choking. But it only applies to time scheduled analyses. If you trigger the analysis based on inputs from the source attributes, this shouldn't apply.

    If you go to the management tab of PI System Explorer, and right click on whitespace in the Operations section (top right), you can open the 'Edit Analysis Service Configuration' to see if the IsLoadSheddingEnabled setting is set to True.

    Load shedding can be done by the service if the duration of one calculation takes more time than the calculation frequency, to avoid calculation lag build-up.

  • Correct, in your case it shouldn’t make any difference.

     

    So, we’re running out of things to check now, but since you say a backfill always seems to fix the issue I would suggest that you could have out of order data coming into your three raw tags.

    Analyses will only trigger on new snapshot events. If any of your input tags have data with earlier timestamps than the current snapshot value, they will go directly to the archive. These events would then not trigger the calculation to run in normal runtime, but they will be included during backfills (since those are triggered by events already in the archive).

    What is the interface type your input values come from? You need to check how out of order data are processed, and you may also need to configure this in the system of origin (dcs/scada). At this point I’d say it’s probably better to open a support ticket with AVEVA to see what they recommend.