The Quality of tag in Pi OPC client is showing Bad 0011000. Kindly help to rectify.
The quality of Bad-00010100 comes from the OPC Server side. The OPC Client is just used as a tool to view the tags. We therefore cannot edit the quality that is seen through the OPC Client tool. The quality of the tags should be something discussed with your OPC Server provider. Let us know if you have any further questions.
Quality is usually 16 bits in length; higher order 8 bytes are vendor specific and OPC standards dictate the following regarding the lower 8 bits (QQSSSSLL):
a) 00SSSSLL - Bad Value is not useful.
b) 01SSSSLL - Uncertain.
c) 10SSSSLL - N/A - Not used by OPC
d) 11SSSSLL - Good - The Quality of the value is Good.
The OPC Client is indeed getting a bad quality status from the OPC server. Check on the data source side to see what's going on.
There have been some cases in our projects, where data quality when we connect remotely via OPC client is "bad" for a tag, but when we connect locally on the OPC server, the quality is reported as "Good" for the same tag.
We have always argued that this maybe due to something wrong on the data source end.
But is there a way in PI OPC interface to completely ignore quality information and store the value "as-is".
Also - I have a larger question related to data cleansing -
What would the best way to remove all instances of "bad" data from Raw Tags without consuming additional tags - for eg. as of now, we maintain seperate Raw Tag and cleansed tag, and the logic for cleansing (removal of bad values, flatlines etc) resides in a PI ACE calculation - Is this the best way to do it? or are there better ways to do it? -
Can we leverage PI AF Custom DRs for this? - we would like to provide error free data to upstream applications like portal, ETL processes etc, so what are the best practices that OSISoft recommends for Data Cleansing?
The OPC standard states that the client cannot assume that there is anything in the data field if the quality for the data is bad. As a result, there is no way to send the value for bad quality data to the PI Server only the status.
From the OPC DA Interface manual:
Because the PI archive stores either the quality or the value, the interface will translate the qualities in the “questionable” category to GOODSTAT, and set the “questionable value” flag for the data value. “Bad quality” flags get the corresponding PI status stored for the tag. If the quality is SUBSTITUTED_ST, the interface will currently store the status rather than the value sent. This behavior can be changed with the /SQ parameter in the startup file. Setting /SQ=Y parameter will cause the interface to store the quality (translated to a PI digital state) if the quality is anything but GOOD. Similarly, if /SQ=I is set, the interface will ignore the "questionable" quality, and treat the value as if it had good quality.
no /SQ parameter
The behavior can be enhanced to send only GOOD quality data by setting the /SG parameter. If the /SG is set, only GOOD quality data will be sent to PI. Questionable quality data and BAD quality data will be ignored.
If the /SQ=I or /SQ=Y flag is also set, then Questionable Quality data will be sent to PI as described above. BAD quality data will continue to be ignored.
The quality information will continue to be sent to tags that are configured to store quality instead of values.
I would discourage storing the bad values into the PI Server, even if it was possible.
There's a reason why the PI OPC Interface doesn't allow storing the bad value, as is. Bad data simply cannot be trusted, why would you trust data if the OPC Server sends the data as "Bad"?
I suggest doing some testing to determine if it's really the case that the value shows "good" on the OPC Server and "bad" on the PI OPC Client tool; double check the exact events. Also if the OPC Server manufacturer has an OPC Client tool, please check with that tool to see if the value is also showing a status of "bad". Maybe you could talk to your OPC Server vendor to determine why it is sending a "bad value", and from there determine the root cause.
Personally, I would rather have "no data" then to store "bad data". Sometimes having no data is better than having bad data, right? For example if someone was doing some reporting with your data: if there is no data, then they can't make a report for that time range; however, if there is bad data recorded it may be assumed to be good data and a report on this data could confuse decision making.
We tried talking to vendor on this couple of times, but the response always was - everything is fine in our end. What was strange was that - Same tag was showing good values when connected locally on OPC server but showing bad values when connected remotely.
We are likely to loose about 20% of events if we choose to store only good data in some cases. I guess we should be doing a pilot for this then decide.
But like you said, we have some reporting based the this data, and hence want it to be error free as much as possible.
Thank you very much for your suggestions
I'm sorry to hear that the OPC Server vendor were not very active at helping you determine the root cause. They may be right in that there is nothing wrong with their OPC Server... it could be due to the network since you've mentioned packet loss.
Here's a quick test: Can you run the PI OPC Client tool natively on the OPC Server? And at the same time run the PI OPC Client tool on your PI OPC Interface node? Check if they are showing similar "Bad" Quality for your data.
I don't think you'll need it: but if the data is coming in too fast, to physically see and compare, there's is a feature on the PI OPC Client tool to capture history so you can scroll back and look at the exact same data point while it was on the OPC Server and after it has made its way to the PI OPC Interface node.
Hopefully you can determine the culprit of the "Bad" Quality soon.
Let us know how it goes,
In some cases, a bad quality data means your source of data had too many information to send to you. I had a problem with my CLP/OPC communication, because I was sending much more data than was possible to my OPC to scan.
1 - Verify how many tags you have in each location 4 attribute, and share it
2 - Create a dedicated channel between your source data and your OPC
3 - Put all your OPC variables in a sequential address, it'll optimize your OPC scan
Thank you for the suggestions.
1) We generally restrict the no of tags in 1 scan class to less than 800. Will it help if we reduce it further?
2) Creating dedicated channel between OPC and Source is something that needs to be done on OPC Server level .. right?
3) I did not fully understand what you meant by "Put all your OPC variables in a sequential address, it'll optimize your OPC scan" . Is it something that we have to do on the PI Interface end or PI Tag Configuration end?
Thanks once again.
Ok, let's go.
1) Here in CSN, our scan class had a maximum of 800 tag's too.
2) It'll depend of your type of communication. We use a CLP with communication in a Modbus TCP/IP protocol, so we use a dedicated card with a tcp/ip adress to do this communication.
3) In CLP case, all variables occupy an memory space, which has an adress. The Modbus protocol has a limited scan word of 256 bytes. When the CLP is reading a device, it is for each 256 bytes. So, if you have a fragmented memory, you use more words to read all of your tags from OPC. For example, if you have a variable in position 1 from the memory and another in the position 300, you will need 2 words to read it, but if you have the second variable in the position 200, you will use just 1 word. It looks like with defrag from windows.
I do not know if I could respond appropriately. You can ask me again if my answer wasn't clear.
Swati, have you saw this configuration at ICU?
Thanks for contributing to the PI Square Community!
In response to your suggestion. Taylor Soulis mentioned this option earlier in the thread.
However, if the Status is "BAD" then there are no options to store the value. A "Bad" status will be stored as a digital state, and any "value" received is not stored (because we cannot trust a value with BAD status).
Yes, my bad, I saw it now. It was "hidden", then I clicked on "show previous answers"
Hi Juão, no worries.
Retrieving data ...