What you are doing by modifying the instrument tags and reverting them back to the original ones is to make the interface to re-load these tags.
Same effect could be achieved by changing the attribute scan to off and then changing it back to on (or changing any other attribute).
When the tags stop updating? do you see any relevant messages in the interface logs regarding OPC server connection? In case you have identified one tag for which the issue repeats often we can increase the debugging level to include all the events received for that tag to better troubleshoot the issue.
1 of 1 people found this helpful
If the message log on the interface machine has revealed no clues, you can add the tag level debugging that Ana mentions (/DT=tagname):
Log Timestamps and Data for Tag
Log the same items as /DB=32, but only for the point specified as the debug point (/DT=tagname). If there is no tag specified, the first point for which a value is received is set to the debug point. (/DB=64)
If Ana Revert Tomas's suggestion has not proven helpful, consider a technical support call, suggest including the interface msglog (pigetmsg -st *-1d -et * >log.txt will give you the most recent 24hours) and interface diagnostics file (From ICU> Tools> Diagnostics or ( <CTRL> + D ). This might speed your resolution while protecting your proprietary information. Hopefully, the log would give some insight. Let us know if there are more details available. If you open a case with TS, we will update this thread to let people know that we are pursuing on that path.
Were you able to resolve the problem ? Im having a similar issue.
Please go through the logs as mentioned by Ana but check few more things before that.
are those instrument tags updating on OPC side?
that is a OPC HDA so check if data present is of good quality from OPC client tool and also if time stamp is updating fine on OPC end.
this seems to be a issue at OPC end.