5 Replies Latest reply on Mar 21, 2013 12:13 PM by Gopal

    Calculation Problem.

    scottl330

      I have a calculation that I have been asked to provide using PI data that I am struggling with and was hopeful that someone out there has done something like this in the past and can provide guidance.

       

      The situation is that we have 67 ovens per battery; each oven has a thermocouple with a scan rate of 1 minute.  There are three TC's per oven, so we need 3 seperate calculations for each TC.  We want to be able to take a moving 72 hour average for the entire 67 ovens.  One major issue is that the TC’s commonly report band values, negative values, EquipFail, or 0 for example.

       

      My challenge is to have a formula that will exclude any value outside a certain range, take the average of each oven individually, then take the average of the 67 ovens. There are 4 batteries total, so performance is a consideration for this project.

       

      I was looking at using a performance equation with the TagAve function for each oven and then use the AVE function, but am struggling with a good way to remove the bad values. I am also concerned that using a PE with 67 ovens per battery and three tags per oven might cause performance issue.

       

      Any ideas?

        • Re: Calculation Problem.
          mhalhead

          Hi Scott,

           

          I'm assuming that the tags your are averaging are all Float32 tags? A float32 will log the values outside of the zero and span; a float16 would have made this easy as values outside the zero and span are marked as above high limit or below low limit. There are other concerns with using float16 so I'm not suggesting that this is the solution. I think that you will struggle with a PE for this because with tagave the values outside the zero and span will be included.

           

          A totaliser however will probably be the best solution for the individual oven tags. You can easily create a totaliser that has a value filter to include only the values within the required range by adding a filter expression. A totaliser has the added benefit of working of the snapshot subsystem and therefore should be more accurate. There are disadvantages to totalisers but that is a different conversation.

           

          To aggregate the totalised values across all the ovens and batteries I would look at using ACE. You could use ACE for everything but I think that the combination of totalisers and ACE would give you the best result.

           

          Regarding performance. 201 Totalisers are well within PI's capabilities so performance really shouldn't be an issue.

            • Re: Calculation Problem.
              scottl330

              Yes, these are all float32 tags.  I have not used a totalizer to filter values, I will look into that.

               

              We have ACE installed and running, but my programming skills are not very good, so it will be interesting to see if I can use this to improve my ACE skills

                • Re: Calculation Problem.

                  Scott, have you looked at doing it in AF?  For example:

                   

                  TimeMethod=TimeRange;RelativeTime=-72h;TimeRangeMethod=Average

                   

                  Blue line is the moving 72 hour avg.

                   

                   

                   

                  7563.PB.PNG

                    • Re: Calculation Problem.
                      mhalhead

                      Hi Scott,

                       

                      As a variation on Gopal's suggestion you can use AF to create the PI Totaliser points (you can use the point creation and update features in AF to create totaliser, PE's, ... most people overlook this); this will make it very easy to manage the point creation and updates. You can then use AF to handle the roll up fairly dynamically. There is a white paper on how to create a roll up data reference.

                       

                      Comments on the Roll up DR: This is not the long term future of handling roll ups; Abacus will fulfil this role in the future (we all waiting with baited breath). Roll ups can become very expensive and therefore flow; particularly if you start traversing large portions of the AF hierarchy.