What's the best way to reset many attributes to template?

We have elements from template whose names are strings, but essentially numeric ("00", "01",...,"52", etc.). The elements have a table lookup attribute template that performs a table lookup using the element name as the key, and returns a PI tag name. This PI tag name is then used as a substitution parameter in the configuration strings of several other attribute templates.

 

When we change PI tag names in the AF Table, we have to reset to template these attributes that use the PI tag name lookup in their config strings, and then use the "Create or Update PI Point" option when right-clicking the attributes in PI System Explorer. Doing this manually in PSE can be time-consuming, so I've made a script that appears to do the same thing programmatically. It performs two steps - first resetting the attribute to template, and secondly updating the data reference with the new configuration string.

 

PISystem pisyst = new PISystems()[afservname];
AFDatabase afdb = pisyst.Databases[afdbname];

string querystr = @"Template:'mytemplatename'"
AFAttribute thisatt;

using (var elemsearch = new AFElementSearch(afdb, "PI AF SDK Attribute Search", querystr)) {
	foreach(AFElement afelem in elemsearch.FindObjects(fullLoad: true))
        {
	        foreach (AFAttribute afatt in afelem.Attributes)
                {
			try
			{
			        afatt.ResetToTemplate();
			        afatt.DataReference.CreateConfig();
			}
			catch (System.ApplicationException e)
			{
                         }
		}
	}
	afdb.CheckIn();
	return;
}

 

I recently discovered the AFAttribute.SetConfigString method, which can be used to reset attributes to template more efficiently than calling AFAttribute.ResetToTemplate on each attribute separately.

 

Does anyone know if using AFAttribute.SetConfigString to reset attributes to template also performs the functionality of AFDataReference.CreateConfig, or will I have to find another way to perform this step? If so, is there a more efficient way to do this than by retrieving each attribute's data reference separately and calling CreateConfig on it?

Parents
  • Unfortunately, my understanding is you have to call AFDataREference.CreateConfig on each attribute. You should only have to call CreateConfig where the data reference is of type PI Point.

  • You can perform a BIG BULK CreateConfig on the entire AFDatabase:

    AFDatabase.CreateConfig(AFDatabase, EventHandler)

     

    For a big database, this could take quite some time to process.

     

    If performing per attribute, then the safest bet is as [Mention:0051I000002ndjdQAA]​ suggests and that is to check the the DataReferencePlugIn the for PIPoints.

     

    Technically, it is possible for a custom data reference to persists other changes in a ConfigString and require a config update, but that is extremely rare (I have never seen it). Consider why it is needed for PIPoint: the first time the attribute tries to connect to its PIPoint via a ConfigString - that is by using a PI Server name and Tagname - the PIPoint DR then is bound to that PIPoint. What that means is the ConfigString has some hidden parameters, most notably the PI Server Guid and the tag's PIPoint ID. The next time you attempt to read the attribute, the Server Guid and PIPoint ID are used instead of the names. This is true even if you change the names! Unless of course, you run CreateConfig() again.

     

Reply
  • You can perform a BIG BULK CreateConfig on the entire AFDatabase:

    AFDatabase.CreateConfig(AFDatabase, EventHandler)

     

    For a big database, this could take quite some time to process.

     

    If performing per attribute, then the safest bet is as [Mention:0051I000002ndjdQAA]​ suggests and that is to check the the DataReferencePlugIn the for PIPoints.

     

    Technically, it is possible for a custom data reference to persists other changes in a ConfigString and require a config update, but that is extremely rare (I have never seen it). Consider why it is needed for PIPoint: the first time the attribute tries to connect to its PIPoint via a ConfigString - that is by using a PI Server name and Tagname - the PIPoint DR then is bound to that PIPoint. What that means is the ConfigString has some hidden parameters, most notably the PI Server Guid and the tag's PIPoint ID. The next time you attempt to read the attribute, the Server Guid and PIPoint ID are used instead of the names. This is true even if you change the names! Unless of course, you run CreateConfig() again.

     

Children
No Data