In addition, can you please confirm that the limit is 200 monitored items per subscription for this server? And, do you know if it is fixed, or can it be configured somewhere on the PLC?

Hello, thanks again.

Yeah, that is what I was afraid of. These specific server variables have been added in OPC UA specification version 1.05.01 so it is possible that the server does not have them. So, in order to help you with this server, we need not just to split the subscriptions, but also have a way to specify the maximum number of items in a subscription externally - as you suggested. Hopefully there won't be a too-small limit on on the number of subscriptions (but that you will figure out with the "workaround" test anyway).

Regards

Hello, and thank you.

1) We have decided to implement the handling of MaxMonitoredItemsPerSubscription - and automatically create more subscriptions if needed. It will be QuickOPC 2024.2; release date is likely in November 2024.

2) As it turned out, the "surveying" algorithm in the OpcCmd version you have does not yet collect all the info I wanted. Consequently, I still cannot confirm that the above mentioned change will work with your server, because I do not know for sure if it reports the right numbers to us. If you have time, I would like to ask you to kindly also capture the output of the following two commands (with the endpoint URL changed to your server):

Best regards

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:
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