3 Replies Latest reply on Dec 8, 2009 8:09 PM by cescamilla

    Writing values to a point using PI-SDK when that point is buffered by an external interface?


      Good morning,


      Recently I've encountered a scenario where it's become desirable to write a value to a PI tag (in a collective) while that point is buffered by a realtime interface. In this scenario, I had a recently created point with a value of PtCreated -no snapshot or archive values present. When attempting to write a value using the OSISoft SMT, Error -11414 buffered point does not accept new events... was raised. This is as expected. I hit upon the idea of using the PI-SDK as a work-around, using the PI-SDK UpdateValue()  function...


      Attempting to write to the same tag a recent value via the UpdateValue() method was successful. I need to clarify the mechanism by which the write occurs. The SDK CHM states "Send a single value (snapshot or archive) to PI" as the method descriptor. In the case above, I would have expected the value to go to the snapshot (???) but instead it appears it was sent directly to the archive. I'm confused by the behaviour. I expected the UpdateValue() call to fail with -11414 error.


      My deployment configuration is a PI collective with 5 servers. I can scale up my code to write values to all collective members individually since the SDK doesn't support buffered writes. But I only want to take this approach if I can be sure there are no cases where the UpdateValue() call would fail.


      Setting aside the (valid) concerns associated with writing recent values to a buffered point, would the above approach of using UpdateValue() on each collective member work? Are there failure scenarios I have overlooked?



        • Re: Writing values to a point using PI-SDK when that point is buffered by an external interface?

          I'm back with more information.


          There is one rule for tags:


          Only one data source can feed one tag.
          Or... there is a one-to-one relation between the Point Source and the PI Point.
          Which effectively means that updating a PI Point from two sources (one of them being the interface and the other one being your application) is not supported and may lead to undesired behaviour.


          Besides that, the only way for you to write values (with either method) is to use a timestamp that is behind the snapshot stimestamp. The reason for this is because the PI Buffer Subsystem has a 'contract' with the source of that PI Point which is used to keep the compresion, we can't guarantee compression of the input of that PI Point if the snapshot value is changed, but any change to (or addition to) a stream with a timestamp older than the snapshot will not affect compression and is, therefore, allowed.


          So, in order to make sure it won't fail you should not try to write values which timestamp is newer than the snapshot for PI Points that are being lock by the PI Buffer.


          Yes it will work if you keep these recommendations in mind. There are the common failure scenearios you have to take into consideration (network disconnection, server shutdown, power failure, etc.) and the fact that there is no buffering for the PI SDK just yet, so you'll have to handle that kind of situation.

          Or pray for your application to work while you wait for the PI SDK Buffer to be released (which is planned for the 1st quarter of 2010). [8-|

            • Re: Writing values to a point using PI-SDK when that point is buffered by an external interface?



              Thanks for the clarification. this is largely as I expected, though from additional testing I'm of the belief at this point that UpdateValue() is bypassing the snapshot in all cases and writing straight through to history?


              The "only one data source can feed one tag" guidance is interesting as well. This is as I understood it wrt buffered points. That being said, cases arise from time to time whereby it becomes necessary to backfill data (using UFL for instance) to a set of tags whilst those tags are being fed by a real time interface (such as OPC DA). I'd be interested to hear OSI's guidance for how best to manage this. Ie, there's a data disruption, a data gap develops. Eventually the cause of the disruption clears and real time data flow resumes but there's still this gap. we want to fill the gap while the interface is online. Seems like a pretty common scenario?