5 Replies Latest reply on Jan 15, 2014 8:57 AM by RJKSolutions

    Issues with compression

    ainwood

      We have a flow meter tag, that is ranged 0 to 10 sm³/s.  Currently, the PI data stored has a resolution of on ±0.1 sm³/s (i.e. it tells me that the current flow is 1.6 sm³/s, and I won't get an update until it hits 1.5 sm³/s).  I wanted to increase the resolution on it.

       

      So:  I modified the tag attributes.  CompDevPercent was set to 0.01, but the span was set to 100 ("zero" is 0 by the way). So I changed the span to 10.  This changed the compdev to 0.001.  Excdev is at 0.005.

       

      However, this hasn't improved things.  I still don't get any better data resolution than ±0.1 sm³/s. 

       

      Any suggestions?  I was wondering whether the DCS (a Bailey) is filtering the data before it gets to the PI Buffer server.

        • Re: Issues with compression
          mhalhead

          Hi Andrew,

           

          This sound like it could be the source. Personally I would turn compression off including setting excdev to 0 for a few days to test. If you can't turn the compression of you can use the API snap utility on the interface to see what is being reported to the snapshot database, but this only gives you a single value.  I don't know what interface you are using but I'm going to guess OPC (it is by far the most common). If you are using OPC check that you don't have a deadband configured; location 5. Deadband only work on advised tags; Location3 = 1.

            • Re: Issues with compression

              Hello Andrew,

               

              What about the exception settings? If exception filters out events, there will be nothing left over for compression. As usual in such cases, I suggest working with OSIsoft Technical Support to see what's going on. I further suggest, trying to figure out what's received from the data source for the particular PI tag. Debugging capabilities depend on the data source but e.g. PI OPC Interface allows to debug for a single tag what's received from the data source. UNIINT tag level debugging allows to see what the interface sends after applying exception. After reviewing the tag configuration, using tag level debugging capabilities would be my first choice.

               

              Please let us know if you would like to be contacted by a Technical Support Engineer.

              • Re: Issues with compression
                ainwood

                @Michael: Thanks - Location 5 = 1, Location3=7, so I presume we don't have a deadband.  Turning off compression means setting "Compressing" to 0?

                 

                 

                 

                @Gregor:Exception values are:

                excdev excdevpercent excmax excmin
                0.005 0.05 100

                0

                Thanks for the offer re Technical Support:  Hold off at the moment.  I am just trying to set a tag or two and learn something in the process.  I will talk to our on-site PI experts as well.

                 

                 

                 

                Finally - is there a manual somewhere for PI-SMT?

                  • Re: Issues with compression
                    mhalhead

                    Hi Andrew,

                     

                    Gregor is correct you will get a faster resolution from techsupport.

                     

                    Regarding the manuals. All the manuals can be downloaded from the techsupport site.

                     

                    You can turn compression off by setting the compressing bit to 0 (or setting compression off in SMT on the Archive tab of Point Builder). You can also turn compression off effectively by setting the compression setting to 0 (duplicate values will be compressed). You will have to set excdev or excdevpercentage to 0 as this isn't controlled by the compression setting.

                     

                    Are you using the OPC interface? This is important as the location settings are interface specific.

                     

                    If you are using OPC then Location3 doesn't make sense as the value can only be between 0 and 4; a value of 1 is the most common. Below is an extract from the manual

                     

                    [Quote user="OPCInt Manual"]

                     

                    Location3

                     

                    This field is used to indicate whether this tag is to be a Polled, Advise, Event, or Output tag.  

                     

                    0 – Polled or Event

                     

                    1 – Advise

                     

                    2 – Output

                     

                    3 – Polled Watchdog used with Failover

                     

                    4 – Advise Watchdog used with Failover

                     

                    For an Advise tag, the OPC Interface will sign up for updates with the OPC Server, and the OPC server will send each new value to the interface, at a rate no more frequent than the update rate for the group.  To minimize “noise”, Location5 can be used to indicate the desired “deadband” if the server supports it.  With a deadband set, if the change between the last value read and the new value is less than the deadband, the new value is not sent to the interface by the OPC server.  This deadband processing is only valid for points which are defined in the OPC Server as Analog.  Deadband processing is optional for servers under the OPC standard; be sure that the server supports deadband processing before attempting to configure tags for advise based upon the assumption that deadband processing is supported.  Note that deadband processing affects which values the interface receives.  Which values the interface sends to PI is still configured using the exception parameters for the PI tag.

                     

                    For systems using failover, Location3 may have a value of 3 or 4 for watchdog tags.  For more information, see the OPC DA Interface Failover Manual and the OPC Specific Failover section.