6 Replies Latest reply on Oct 26, 2018 1:25 AM by John Messinger

    Programmatically test performance equation syntax


      We are in the process of transitioning from a different historian into Pi, and need to mass create performance equation equivalents of quite a number of virtual calc tags.

      With some pattern matching, and a few other tricks, I believe I can translate the existing code to a PE equiv, but was wondering if there were a way to programmatically test the syntax prior to loading up the PE tags.


      IE, translate the code, test the PE algorithm, if works, flag for promotion to Pi, if not, flag for further assessment, as part of an automated process.

      Assuming many systems have been transitioned to Pi, has anyone had to do something like this, or have some viable suggestions as to how it could be achieved?




        • Re: Programmatically test performance equation syntax
          John Messinger

          Hi Mike,


          Interesting question! As I've thought about this, I really can't think of a way that you could reliably test PE syntax in an automated fashion, at least not simply. Given that the rules of PE syntax are fairly well known, you could write your own custom parser and syntax checker, but this seems a lot of effort for what sounds like would be a one-off requirement.


          I'm assuming that this is also related to your PHD migration that you asked about earlier in the year, and if so will make the further assumption that moving directly to AF Expression Analyses may not be an option for you (though it would be the way to go, especially if there is a lot of duplication of your PE's for similar assets).


          Short story - I'm not sure how you could do this, and if it's even possible without a load of custom code. I'll definitely think about it some more, and be watching this post to see if others have options they can share.

          • Re: Programmatically test performance equation syntax

            Hi Mike Worby,


            I'm not sure the best way to do this, but there is a utility that gets installed with PI Data Archive called pipetest that you can call from a command window and use to validate performance equation syntax. You could write a fairly simple script that uses this utility to validate the syntax of your performance equations before building them in PI. More information on pipetest can be found in the manual here.




            3 of 3 people found this helpful
            • Re: Programmatically test performance equation syntax


              In a previous position, I had to write some code to execute PE calculations; the calculations were loaded from a flat file.

              Your question has caused me to search the recesses of my mind to remember what I did.

              Since you've asked for a coding solution, look at the PI-SDK IPICalculation examples.

              Using the PI-SDK Utility, I went to "Help", "PI-SDK Help", "Search" and enter "IPICalculation Example".

              The code is in VB format, not .NET, but it was the code base I used for my solution; you should be able to derive what you need from there.

              Hope this helps...



              2 of 2 people found this helpful
                • Re: Programmatically test performance equation syntax
                  John Messinger



                  I was looking for a programatic solution for this, but am so in the AF SDK mindset now that I didn't even think about PI-SDK and IPICalculation. Yes, that's a possibility, especially using the Calculate method, and then specifically trap for the E_INVALIDARG, PISDK_E_INVPEEXPR and PISDK_E_PERUNTIMEERROR errors to determine if there is a syntax issue in the passed expression.


                  For a one-off testing solution this use of the PI-SDK would be reasonable


                  Good call Tim.

                • Re: Programmatically test performance equation syntax

                  Hello James


                  I think that the IPICalculation examples would probably also work, but I tried this first, and it just...worked!

                  Thanks for your suggestion :-)