Third party OPC lagging
Hello,
we getting data from Yokogawa EXA OPC and it's about 35000 items. To lad the first data to scada or object takes 6 - 7 seconds and to update changed value takes 1 or 2 seconds. Smart client works smooth, no lagging.
we getting data from Yokogawa EXA OPC and it's about 35000 items. To lad the first data to scada or object takes 6 - 7 seconds and to update changed value takes 1 or 2 seconds. Smart client works smooth, no lagging.
Answers
Please provide more detail on the ABB system
I am not aware of any delaying factors in the 800xA framework between PG2 (faceplates, displays, etc.) and the source OPC server.
If possible, remove known bad items - sometimes handling a problematic item may cause delays in an OPC server.
Contrary to PG2 where each graphic creates its own OPC groups and items in the source OPC server, Smart Client uses a "Data Provider" technique that likely share/multiplex subscriptions to common OPC items; if you close down *all* Smart Client displays and then call up one single, it is likely to see the same delay as you see in PG2.
If you want more details to feed back to Yokogawa, please use AfwApplogViewer.exe to enable the OPC Communicator Common and TimeMeasure logs in the client process (e.g. AfwWorkplaceApplication.exe).
These logs are quite noisy and you will need some basic OPC DA skills to decipher them. Start of with changing the TimeMeasure log from level 0 to 2.
Here a sample from the TimeMeasure log; adding 10 items took 26.7ms where most time was spent on parsing the OPC information before calling "AddItems" in the OPC server. This callup was NOT cached.
Closing and reopening the same graphic is faster (due to the OPC blob cache being valid now)
The Common log covers the OPC DA interactions (AddGroup, AddItems, Advise, OnDataChange, etc.)
If possible, remove known bad items - sometimes handling a problematic item may cause delays in an OPC server.
Contrary to PG2 where each graphic creates its own OPC groups and items in the source OPC server, Smart Client uses a "Data Provider" technique that likely share/multiplex subscriptions to common OPC items; if you close down *all* Smart Client displays and then call up one single, it is likely to see the same delay as you see in PG2.
If you want more details to feed back to Yokogawa, please use AfwApplogViewer.exe to enable the OPC Communicator Common and TimeMeasure logs in the client process (e.g. AfwWorkplaceApplication.exe).
These logs are quite noisy and you will need some basic OPC DA skills to decipher them. Start of with changing the TimeMeasure log from level 0 to 2.
Here a sample from the TimeMeasure log; adding 10 items took 26.7ms where most time was spent on parsing the OPC information before calling "AddItems" in the OPC server. This callup was NOT cached.
2020-08-11 09:54:21:912#1477, ABBIT25, AfwWorkplaceApplication, PID: 12488, Thread: 5140
OPC Communicator, TimeMeasure, level = 2, Tag =
COpcGroup::AddItemsImpl: Measurement: AddItems
STEP ........................... TIME .. START . END ...
Validate ItemBlobs ............. 0.01 .. 0.00 .. 0.01 ..
Prepare Parse ItemBlobs ........ 0.03 .. 0.01 .. 0.04 ..
Parse ItemBlobs ................ 24.94 . 0.04 .. 24.99 .
Prepare Add Items (count = 10) . 0.07 .. 24.99 . 25.06 .
Validate Item Permissions ...... 1.26 .. 25.06 . 26.33 .
Add Connector .................. 0.38 .. 26.33 . 26.70 .
AddItems Total : 26.70 msec
Closing and reopening the same graphic is faster (due to the OPC blob cache being valid now)
2020-08-11 10:03:35:560#4989, ABBIT25, AfwWorkplaceApplication, PID: 12488, Thread: 9824
OPC Communicator, TimeMeasure, level = 2, Tag =
COpcGroup::AddItemsImpl: Measurement: AddItems
STEP ........................... TIME . START . END ..
Validate ItemBlobs ............. 3.80 . 0.00 .. 3.80 .
Prepare Parse ItemBlobs ........ 0.03 . 3.80 .. 3.84 .
Parse ItemBlobs ................ 0.08 . 3.84 .. 3.91 .
Prepare Add Items (count = 10) . 0.06 . 3.91 .. 3.98 .
Validate Item Permissions ...... 1.03 . 3.98 .. 5.00 .
Add Connector .................. 0.34 . 5.00 .. 5.34 .
AddItems Total : 5.34 msec
The Common log covers the OPC DA interactions (AddGroup, AddItems, Advise, OnDataChange, etc.)
by Stefan Stromqvist
Can you share some more details/explanation?
Where is the lag and why is SC not affected?
by Tomas Rank: 316 on 8/11/2020 12:40:01 AM | Like (0) | Report
Hello,
sorry I made a mistake counting items, the true number is les then 25000. Lagging 6 to 8 sec is then you open new view or new faceplate, but then you write value to item its delayed 2-3 sec. Please look at diagnostics screens. Strange thing that one screen 'diag21' works faster even then hi has more item and some bad.
Add new comment