Some (most) of the parameters mentioned above relate to Reads(&Writes), and only some relate to Subscriptions. It is my understanding that the customers is only interested in subscriptions. In such case, he can ignore the Slowdown/Speedup weights, abandonment intervals, automatic rates for read/write. We can get into their explanation but only if they are truly using explicit Reads a lot – let me know.



For Subscriptions, we are left mainly with these parameters:

- Percent deadband buckets/decade, Update rate deadband buckets/decade: These are meant to limit the number of OPC groups created in the server, in case that different percent deadband or update values are specified that are fairly close to each other. For example, it makes little sense to create 3 groups with update rates of 1000, 1001, 1002 milliseconds; and it makes little sense to create 3 group with percent deadband of 10.0%, 10.1% and 10.2%. The component therefore only creates OPC groups with certain update rates and percent deadband, and uses them even if the specified update rate or percent deadband is not precise. For example, with the above examples, we would only create a single OPC group with an update rate of 1000 milliseconds, and with a percent deadband of 10%, and all items will go into this group. The group parameters we choose are the “buckets” we put the items into. Saying that there are e.g. 6 buckets per decade means that there are six of them between 10 and 100 milliseconds, 6 of them between 100 and 1000 milliseconds, 6 of them between 1000 and 10000 milliseconds and so on – it is on a logarithmic scale. With 6 buckets per decade, the update rates for the possible buckets will be roughly 10, 15, 22, 33, 47, 68, then 100, 150, 220, 330, 470, 680, then 1000, 1500, 2200, 3300, 4700, 6800 milliseconds, and so on.

- The downside of the above approach is that you do not necessarily get what you have asked for. You may ask for update rate = 500 milliseconds, but we will use the bucket with 470 milliseconds update rate (we always choose the same or faster; similarly, for percent deadband, we always use the same or lower). If this behavior is not appropriate for the specific app, you can set ExactManualGroupMatch = true and the whole “bucketing” thing will be disabled (for explicit Subscriptions).

From: C.
...

2. A.’s question at the bottom is this: Now my guess is the OPC client is auto adjusting the rates from numerous factors: percent deadband, slowdown weight, hold periods, abandonment interval, automatic read, percent deadband buckets per decade, update rate buckets per decade, etc. I tried to play around with these settings but I really cannot tell if the turning off a setting worked or not, for example I cannot tell slowdown weight is turned off or reset to default if I set slowdown weight to 0(0.0f in C#) instead of default 1.



a. My thoughts: he has set EasyDAClient.TopicParameters.ExactManualGroupMatch = true, which would negate most of your internal optimizations for update rates correct? He is also setting the other properties like SlowdownWeight and UpdateRateBucketsPerDecade, which would not get used if the first setting is true – correct?

b. Any clarification on how the internal optimizations in EasyOPC works would be greatly appreciated since I am sure they will ask.