Hello.
The OPC UA specification defines variables which the server can use to announce to its clients which capabilities and limits it has, so that the clients can adjust accordingly.
In an ideal world, this will work like this:
1) The server will correctly expose and fill in the capabilities/limits variables.
2) The client (QuickOPC, in this case) will correctly interpret them and attempt to adjust, where possible.
On the client side, QuickOPC currently does *some* of it, but not all. Specifically, in version 2024.1, it honors the "MaxMonitoredItemsPerCall" variable, but it does not honor the "MaxMonitoredItemsPerSubscription" variable, and this can be the reason for the behavior you observed.
We have a work item to also provide support for "MaxMonitoredItemsPerSubscription" and if needed, create more subscriptions to accommodate for larger number of monitored items, but it has not been assigned a target release yet. I may be able to squeeze it into the upcoming QuickOPC 2024.2 release which is probably going to be out in November. But for it to make sense for you, we want to be sure that the requirements are also fulfilled on the server side - i.e. that the server announces its limits properly.
To verify this, can you please use our OpcCmd utility, and issue a following command, replacing the endpoint URL of our demo server with the endpoint of your server:
OpcCmd uaClient collectSoftwareInfo //opcua.demo-this.com:51210/UA/SampleServer
This collects various info about the server, including the capabilities and limits, and displays a table.
Once you know that the command is working, start it again (from the Windows command prompt), and this time redirect the output to a text file, by appending e.g. "> output.txt" to the end of the command line.Then, post the resulting output.txt file here; or email to support09 (at) opclabs.com if there is privacy concern; but you can verify that the contents of the file is actually just software info, there should be nothing "private" in it anyway.
If you need a solution right now, I can only offer an ugly workaround:
Choose a somewhat different monitored item arguments for different sets of items. For example, use sampling rate 1000 with first 200 items, and then use sampling rate 998 with the second set of 200 items, and so on (make at least 2 milliseconds difference). This will cause QuickOPC to maintain separate subscriptions.
It would also be possible to use multiple EasyUAClient objects with Isolated = true setting, but that is even uglier, because it would cause separate sessions to the server, so this requires even more resources and you would likely hit another server limit soon.
Best regards
