6 Replies Latest reply on Jun 17, 2014 6:33 PM by jking

    When exactly are PI Point references resolved?

    Roger Palmen

      I've been looking at this for some time. Did not 100% figure it out yet, so i thought to call our on your combined smartness to enlighten me on this topic!


      I use PI Point datareferences frequently, in combination with substitution parameters %@xxx% and %xxxx% and PI Point creation. The AF documentation states that when a PI Point DR is resolved, the PointID is stored in the Point attributes. However, just looking at PSE it's a but fuzzy to me when the PointID is determined and persisted on the attribute in the AFserver.


      Let's look at my example:

      • A simple Element, based on a template.
      • One PI Point attribute, with the following configstring: "\\mypiserver\%@.|TagName%;ptclassname=classic;pointtype=Float32;location2=2;location4=1;pointsource=R"
      • One child attribute (string) holding the PI Point name. Defaults to "CDT158". NOT a config item.
      Now let's start playing:
      • I create the element based on the template, and in an instant, the Element is created, the Pi Point reference shows a value, and shows a configstring resolved to the PI Point CDT158.
      • Change the tagname to SINUSOID. First nothing happens and stays at CDT158.. Press refresh on the attribute, or switch between elements or checkin: nothing happens and stays at CDT158.
      • Choose Revert to Template: point is resolved to SINUSOID.
      • Now it starts behaving differently: Whenever i change the tagname to CDT158 or SINUSOID, the change is instantly reflected in the Configstring. And after pressing refresh on the attribute, the value is shown of the PI Point in the configstring.
      • I set a new TagName, of a non-existing tag: behaves as previous bullet (except no value of course).
      • Now i press Create or Update Pi Point. Point gets created, but now Configstring is stripped from it's tag creation parts of the string.
      • If i now press Reset to template, the tag creation parts return on the string.
      • I now set a new TagName of a non-existing tag, and press Create or Update PI Point. Point gets created, configstring is stripped from tag creation parts.
      • I now change the tagname to an existing tag. Tag creation parts stay off, but new tag is resolved and shown.
      • Close and open PSE. Attribute still on previous value before change, creation part still absent. Now i can change the tagname, refresh, without that impacting the Pi Point: back to start situation.Only when i now press Reset to Template, the response to a tagname change is instant again.

      AF help says on %@xxx%: PI AF does not update the attribute value over time. It uses the value of the attribute at that exact time that you created or updated the data reference (Create or update data references). This value is a constant. PI AF does not evaluate that attribute value again, unless you update the data reference. 



      This 1) appears to me there are some minor inconsistencies in the handling of the configstring and 2) i'm unsure when a substitution value is resolved, when the PointID is written back to the AF server, what actions trigger a refresh of the substitution parameters & PointID. Documentation does not really explain in detail how this works.
      Anybody able to shine some light on this? 
      Using 32bit PSE2014 ( against a AFserver
      I did find this great post, that shows the (did not now!) hidden feature to shift-click to show the parsed / un-parsed configstring: http://vcampus.osisoft.com/discussion_hall/Development_with_OSIsoft_SDKs/f/28/p/4267/22670.aspx#22670
      too bad it does not show if the attribute is resolved, and what the PI PointID is if resolved.
        • Re: When exactly are PI Point references resolved?

          This subject can get really complicated really quickly but I will give it a shot:


          So first of all i want to clarify your steps.  Lemme tell you what i see and if you see something different then please tell me:


          1) Create an element template


          2) Create an attribute template for that element template with the configstring of \\servername\cdt158


          3) Create an element instance derived from the element template


          4) Notice that element instance is created with attribute already created and it is correctly pointing to cdt158 and getting correct value


          5) Change the configstring of attribute template to \\servername\sinusoid


          6) Notice that attribute instance changes to sinusoid without any refresh or check-in to match the change you made in step 5 to the attribute template


          These 6 steps don't seem to follow what you are seeing but these 6 steps are what i am seeing using AF  Please tell me if I have done any step incorrectly.  I am still not sure why there is a discrepancy here but I am assuming we are doing slightly different steps.


          Now I want to also try to explain what each of the 3 configstrings you see in PSE are:


          1) I call it the user-friendly configstring.  It is the configstring in the attribute properties pane in the text box under the Settings button.  This configstring will not show substitution parameter, server id, or point id.  It will actually show the resolved values of the substitution parameters.


          2) The ConfigString in the Shift+Settings dialog.  This is the configstring that does show substitution parameters, show server id, and point id.  It is a run-time created configstring.  Let's say if you have a renamed PI server tag.  This configstring will display the new name of the tag that is resolved from the point id stored in the configstring on the AF server.  This is not what is stored on the AF server.  This is only a runtime representation of the configstring in memory.


          3) This leads me to the ConfigStringStored which is the ConfigStringStored in the Shift+Settings dialog. It shows you what is actually stored on the AF server.  It will also show substitution parameters, server id and point id but this configstring will have the old tagname in my rename PI tag example.


          I hope all of this helps.



          1 of 1 people found this helpful
            • Re: When exactly are PI Point references resolved?
              Roger Palmen

              Hi Jason,


              I understand this gets complicated quickly! That's why i'm asking the experts. And it seems to make a good, barely-touched topic for vCampus.


              I can reproduce the steps you describe, so that is matching nicely, as expected. The key difference with my example, is that i use a sub-attribute that holds the tagname, and that is resolved in the configstring. This complicates stuff a bit more.


              But let's stick to the simple example you give, because you state on 3) that the ConfigStringStored shows the string as stored on the AF server. After step 6 i performed a checkin, and changed the attribute back to CDT158. I now expect that the ConfigString and the ConfigStringStored would be different, as i did not commit my change of the tag from SINUSOID to CDT158 yet.


              To have i look, i simultaneously (i started PSE after the changes above)  connected to the AFserver using different credentials and took a look at the attribute. And voila, it shows SINUSOID in both ConfigString and ConfigStringStored. Not really consistent? Or did i miss some point here?


              About PI Point IDs: is that stored in the ID or in the UniqueID property? Interesting stuff!

                • Re: When exactly are PI Point references resolved?
                  David Hearn

                  PSE will automatically save your changes to the AFServer (do an apply changes) if you move off the element or change tabs. So that could be the reason you are seeing the same value for both ConfigString and ConfigStringStored.


                  The PI PointID is stored in the attribute's ConfigString if it has been resolved while the element is checked out and is used when loading the PIPoint. A PIPoint also has Attributes associated with it (using the PIPoint.GetAttribute method) and one of these attributes is its PointID. Some of these attributes are automatically loaded like the PIPoint PointID, but others must be loaded using the PIPoint.LoadAttributes method.

                    • Re: When exactly are PI Point references resolved?

                      Hi Roger,


                      So if you take what I said literally it is not quite true.  Here is a simple example to show you that:


                      1) Create an attribute that points to a PI Point


                      2) Check it in


                      3) Change the configstring to point to another PI Point


                      4) Notice that before checking in, applying, or navigating to another element that the ConfigStringStored is already representing the new PI Point


                      My description of those 3 configstrings is to make it easier to understand but there not what is truly happening underneath the hood.  Both ConfigString and ConfigStringStored are actually both in the memory of the AF SDK.  For example in the PI Point rename example, a dynamic runtime change will be made such that the ConfigString no longer matches the ConfigStringStored.  It is in this case of a dynamic runtime change, the ConfigStringStored is a better representation of what is stored on the AF server than the ConfigString. However, only Apply or Checkin is when things are ACTUALLY written back to the AF server.  Apply will write it to the sandbox of the AF server and Check In will actually permanently write it to the AF server such that you no longer can Undo it.


                      PSE changes are not a dynamic runtime change so it follows different rules.  The ConfigString and ConfigStringStored will change once you make the change.  However, as I have said only Apply or CheckIn will write it back to the AF server.


                      I know this may be confusing but this is how it works.

                        • Re: When exactly are PI Point references resolved?
                          Roger Palmen

                          Ah, capiche! Of course i take things literally.. i'm an engineer :-)


                          Now going back to my original question on the substitution variables and PointID. I'm still looking for some ideas on when they are exactly resolved. How can i tell from PSE if a PI Point is resolved, based on the current values of the substitution parameters? Should a refresh do the trick, or must i run the Create or Update Data References? From PSE i cannot tell if what i'm looking at locally is the same as what is stored on the AF server. At least, that is the consequence of what you explained on ConfigStringStored.


                          The behaviour of the Point Creation attributes disappearing from the configstring still looks like a minor bug to me. I could live with that one though.


                          My case: I store the PI server to use in a Configuration element, and include that into the PI Point reference. When moving AFmodels from e.g. Acceptance to Production environments, i need to re-resolve the PI Point attributes to point to the correct server. How can i tell if that is done properly? I prefer not to go around to the PI server to update thousands of PI Points if no change is needed in the first place. I just want to resolve the substitution variables in the ConfigString of all PI Points.

                            • Re: When exactly are PI Point references resolved?

                              On a normal non templatized attribute, it is pretty easy to tell when a PI Point is resolved because it will have the point id in the ConfigString.  The syntax is \\<servername>?<server ID>\<tagname>?<tag ID>.  However, on a templatized attribute instance, it is more difficult because it does not show you the point ID in the configstring.


                              When everything is checked in, the ConfigStringStored is pretty much what is stored on the AF server.  It is only when things are checked out, that they will be different.


                              The stripping of the tag creation parts of the configstring when a Create or Update Data Reference command is issued is definitely not a bug.  It was designed that way on purpose.  You can think of it like this.  We have committed the changes you want to the PI server therefore those tag attributes are now stored on the PI server.  Therefore they are no longer needed in the ConfigString.


                              I am assuming you are trying to do something like this:


                              You have a PI Point DR attribute template with name of Attribute1 with configstring like this: \\%@Attribute2%\sinusoid


                              The Attribute template Attribute2 has the data type of string and has the name of the PI server.


                              You want to be able to change value of Attribute2 such that one change will change all attribute's PI server from one to another PI server.


                              This does work and the way you can tell is that the user friendly ConfigString should show the new PI server.


                              Is it not doing this for you?


                              BTW there is another way to do this.  With the method above, you obviously have to architecture it with attribute templates and such.  However, what do customers do if they did not do this?  We have a new utility called AFUpdatePlugInConfiguration.  It is a command line utility that was released in AF 2.6.  The utility needs to be passed the old server name and the new server name and it will do a string replace of all configstrings in a database or PI system.


                              I hope this helps,