Error connecting to 3rd party UA server: Exception: session inactive

Ignition
1

ok, note that I am able to connect to the Ignition OPC UA Server, now I am not able to connect to the remote opc-ua server.

This was working before with 8.0.2RC1. Now at 8.0.2 I am getting similar errors as before.

Ok, after deleting the cert…pfx files and restarting… I am getting different connection refused errors.

java.lang.Exception: session inactive: id=NodeId{ns=0, id=12345} name=ignition[Ignition-ubnt18]_MyOpc_Server_1564509157964
	at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaConnection$MiloSessionActivityListener.onSessionInactive(OpcUaConnection.kt:285)
	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$null$31(SessionFsmFactory.java:557)
	at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(Unknown Source)
	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$configureActiveState$32(SessionFsmFactory.java:557)
	at com.digitalpetri.strictmachine.dsl.ActionBuilder$PredicatedTransitionAction.execute(ActionBuilder.java:76)
	at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.lambda$run$0(StrictMachine.java:207)
	at java.base/java.util.ArrayList.forEach(Unknown Source)
	at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.run(StrictMachine.java:198)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

8.0.2 (b2019060511)
Azul Systems, Inc. 11.0.3
2

Seems like the server is sending ServiceFault or something else causing the session to go inactive.

You can turn loggers for OpcUaConnection and SesionFsm to DEBUG and/or get a Wireshark capture and send those to me.

3

Thank you. I will work on those captures.

If I disconnect the ignition server from network. I am able to communicate with the opcua server using FreeOpcUa client. It does not time out in this case. Once I connect ignition server, both clients will get the same connection refused.

ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it
uawidgets.utils - WARNING - Error class <uaclient.connection_dialog.ConnectionDialog object at 0x04BE1990>s no member show_error or error’)

I was able to browse the directory with the Ignition designer and read and write values using the ignition quick client, before upgrading to 8.0.2

4

I don’t know if this issue is the same as original. I thought it was because the first exception included “PKCS12KeyStore”… but now this might be another issue. Maybe independant or closer related to my original Uint32 post. Please moderate however you feel is best.

5

The Wireshark capture you sent shows the device closing the TCP connection after one of the ReadRequests Ignition sends. There’s no clear reason why.

You’re probably going to have to get support from the device vendor or whoever built this device’s UA server implementation.

6

So this wasn’t an issue in 7.0.10 or in 8.0.2rc2 but now it is.

One thing stands out in the exception thrown. What is ns=0, id=12345? Why is the name : ignition…

session inactive: id=NodeId{ns=0, id=12345} name=ignition[Ignition-ubnt18]_MyOpc_Server_1564509157964

This shows connected. Then ignition sends several packets to the opc server. what is being sent and why? This happens before even adding to a project as a tag. We are able to use this with the older versions and a polled/on demand scan class group. In 8.0.2 it is different.

7

The ReadRequest that the server is closing the connection in response to contains 167 items. I’m guessing that you have 167 tags defined for this server and are using an OPC Read Mode tag group as discussed previously.

It’s possible this is too many tags to read at one time from this server. The read for the operation limits is failing with Bad_NodeIdUnknown, so the client is just falling back to default values. A correctly implemented server would be responding with Bad_TooManyOperations in this case, rather than closing the connection, but who knows.

You can try changing the “Max Per Operation” setting on the OPC UA connection to 50 or 100 and see if it helps. You really need to get the vendor of this server involved, though, because it seems to be kind of a poor implementation.

1 Like