The following calls that edit existing events do not support buffering:
Once PI Buffer Subsystem registers with a PI Server and starts sending snapshot values for a PI point, only PI Buffer Subsystem can write snapshot values (either new values or edits) for that point. In other words, PI Buffer Subsystem "owns" the point in the snapshot. Point ownership is used to maintain consistent compression.
When PI Buffer Subsystem is unable to accept a data value, PI SDK may attempt to write the value directly. In a case like this, if PI SDK attempts to write the data to the snapshot, PI Server rejects the write attempt because only PI Buffer Subsystem can write to the point.
For more information, see the message 0x80040725 Failed to update events on the server in Resolve specific PI SDK buffering issues. You may also see error messages that include this PI error code: [-11414] Buffered point does not accept new events.
To resolve this problem, you need to identify and fix any problems that are preventing PI Buffer Subsystem from receiving or sending data. This allows PI SDK and AF SDK to send data using PI Buffer Subsystem instead of sending it directly to the server.
The table below describes each combination of conditions and how it affects PI SDK buffering.
|Target of the call||Status of PI SDK buffering||Is the target configured to receive buffered data?||Behavior of PI SDK calls|
|Single server||Enabled||Yes|| Calls that support PI SDK buffering write to PI Buffer Subsystem, which delivers the data to the target server.
Calls that do not support PI SDK buffering write data directly to the target server. Data from these calls is not buffered.
|Single server||Enabled||No||All PI SDK calls write data directly to the target server. No data is buffered.|
|Single server||Disabled||No||All PI SDK calls write data directly to the target server. No PI SDK data is buffered.|
|Collective||Enabled||Yes|| Calls that support PI SDK buffering write to PI Buffer Subsystem, which delivers the data to members of the target collective.
Calls that do not support PI SDK buffering do not write any data to the target collective. In this scenario, each unsupported call returns an error.
|Collective||Enabled||No|| PI SDK does not write any data to the target collective or to PI Buffer Subsystem (this applies whether or not specific calls support buffering). In this scenario, each call returns an error.
The reason for this behavior is as follows. When buffering is disabled, PI SDK can write only to the primary server of an unbuffered collective. It cannot write to other collective members. When buffering is enabled, PI SDK does not allow writes to an unbuffered collective, because writing only to the primary server would desynchronize the collective’s archives. PI SDK can write data to an unbuffered collective only from a node where PI SDK buffering is disabled.
|All PI SDK calls write data directly to the target collective’s primary member only. No PI SDK data is buffered.|
The UpdateValue and UpdateValues methods supported by PI SDK buffering treat events with identical timestamps as identical events, even if values or annotations are different. This may result in modifying the wrong event with a new value and annotation. Annotation Editor uses these methods and is therefore subject to this limitation.
To modify the value or annotation of a specific event, OSIsoft recommends using ReplaceValue instead of UpdateValue. However, changes made with ReplaceValue are not buffered. In addition, when buffering is enabled, ReplaceValue can write data directly to single servers, but not collectives. See “Buffering and the Behavior of PI SDK Calls” for more information.