We have problem once the value of any tags remain fixed for long time , the tags will have bad value .
How to solve this issue ?
I would suggest you to check the source of the point i.e. from where it is receiving data from. Request you to check last update value in the source and compare with current value in the tag.
thank for reply
the source of all tags are SCADA system .Most of values are updated every two seconds but we have few values updated after one month, means value fixed for one month and cause problem, it changes to bad value. How to avoid bad value for these tags which not change for long time?
I would suggest you to take look at KB : KB01298 - Troubleshooting bad quality data to understand bad quality written to PI tag.
thank for your help
What I did I set the Min / maxtime for exception and compression . it seems make affect , I can see the last value from scada system even it is old .
do you have idea about the change ?
To give a background, Data comes into the snapshot, The snapshot holds the most recent value for every tag on the PI server.
The exmax (10 min in your case) attribute specifies an amount of time to wait before sending a value across even if it does not vary by more than the exdev amount("zero in your case"). Compmax attribute is set to 2 hours. This means that after waiting 2 hours with no values breaking the compression setting, the current snapshot value will be archive.
3226OSI8 - What are recommended Exception and Compression settings
OSIsoft: Exception and Compression Full Details - YouTube
OSIsoft: Exception and Compression Quick Summary - YouTube
Please check your interface and tag locations. Please check this link (PI Server) for locations significance and what should be the value of all the locations.
I beleive the tag locations are correct , issue related for those tags which not change for longtime . for example
the source of tag is 500 and not updated for one month so tag will goes to bad value .
Something other than the original data source (interface pulling from SCADA) may be writing to these tags. For instance, here's an example of where Asset Analytics were used to write a bad value to a stale tag:Is it possible to use the Extended Description field to change a PI tag value to Stale rather than hold the stale value?
If you have Data Archive 2017 R2+, there is a tuning parameter called Snapshot_TracePointID. You can set the value of this parameter (gets picked up once a minute) to the point ID of one of the problem tags. This will print a message log if an event is written to the tag that is coming from a source different than the most recently written event. Note, this will only be helpful if the parameter is set prior to the bad value being written, so you'd have to be able to predict which tag will receive a bad value.
You could also check out your active Analyses on your AF system to see if there are any analyses referencing the problem tags, and then evaluate the analysis logic from there to see if it is relevant. One way to do this could be to export the database to an XML (PSE > File > Export to file... > Include All Referenced Objects), search for one of the tag names, and then search for the attribute name corresponding to the tag within an AFAnalysisRule.
Not necessarily a definitive answer, but could be a good place to do some investigation.
Retrieving data ...