1 of 1 people found this helpful
I think Joseph already reached out to your directly to discuss this, however I wanted to post a few comments in case anyone else has the same questions.
Load balancing in scan classes is definitely something you should consider when collecting data for MANY points. This is typically accomplished by separating your points into different scan classes (they can still have the same scan frequency but different offsets to stagger them). I've seen many recommendations specific to OPC, most indicating no more than 800 points per scan class and no more than 10,000 points per interface instance (references: PI Interface for OPC DA documentation, KB00333 - Optimize load on the OPC server OR How to address the error "The OPC server did not respond to the last Refres… and more). For other types of data where we don't have explicit recommendations, you can still use metrics like the percentage of scans skipped to help determine if you're facing performance issues (more info here - KB00441 - Understanding Scan Class Performance for PI Interfaces)
Whenever possible, you should try to use substitution parameters instead of assigning PI Point data references to AF attributes one-by-one. However you're right that most OPC sources are probably not organized perfectly to reflect your AF structure. Thus, many times I see people using a combination of hard coding, attribute values, and substitution parameters. If no reusable patterns are possible, then PI Builder will definitely be your best friend.