Sometimes you just want the points on one PI server to match those on another, if not exactly then with just a few attributes overridden with alternate values. PI-APS does something like this but needs an Add-In that comes with caveats, e.g. if you use the PI-to-PI Add-In, APS will only create points that follow PI-to-PI configuration. Also, PI-APS scales to a maximum of about 10,000 points. AFSDK can easily scale better. So here's an example AFSDK application that does something alot like PI-APS for PI-to-PI. (Note - it still uses PI-SDK to work with digital sets, but minimally.) Visual Studio Project attached.
Here's how it works. It is a console application that reads configuration from the Windows Registry. It reads all the applicable points on the source and compares them, including attributes, to the target. System attributes are ignored and for digitals, zero, span, and typical value are ignored. Any attributes can be over-ridden with a default value. It assumes only classic points, so other point types may crash it as is.
It loads up all digital set and state information on source and target servers only once when digitals first come into play. If digital sets have the same name but different sets on source and target points using that set get banned from sync. Otherwise digital sets are created and/or used as required to sync points. PISDK connections exist only when digital sets are first read or when new ones are being created. Apart from this only AFSDK is used.
I haven't tested but I'm sure it can do far more than 10,000 points.
Here's an example registry:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\PISystem\PISync] "sourcePIServer"="PISVR01" "targetPIServer"="PISVR02" "workingTagListPath"="C:\\PISyncTagList.txt" "logFilePath"="C:\\PISyncLog.txt" "tagMasks"=hex(7):73,00,69,00,6e,00,2a,00,00,00,63,00,64,00,74,00,2a,00,00,00,\ 74,00,65,00,73,00,74,00,2a,00,00,00,63,00,64,00,6d,00,2a,00,00,00,00,00 "attributeOverrides"=hex(7):70,00,6f,00,69,00,6e,00,74,00,73,00,6f,00,75,00,72,\ 00,63,00,65,00,3d,00,70,00,69,00,73,00,79,00,6e,00,63,00,00,00,6c,00,6f,00,\ 63,00,61,00,74,00,69,00,6f,00,6e,00,31,00,3d,00,30,00,00,00,6c,00,6f,00,63,\ 00,61,00,74,00,69,00,6f,00,6e,00,32,00,3d,00,30,00,00,00,6c,00,6f,00,63,00,\ 61,00,74,00,69,00,6f,00,6e,00,33,00,3d,00,30,00,00,00,6c,00,6f,00,63,00,61,\ 00,74,00,69,00,6f,00,6e,00,34,00,3d,00,31,00,00,00,6c,00,6f,00,63,00,61,00,\ 74,00,69,00,6f,00,6e,00,35,00,3d,00,30,00,00,00,65,00,78,00,64,00,65,00,73,\ 00,63,00,3d,00,00,00,00,00 "noSecurityAttribs"="TRUE"
Source is were point configuration is read, and target is where it is copied to.
The working tag list is one way to get points to synchronize - just put the tag in this text file.
logfilepath is where the application logs messages.
tagmasks is another way to get points synchronized. Any point matching a tagmask here gets added to the working list.
attribute overrides are so target point configuration can be different. For example, pointsource=pisync would cause the pointsource attribute on target to be "pisync" for every sychronized point, regardless of what pointsource might be on the source.
noSecurityAttribs, if true, means none of the security-related attributes on the source will be synced with target. Use this if the security models are different between servers.
THE MAIN LOOP:
GetConfig(); // from Windows registry
ReadTagList(); // from text file (not really necessary if can be done by tag mask alone)
SyncPoints(); // loads points from source using text file and tagmask strings, gets or creates matching point on target
SyncAttributes(); // go point by point comparing attributes and updating if required
WriteTagList(); // write the tag list back to the text file
System.Threading.Thread.Sleep(1000000); // until the next pass at synchronization