From: Z.
Sent: Wednesday, March 08, 2017 4:28 AM
To: C.
Subject: RE: Problem when writing large number of tags with WriteMultiple (UA)

C.,

This is caused by exceeding the OPC UA encoding limits – in this case, the maximum array length, which defaults to 65535.

A hint to this can be found if you inspect .Exception.ServiceResult.InnerResult.Description in any of the returned result objects – it contains a string "MaxArrayLength 65535 < 70000" – but I admit that’s not easy to find.

The actual array length for the OPC operation in your example is 70000, which is 2*35000. This is because QuickOPC must first determine the data types, and does a “read”, two attributes per each node, before it can convert the values and do the actual “Write”. This is somewhat inefficient (although QuickOPC remembers the outcome and does not repeat the read next time the same node is written) and could be overcome by specifying the type inside the write arguments. All that is unrelated to the issue you reported, but it reduces the count of nodes you can write to 32767 instead of 65535; if the types were specified, it would be the full 65535 nodes (and no “read”).

In order to change the encoding limits, one needs to follow a procedure described (in part) here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...plication%20Configuration.html . This is because the encoding limits are at fairly low level of the OPC UA stack, and we do not have (yet) properties in the API to configure all of that stuff. I have tried to do that, but in the process I have discovered a bug that prevents the custom configuration from being usable. Consequently, your customer cannot use this solution now.

Here is what I will do:
1. In the upcoming version (2017.1), I will fix the bug, so that the developers will actually be able to provide their custom UA stack configs.
2. In the upcoming version (2017.1), I will increase the default MaxArrayLength by an order of magnitude (ten-fold), because I think there is no need for this value be so low in .NET applications. Consequently, for counts up to several hundred thousands of items, developers will not have to resort to custom UA stack configs at all.
3. If needed to address your customer’s issue, I can do these changes to the current version (2016.2) and make a new build of it, but I would prefer not to – let me know.

[...]

Best regards
Z.

From: C.
Sent: Tuesday, March 07, 2017 7:44 PM
To: Z.
Subject: Problem when writing large number of tags with WriteMultiple (UA)

Hi Z.,

I am working with a customer who is trying to write a large number of tags (could be up to ~102k tags) with a single WriteMultiple call. He has noticed that when he attempts to write more than around 18k tags, the write does not reach the OPC Server. The error message he receives is: “Failure -2146959360 (0x80080000): Could not send request to server.””

I was able to reproduce this message here with the TOP Server and some simulated devices, but I must write around ~35k tags to get the message.

I was hoping you could tell us the source of this error message, and the proper way to resolve this, or work around it.

The customer is not opposed, and I have encouraged him to do this, to splitting up into smaller groups of writes – he just wants to know a concrete reason as to why this is happening, and what (if any) control [there is in QuickOPC] over this.

I’ve attached a sample C# project and TOP Server (Or KepServer) project (Version 6.0 or later) that I used to reproduce the behavior, incase you’d like to take a look.

Thanks,

C.