• State Not Answered
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 121 views
  • Users 0 members are here
Options
Related

How to buffer data written to PI AF Attributes to both members of PI DA collective?

gmalek

We are building a custom application that writes data to PI AF Attributes (with PI Point Data Reference) using the PI AF SDK. The attributes point to PI Points on the primary archive in a collective, but we would like to write the data to both members of the collective. Is there a way to do this by writing to PI AF attributes, or would we need to write directly to the PI Points on the respective archives instead?

Parents
  • 0

    Unless you are using custom data references, AFAttributes are based on the PI Point Data Reference, which means you get the same behavior writing to either. There is a minor difference if the AFAttribute is defined with a SourceUOM and the write command uses a different but compatible UOM. AF will perform a UOM conversion automatically, and then write the data to the PI Data Archive.

     

    ONe, what you will need to do is to enable a Data Archive Tuning Parameter called Replication_EnableSDKWriteValues.

     

    Two, you would need to have the PI buffering correctly configured on any/every Windows host running the AF SDK application.

     

    Three, the AF SDK app should be sure to specify to use buffering, or rather, NOT to bypass buffering.

     

     The decision on AFAttributes versus PIPoints has nothing to do with the above. You should use which one is most appropriate for the nature of your application. If your app is Asset-based using an AFDatabase and AFElements, then obviously you should use AFAttributes - and by doing so they in turn will be using the PIPoint.

     

Reply
  • 0

    Unless you are using custom data references, AFAttributes are based on the PI Point Data Reference, which means you get the same behavior writing to either. There is a minor difference if the AFAttribute is defined with a SourceUOM and the write command uses a different but compatible UOM. AF will perform a UOM conversion automatically, and then write the data to the PI Data Archive.

     

    ONe, what you will need to do is to enable a Data Archive Tuning Parameter called Replication_EnableSDKWriteValues.

     

    Two, you would need to have the PI buffering correctly configured on any/every Windows host running the AF SDK application.

     

    Three, the AF SDK app should be sure to specify to use buffering, or rather, NOT to bypass buffering.

     

     The decision on AFAttributes versus PIPoints has nothing to do with the above. You should use which one is most appropriate for the nature of your application. If your app is Asset-based using an AFDatabase and AFElements, then obviously you should use AFAttributes - and by doing so they in turn will be using the PIPoint.

     

Children
  • 0 in reply to Rick_Davin_3.0

    Hi Rick,

     

    Thank you for your response. The tuning parameters are already set = 1, which I assume is the correct value.

     

    Also, we specify AFData.BufferOption = AFBufferOption.Buffer globally in our program, and as the bufferOption parameter in our AFAttribute.Data.UpdateValues calls.

     

    As this runs on my machine currently, we don't have PI Buffer Subsystem running, but I've been told that shouldn't be an issue.

     

    Under these circumstances, would you normally expect the data to pass to both collective members' tags when writing to PI Point attributes?

     

    If so, we have an issue where a PI SDK alias mapping the secondary archive to primary keeps resurfacing, even after manual deletion. Do you think this could explain why data is only passing to the primary's tags?