To trace the issue, would like to know device status (Health Counter) to check it is an issue with OPC server or Interface. Device status “0” if it is collecting data, ”10” where connection is active but not collecting data and “95” comm failure
In general, it stops collecting data if there are missing scans and point edits (configure errors) greater than 20% of the total but looks like you haven’t done any changes on the interface.
Device status health point on the interface will provide information along with logs (set to debug). COM existing error is something to do with OPC server as per the log message shared.
I just want to clarify this statement:
"In general, it stops collecting data if there are missing scans and point edits (configure errors) greater than 20% of the total but looks like you haven’t done any changes on the interface"
That is incorrect. The interface will not stop collecting data if more than 20% of the tags are in a bad state. The /RP (Percentage of tags to be good, default 80%) only affects the value of the device status, it does not affect data collection.
I had an instance where OPC DA interface stopped collecting data after loading the interface with incorrect OPC instrument ID's. 50% tags showed "Configure" value and we have not seen any data in the tags during that time. Removed the tags with Configure error from interface and could notice data collection on the interface.
Thank you for correction but not sure why configure error caused interface to stop data collection.
If you were using /MA (Mass Tag Adding), which makes the interface add multiple tags to a group at once, some OPC servers reject the entire group if one tag is invalid. That may have been what you ran into. That being said, we would need to have a lot more information to know exactly what happened.
The PI OPC DA interface tells the OPC server which values it is interested in before the interface is allowed to request data for them. The interface does so by creating "groups" on the server and then adding items to the groups. The groups correspond roughly to PI scan classes and the items correspond to PI tags. The /ma parameter configures how the interface adds items to each group:
- In groups of up to 500 items at a time - Mass Tag Adding enabled (/ma=y), requiring one round-trip to the server for each group
- One at a time - Mass Tag Adding disabled (/ma=n), requiring one round-trip to the server for each item.
If you have configured thousands of PI tags and notice that the interface takes a long time to start, try enabling Mass Tag Adding to reduce the time required to load points.
Some OPC servers reject all the items in a group if even a single one of them is invalid. For those servers, set /ma=n to make sure the valid items are not rejected.
So I request you do this change in advanced options settings and check. Please refer the below link for more details,
You would need to review the logs on the OPC Server as it looks like the issue is occuring on the OPC Server side and it is dropping all the tags from the groups.
The "Interface rejected all PI points" message simply indicates that none of the PI Points configured for the interface were accepted on the OPC Server side. Unfortunately, from the interface side (and logging), the loggin is sparse since we do not know why the points were rejected. Reviewing the OPC Server logs should clarify what the underlying issue is.