800xA OPC Client Communication via Matrikon Tunneller Drop Down
We have an OPC Client 800xA SP2 Rev.E system (Generic OPC) connected via Matrikon Tunneller to an WinCC OPC Server.
What's happen:
Once i open a faceplate (e.g. DWSAIT101) the client ask for the tag value and the log of the Matrikon Tunneller writes:
[07/26 16:47:55.89](3 ID=276) CDevLink::Add() Unabled to add item with an empty path.
[07/26 16:47:55.89](3 ID=276) CDevItem::SetActiveState() [DWSAAH101] update rate=600ms
[07/26 16:47:55.89](3 ID=276) CDevItem::SetActiveState() [DWSAIT101Flt] update rate=600ms
[07/26 16:47:55.89](3 ID=276) CDevItem::SetActiveState() [DWSAAL101] update rate=600ms
[07/26 16:47:55.89](3 ID=276) CDevItem::SetActiveState() [DWSAIT101] update rate=600ms
(Maybe an empty path is referred to “limit4_active”. See “PrintScreen.gif” attached.)
After that, the client ask for all items synchronization:
[07/26 16:47:56.90](3 ID=256) CTunnellerSyncItemStatesReq::_BeforeExecute() Creating item list for synchronization
Then all the tags go in bad quality for 1 second and then return good.
The strange fact is that every time the client ask for a value of one specific tag, see example inside the logs:
· [07/26 16:49:07.44](3 ID=740) Opened DWSAIT102 pop-up
· [07/26 16:49:42.08](3 ID=740) Opened DWSAIT103A pop-up
· Etc..
After that the client ask also for the refresh of all the database and the communication drops, I mean we have a bad quality of all items, the service is every connected. (it seems to be overloaded).
I think the right way should be when the client side only ask for the activation of a single tag and stop. With less than 30 tags the communication works fine.
Is it possible to disable that refresh?
Where can i check client side (800xA OPC Client logs)?
Finally why the update rate is 600ms when all my tag have an update rate in control connection not less than 1 second?
See “PSTCFGMatrikon.OPC.Tunneller.1.LOG” attached.
Waiting for some feedback.
Thanks.
Fabio
Answers
Sounds very strange!
Generic OPC uses 3000 ms in 800xA unless .ocs file has been tweaked, or a custom Control Connection is used.
The OPC DA Connector's "Basic" log in AfwApplogViewer.exe will tell exactly what OPC calls are made to the tunnel end.
I've seen tunnellers silently converting (preferred) asynchronous calls into (less desired) synchronous calls on the other side... trying another tunneller might reveal oddities...
Add new comment