3 Replies Latest reply on Feb 25, 2010 10:24 PM by spilon

    Best practices for handling bad values?


      We're trying to get 1 minute averages for a particular point using VB.Net 2005 code like this:


      myValue = myPoint.Data.Summary(minuteStart, minuteEnd, PISDK.ArchiveSummaryTypeConstants.astAverage, PISDK.CalculationBasisConstants.cbTimeWeighted)


      The code throws this exception:
      "Unable to read tag FI-B626  Error Calculation failed."


      Looking at the tag in Processbook, it shows "Under Range".  Looking at the actual value with an OPC client, it's showing just a little below zero (-0.00something).  The zero for the tag is 0, span is 150.  The pointtype is float16.


      I think in the past we've changed a few tags from float16 to float32 to get rid of the "Under Range", but I can't remember for sure.  The real PI expert is gone for the day, so that's something we'll try tomorrow.


      Even if float32 does solve our immediate problem, it doesn't solve other situations like "I/O Timeout" or "Shutdown".  We have a few different ways we've dealt with this in the past, but decided to ask the experts what the best practices are.


      So, experts, what are the best practices for handling bad values?

        • Re: Best practices for handling bad values?

          Hi Richard,


          Is there no other values for the point within that 1 minute period, other then the "Under Range" event?


          PIData.Summary method will work even if there are bad values within the time range that you are performing calculation for. Unless there are no good value within that time range, then the method will return an exception indicating "Calculation Failed". I think the easiest way to do this is to catch and handle the exception, indicating that there is no good value for calculation in that time period.


          Personally I don't think there is really a best practise on how to handle bad values. In most cases, it is used to suggest an error or an abnormal event that has happened. It would really depends on whether there is any need to take note of such events or to show the users that a problem is ongoing.


          There are different ways to prevent these bad values to be written as well, if you really want to avoid them. "Shutdown" is configured in the point configuration. For newer PI servers, only random points will have Shutdown event written by default, when PI server is restarted.


          "I/O Timeout" would depend on the interface that the point is getting data from. PI OPC Interface, for example, can suppress "I/O timeout" event by setting the flag "/NT" in the configuration.


          You are right that you can prevent "Under Range" event by changing it to float32 point, because PI server will only write this event to float16 points when the value is out of the range as indicated by zero and span.



            • Re: Best practices for handling bad values?

              Hi Han.




              No, there were no other values recorded during that minute.  Looking through the history, this tag is only "active" for a few minutes at a time, and only a few times a week.  But we do have to report it on a 1 minute basis.




              I guess we will continue to handle these situations on a case-by-case basis.




              Thanks for your help.





                • Re: Best practices for handling bad values?

                  As Han Yong suggested, I don't think there is a real "best practice" on how to handle bad values... it all depends on what the data is, where it comes from and what you want to do with it. That said, it seems logical to me that the call throws an exception if there are no good values at all. And even if it did return without error, you would want to check the PercentGood attribute of the returned value, to make sure the calculation result is suitable for you to use.


                  As for the Float16/Float32 discussion, I would personally strongly advise to use Float32's only if you don't specifically need the Under/Over Range clamping that's performed with Float16. Float16 was primarily a way to just store data in less space than what's used by Float32; that was particularly useful in days where storage was rather limited and much more expensive than today.


                  In addition to losing data (when it gets replaced by Over Range or Under Range), you have a potential loss of precision when using Float16: despite the name, Float16 isn't really a floating point number... it is stored as an integer number between 0 and 32767, which number represents a particular 1/32767th increment of your PI Point's value range (a number between "zero" and "zero+span"). In other words, a potential for rounding error.


                  Another potential issue is when people change the "zero" and the "span" attributes of a Float16 PI Point over time - this becomes obvious based on the explanation in the previous paragraph. You can find out more about this in the "1.3.6 Point Type - Float16" section of the PI System Manager I: Essential Skills training course.