Applies To: |
|
Summary: |
Customers using small values of [OPC]Block
together with [OPC]LeaveTagsActive=0 were experiencing issues with
items continually activating and deactivating. This is because the IOServer only permits a certain number of requests to be outstanding to a driver at a time (controlled by [OPC]MaxPending). Each request can retrieve a number of tag values, depending on the [OPC]Block parameter. Thus, if [OPC]MaxPending=10 and [OPC]Block=10, then up to 100 tag values can be read at a time. If all 100 of these reads require an activation (i.e. tag was not previously active) there may be some delay whilst the tags activate, meaning that it is some time before the next 100 tags can be read. For large numbers of tags, this may result in a time between polls that is greater than the [OPC]ItemLifeTime, and so the tag gets deactivated before it is read again. |
Solution: |
This has been fixed by increasing the
default value of [OPC]MaxPending from 10 to 255 and providing some
new driver statistics for tuning purposes. The new range for [OPC]MaxPending is 1 to 1024, with a default of 255. The new statistics are available in the Citect Kernel by viewing the driver statistics in verbose mode. The new statistics are:
1) Run system using default parameters for a while, monitoring stats in kernel. 2) Set [OPC]Timeout = 2 x "Max Activate Time" 3) Set desired block size. 4) Set [OPC]MaxPending to be at least 1.5 x the 'normal' peak value of "DCBs in Handling Que". i.e. if "DCBs in Handling Que" usually peaks at 100, set [OPC]MaxPending to > 150 to allow for burst write traffic. |
Keywords: |
OPC, LeaveTagsActive,
ItemLifeTime |
Related Links
Attachments