8 Replies Latest reply on Dec 15, 2014 9:28 AM by Rhys Kirk

    How many of you know that...

    Rhys Kirk

      I'm frustrated with something so I'm venting on vCampus  PI DevClub.

       

      The subject is PI Interfaces and the Point Update mechanism - I already have open communications with OSIsoft directly but I'm interested to know how widely within the community this feature is known. (More widely known by the time you finish reading this. )

       

      When an interface connects to a destination PI Server it will signup for PI Point Updates so that it knows about changes that it should process to add/remove/change PI Points from the interface. However, interfaces don't receive their relevant PI Points (i.e. from the interface's pointsource(s)), they will receive changes from any PI Point on the destination PI Server. So you can imagine if you have a PI Interface sending data for 100 PI Points on a PI Server that contains 1,000,000 PI Points, if you change 100,000 PI Points (e.g. data security change, compression standard changes) then that interface will receive all 100,000 changes. Now imagine you have 100 PI Interfaces connected, all 100 PI Interfaces will each receive the 100,000 PI Point changes. Next, imagine your interfaces are single threaded like PI to PI so data replication & point change checking interfere with each other, your interfaces are now disrupted by irrelevant point changes...the larger your PI Server the more potential impact to your interfaces...

       

       

        • Re: How many of you know that...
          lgarrigues

          So is that an interface issue or a limitation in the way the PI server delivers unfiltered point updates?

            • Re: How many of you know that...
              Karl.Hodgkiss

              Hi Rhys, I can at least confirm that you're not alone and have seen this behaviour where all interfaces grind through every point that has been updated. It was confusing at first as the points had nothing to do with the particular interface, but once the issue/feature was known all mass updates were planned a bit better so as to not affect normal support... this extra processing can take hours and lock out any legit interface changes.

              • Re: How many of you know that...
                rzandvliet

                This is a lot of extra communication, but updates should be send to every interface. Changes of point source, interface Id and some other changes can result in removing it from one interface and adding it too another interface.

                 

                This can properly optimized by sending updates, that can result in adding/removing, to every interface. All other updates, like exception and compression settings, only needs to be send to the interface where the point is added.

                  • Re: How many of you know that...
                    Rhys Kirk

                    The PI Server, Data Archive, already has functionality to support pointsource only point updates for a while. A point change shouldn't be sent to every interface, it should only be sent if it is relevant. Removing from the interface's pointsources, or adding to an interfaces pointsources is the key to determine which interface should be receiving the point update. The following TS enhancement shows this was added to the PI Server: https://techsupport.osisoft.com/Troubleshooting/Enhancements/19307OSI8

                     

                    However, even the latest of interfaces do not support this approach. 

                     

                    Karl, planning your changes is a very careful consideration now as the scale of your PI Server increases with lots of connected interfaces, especially if those interfaces are the other side of a poor latency connection.

                     

                    It begs the question of how PI Connectors handle this very topic. Yes they scan the source and create the PI Points, but how do they handle point updates?

                    • Re: How many of you know that...
                      Karl.Hodgkiss

                      Hi Robert, it's best to unregister a tag from one interface before registering it with another though, else you can end up in a right mess with tags stuck in the buffer. Rhys, by plan I simply meant get ready for a long delay where you can't do anything else on the interfaces except watch the log files slowly fill up.

                        • Re: How many of you know that...

                          Dear all,

                           

                          The Interface Team at OSIsoft is aware of this discussion. Please stay tuned for a reply.

                            • Re: How many of you know that...
                              ccoen

                              Hi everyone,

                               

                              Rhys refers to 19307osi8 where a new call was added at the PI Data Archive level to support point updates for a single point source.  That was implemented a while back in PI Data Archive version 3.4.370.52.  Well, unfortunately, that was later deprecated and is documented in 19484osi8.  That means that call is not available for clients like PI Interfaces to take advantage of.

                               

                              We discussed this among the PI Interface team anyway.  We have used the signup for all point updates because interfaces can use other tags as trigger tags among other things.  We need to monitor those too and are not specified by point source.  The team did suggest that if you make a massive change to your point database that causes your interface an issue, you can restart that interface to avoid processing the changes and simply re-fetch the points.  If you have a failover pair, you can avoid data loss.  Not sure if this workaround makes sense for everyone but might help in rare situations when you edit so many tags at once.

                               

                              At OSIsoft, we feel that the better investment for our customers will be to build PI Connectors.  These don't look to the PI Data Archive for changes at all and offer many other advantages (easy configuration, automatic tag and AF element creation, and better performance).  We building these now and expect to pick up more steam in 2015.  If you want to learn more, see one of our UC presentations from San Francisco or Lisbon.

                                • Re: How many of you know that...
                                  Rhys Kirk

                                  Chris, what PI Points exist in the PI Server that are not grouped by a point source? If you mean that interfaces such as the OPC DA writes where you specify the source tag then that tag still belongs to a point source.

                                  If you have a PI Server connector that provides the functionality of PI to PI then that would be a viable option, but it is still in development, right? That means the issue remains, and the issue can manifest itself with as little as 20 point changes, it doesn't need to be large volume changes - we've hit those specific conditions that cause this.