2 Replies Latest reply on Feb 13, 2018 3:50 PM by gregor

    Problem when accessing ConfigString of attributes

    jhoekx

      We have an AF structure defined in the 'PI system Explorer'. We access this data using the AF-SDK.

      One of the elements we are interested in is 'AFElement.Attributes[0].DataReference.ConfigString'.

      It should contain the information of a PI Point linked to an attribute.

       

      However, we see that not the correct information is returned in this scenario:

      • Start situation:
        PI System Explorer - Before.png
        PI System Management Tools - Before.png
      • Using 'PI System Management Tools', we rename the PI Point
        PI System Explorer - Rename.png
      • After restarting 'PI System Explorer', this change becomes visible (even on a different machine)
        Screen Shot 2018-02-13 at 15.10.07.png
      • When debugging, we see that the rename is not effected, but we want to see same result as 'PI System Explorer' shows:
        Visual Studio - Rename.png

      A workaround is to redo a check-in in 'PI System Explorer'. However, this is not always possible, since we are also working with old data.

      Is there a different way to get the correct renamed ConfigString?

        • Re: Problem when accessing ConfigString of attributes
          rschmitz

          Hi Jeroen,

           

          This is expected behavior after changing a PI point's name. The backend of AF builds config string to improve performance when resolving PI point attributes used on elements. When these PI point are renamed, the config string is broken and needs to be updated. You can visually see a difference in PSE with a small white tag and an exclamation point next to it, which when hovered over it will give you the standard config string error message.

           

           

          You can right click and create/update PI point reference as needed when renaming points (rather than having to re-checkin). There are other ways to call a bulk checkin for the database if you're expecting this to happen often such as the "-Repair" switch on the AF Update Plug-in Utility (I would stress caution with this utility because calling it frequently for large databases is costly and could hurt performance).

           

          Can I ask what your use case is for renaming tags? Is this more of a debugging/testing for a custom application or are you expecting tags to be frequently renamed and you code will need to handle this case often?

           

          Cheers,

          Rob

          3 of 3 people found this helpful
          • Re: Problem when accessing ConfigString of attributes
            gregor

            Hello Jeroen,

             

            Even the ConfigString stores the path to the PI Point using its name, PI Points are indeed resolved by their Point ID. When debugging your code, you will recognize "?14" at the end of the ConfigString property. This is the Point ID of your PI Point  (please verify Point ID property in PI SMT -> Point Builder -> tab System)

             

            PI System Explorer displays the correct path after you renamed the PI Point because it recognizes the name change but the ConfigString as it is stored in PIFD database remains unchanged.

             

            There is a command line tool installed with the PI AF Client setup which you can use to fix these kind of issues using a command as follows:

             

            "%pihome64%"\AF\afupdatepluginconfigurations "-root:\\<myafserver>\<myafdatabase>" -Repair
            

             

            Probably the best option is to avoid PI Point name changes. In your example, you rename a PI Point created by AF and I assume you've chosen this as an example. Can you elaborate on your real use case?

            1 of 1 people found this helpful