OPC-UA : Browse fail

Ignition
1

Hello all,

I encounter a problem with the in-built OPC browser (not the tag browser) when trying to browse a specific folder/branch of a SIEMENS PLC (S7-1500). I use the PLC OPCUA Server (not the siemens driver). The PLC is declared as an OPC Server connection (and not as a device)

The problematic folder contains about 690 items. My guess is that it is too much for the OPC Browser.
Items can be addressed by typing manually the itemPath.
Other folders can be browsed by the OPC Browser without any UaServiceFaultException.
The problematic folder is browsed without any error with an external UA Client (UAExpert).

My questions are :
Does this exception come from the number of items in the folder ?
If yes, how can this limit be raised ?

Any help or clue highly appreciated.

Regards.

[quote]com.inductiveautomation.ignition.client.gateway_interface.GatewayException: UaServiceFaultException: status=Bad_TooManyOperations, message=The request could not be processed because it specified too many operations.
at com.inductiveautomation.ignition.client.gateway_interface.GatewayInterface.newGatewayException(GatewayInterface.java:327)
at com.inductiveautomation.ignition.client.gateway_interface.GatewayInterface.sendMessage(GatewayInterface.java:297)
at com.inductiveautomation.ignition.client.gateway_interface.GatewayInterface.invokeWithTimeout(GatewayInterface.java:896)
at com.inductiveautomation.ignition.client.gateway_interface.GatewayInterface.browseOPC(GatewayInterface.java:900)
at com.inductiveautomation.ignition.designer.sqltags.opcbrowser.OPCFolderNode.loadChildren(OPCFolderNode.java:52)
at com.inductiveautomation.ignition.client.util.gui.tree.AbstractAsynchronousTreeNode$Loader.run(AbstractAsynchronousTreeNode.java:75)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException
com.inductiveautomation.ignition.common.GenericTransferrableException: UaServiceFaultException: status=Bad_TooManyOperations, message=The request could not be processed because it specified too many operations.
at java.util.concurrent.CompletableFuture.reportGet(Unknown Source)
at java.util.concurrent.CompletableFuture.get(Unknown Source)
at com.inductiveautomation.xopc2.client.OpcUaConnection.browse(OpcUaConnection.java:495)
at com.inductiveautomation.ignition.gateway.opc.OPCManagerImpl$ServerWrapper.browse(OPCManagerImpl.java:754)
at com.inductiveautomation.ignition.gateway.opc.OPCManagerImpl.browse(OPCManagerImpl.java:468)
at com.inductiveautomation.ignition.gateway.sqltags.tagproviders.internal.InternalSQLTagsProvider.browseOPC(InternalSQLTagsProvider.java:79)
at com.inductiveautomation.ignition.gateway.sqltags.providers.RedundantProviderWrapper.browseOPC(RedundantProviderWrapper.java:174)
at com.inductiveautomation.ignition.gateway.sqltags.SQLTagsManagerImpl.browseOPC(SQLTagsManagerImpl.java:925)
at com.inductiveautomation.ignition.gateway.project.ProjectSettingsCache$ProjectDefaultTagManagerFacade.browseOPC(ProjectSettingsCache.java:484)
at com.inductiveautomation.ignition.gateway.servlets.gateway.functions.SQLTags.browseOPC(SQLTags.java:814)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.inductiveautomation.ignition.gateway.clientcomm.progress.MethodInvokeRunnable.run(MethodInvokeRunnable.java:27)
at com.inductiveautomation.ignition.gateway.clientcomm.progress.GatewayProgressManagerImpl$GatewayProgressTask.run(GatewayProgressManagerImpl.java:233)
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$ThrowableCatchingRunnable.run(BasicExecutionEngine.java:537)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
… 3 more
Caused by: org.eclipse.milo.opcua.stack.core.UaServiceFaultException
UaServiceFaultException: status=Bad_TooManyOperations, message=The request could not be processed because it specified too many operations.
at org.eclipse.milo.opcua.stack.client.UaTcpStackClient.receiveResponse(UaTcpStackClient.java:283)
at org.eclipse.milo.opcua.stack.client.UaTcpStackClient.lambda$sendRequest$3(UaTcpStackClient.java:145)
at java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)
at java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
at java.util.concurrent.CompletableFuture.complete(Unknown Source)
at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$null$19(UaTcpClientMessageHandler.java:528)
… 3 more

Ignition v7.8.4 (b2016082217)
Java: Oracle Corporation 1.8.0_111[/quote]

2

I think you can work around this by lowering the “Max Per Operation” advanced setting on the OPC UA connection.

A proper fix that doesn’t require this change has been implemented in 7.9.1.

3

Thank you Kevin for your reply.

Unfortunately, the work around did not work. We lowered the value down to 4096 then 1024. The browse still fails.
We gave a try with a value set to 16384, jst to be sure but the exception is still raised and the browse fails.

A fresh gateway start does not change anything.

Is there other workarounds we could explore to solve this problem ?

Regards.

4

You may still have to go lower than 1024. If you can capture the exchange on Wireshark I can verify what is happening.

5

It worked for a value set to 333.

Thank you for your help.

6

Hi Kevin, I have the same problem with the Java Milo SDK. Do you know how/where I can set this “MaxPerOperation” within the Java Milo SDK? Maybe it is the wrong forum, but it seems that you are a main Eclipse Milo contributor … :slight_smile:

7

There is no equivalent in the SDK. The Ignition client uses this value (along with operation limits read from the address space) to batch operations as necessary before making service calls.

The more appropriate forums for Milo-related questions are either Stack Overflow (tagged milo and opcua) or as of a week ago the GitHub Discussions page in the repo: https://github.com/eclipse/milo/discussions

8

Ok, thanks! I thought it is a similar issue, at least the error sounded similar, that’s why Google directed me to this forum… I will try on stackoverflow…

9

It probably is similar, and the solution is probably to implement batching of operations beyond a certain size in your client.

10

I just tried the browse node example from milo and my server complains that there are too many operations in the queue… I already removed the recursive call in the sample and so it should be a single browseNode SDK function call …

11

Start a discussion here and upload a Wireshark capture of the interaction: https://github.com/eclipse/milo/discussions?discussions_q=category%3AQ%26A

Make sure you are not connecting to an endpoint with security for the capture.

12

I think I have used the wrong example, the BrowseExample.java is doing the right job for me. I don’t know what the BrowseNodeExample.java is doing, and why it breaks my server.

But thank you very much for your help and quick responses! and I am really sorry if I have wasted your time …

13

I can only guess without Wireshark or seeing your server or more information, but it sounds like your server has an exceptionally low maximum operations allowed for some service calls. The BrowseNodeExample one is using the client SDK’s AddressSpace API that creates UaNode instances, and when those are being constructed certain things happen like reading all of an Object or Variable Node’s attributes, which can be as many as 15 operations in a single read call.

Like I said… exceptionally low, if that’s what is going on. :grimacing: