Hi,
I am evaluating Ignition 7.6.4 as a possible central OPC UA server.
As a test I was trying to connect to a 3rd party OPC UA server, namely the binary example server (version 1.0.2.2) from OpenOpcUA.org.
Both Ignition and the OpenOpcUA server are running locally.
The discovery server recognises both servers and I am able to connect to boh servers using UaExpert from Unified Automation.
I added the configuration for the 2nd OPC server (localhost, none, none on port 16664, which uaexpert can connect to).
Ignition indicates the connection as Faulted with the following details:
java.lang.NullPointerException: null
com.inductiveautomation.xopc.client.util.ConnectionUtil.getEndpoint(ConnectionUtil.java:78)
com.inductiveautomation.xopc.client.OpcUaConnection.createUaClient(OpcUaConnection.java:523)
com.inductiveautomation.xopc.client.OpcUaConnection.verifyConnectionState(OpcUaConnection.java:141)
com.inductiveautomation.xopc.client.FailoverAwareOpcUaConnection.verifyConnectionState(FailoverAwareOpcUaConnection.java:75)
com.inductiveautomation.ignition.gateway.opc.OPCManagerImpl$ServerWrapper.verifyConnectionState(OPCManagerImpl.java:742)
com.inductiveautomation.ignition.gateway.opc.OPCManagerImpl$OPCConnectionKeepalive.run(OPCManagerImpl.java:618)
com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$TrackedTask.run(BasicExecutionEngine.java:573)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
java.lang.Thread.run(Thread.java:722)
In the Console, I increased the logging of ConnectionUtil, but all this produces is:
ConnectionUtil Getting endpoints from “opc.tcp://localhost:16664”
Attached is also a log that should contain this error getting the endpoints.
One thing I noticed in UaExpert is that it indicates the endpoint as: opc.tcp://3dns.adobe.com:16664/4CEUAServer
This 3dns.adobe.com seems to come from the certificate used by the server. I’m not sure if this is normal.
Did anyone ever try to connect to this server?
Do I need to accept the OpenOpcUA server certificate somewhere?
Any hints?
Best I can tell it means the GetEndpointsResponse contains a null EndpointDescription list and Ignition isn’t expecting that to be null…
So… even if it didn’t error out, you still wouldn’t be getting any further because there’s no EndpointDescriptions being returned to connect to.
thanks for the hint, I will try to figure out if the remote server is sending a null.
Would this show up somehow in a client like UaExpert?
UaExpert does not seem to have a problem connecting, so if I can compare it somehow… 
maybe some logs that can be usefull to diagnose?
If I turn on the logging for DiscoveryServer.services.DiscoveryGetEndpointsService, it is showing me something like this:
Time Logger Message
(T) 5:34:01 PM DiscoveryServer.services.DiscoveryGetEndpointsService GetEndpointsResponse: . responseHeader=serializable... . [ . ResponseHeader .. timestamp=Sun Feb 02 17:34:01 CET 2014 .. requestHandle=0 .. serviceResult=StatusCode[Severity=Good, Subcode=NotSpecified] .. serviceDiagnostics=null .. stringTable=collection... .. additionalHeader=null . ] . endpoints=collection... . { . EndpointDescription .. endpointUrl=opc.tcp://192.168.0.101:4840/iaopcua/discovery .. server=serializable... .. [ .. ApplicationDescription ... applicationUri=uri://192.168.0.101/Ignition%20OPC-UA%20Discovery%20Server ... productUri=http://inductiveautomation.com/products/ignitionopc/ ... applicationName=Ignition OPC-UA Discovery Server:en_US ... applicationType=DiscoveryServer ... gatewayServerUri=null ... discoveryProfileUri=null ... discoveryUrls=collection... ... { ... String .... value=[C@32085ace .... hash=0 .... hash32=0 ... } .. ] .. serverCertificate=[B@4281a40b .. securityMode=None .. securityPolicyUri=http://opcfoundation.org/UA/SecurityPolicy#None .. userIdentityTokens=collection... .. transportProfileUri=http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary .. securityLevel=1 . }
(D) 5:34:01 PM DiscoveryServer.services.DiscoveryGetEndpointsService Sending GetEndpointsResponse. ReqHandle=0
(T) 5:34:01 PM DiscoveryServer.services.DiscoveryGetEndpointsService GetEndpointsRequest: . requestHeader=serializable... . [ . RequestHeader .. authenticationToken=ns=0:i=0 .. timestamp=Sun Feb 02 17:34:01 CET 2014 .. requestHandle=0 .. returnDiagnostics=0 .. auditEntryId=null .. timeoutHint=300000 .. additionalHeader=com.inductiveautomation.opcua.types.ExtensionObject@537631a7 . ] . endpointUrl=opc.tcp://localhost:4840 . localeIds=collection... . { . String .. value=[C@74b5f5bf .. hash=0 .. hash32=0 . } . profileUris=collection...
(D) 5:34:01 PM DiscoveryServer.services.DiscoveryGetEndpointsService Received GetEndpointsRequest. ReqHandle=0
but it is not clear to me if the message part is complete or not.
Is this a response that is supposed to come from the local discovery server?
Attached is the binary log.
If you can see any indications of Null being returned somewhere… let me know
Hello,
I suggest you two thing :
1- Increase the trace level on the OpenOpcUa server
2- Post your request to the OpenOpcUa projet site
http://www.openopcua.org/redmine/projects/opcua-cpp-quickserver/issues
Best regards
Michel Condemine
OpenOpcUa Project leader
Something to keep in mind: Ignition’s UA client does not do any discovery… it just assumes you’ve configured it to point at a valid endpoint on the server (one that matches the hostname, port, and security settings).
So what’s happening here is that it calls GetEndpoints on the host and port you’ve configured and is getting a null list of EndpointDescriptions back.
My point is: if your pointing at the port that OpenOpcUa is running discovery on, and not the actual port the other services are bound to, assuming they’re different, it could be your problem.
[quote=“Michel4CE”]Hello,
I suggest you two thing :
1- Increase the trace level on the OpenOpcUa server
2- Post your request to the OpenOpcUa projet site
http://www.openopcua.org/redmine/projects/opcua-cpp-quickserver/issues
Best regards
Michel Condemine
OpenOpcUa Project leader[/quote]
I have increased the log level of the OpenOpcUa server but I don’t immediately see any errors pop up. I will add a log to the project site.
I was doing some more tests.
After increasing the TCPClientChannel logging, I get this message:
GetEndpoints TCPClientChannel Connecting to opc.tcp://localhost/127.0.0.1:16664/, securityMode=None, securityPolicy=None)
This seems a little weird. Why is it showing both hostname and ip address?
In the OPC UA connection settings, I only used localhost.
Following that message there is also:
GetEndpoints TCPClientChannel Error sending CloseSecureChannelRequest
StatusCode[Severity=Bad, Subcode=Bad_NotConnected]: Bad_NotConnected
at com.inductiveautomation.xopc.client.stack.TCPClientChannel.stopIOAndShutdown(TCPClientChannel.java:303)
at com.inductiveautomation.xopc.client.stack.TCPClientChannel.access$800(TCPClientChannel.java:69)
at com.inductiveautomation.xopc.client.stack.TCPClientChannel$ClientIOEventHandler.connectionLost(TCPClientChannel.java:871)
at com.inductiveautomation.iosession.socket.AsyncSocketIOSession.run(AsyncSocketIOSession.java:74)
at java.lang.Thread.run(Thread.java:722)
but that might just be a result of the fact that there is an issue reading the endpoints.
just a little update…
I did a sniff with wireshark and openopcua is indeed returning an empty array of endpoints as response to the getEndPoints request.
I’ll see if I can get openopcua to return something.
Just a small follow-up, I managed to get this link working by debugging the connection on OpenOpcUA side and comparing with a Discovery example from the unified automation toolkit.
The only difference I could find in the GetEndpoints request was a nNoOfProfileUris parameter that was -1 in the ignition request and 0 in the unified automation request.
This difference causes OpenOpcUA to return an empty list of endpoints.
After slightly modifying the code to do the same for -1 as for 0, the OpenOpcUA server correctly returns 3 endpoints an no longer prevents Ignition to connect.
I still need to investigate if there is another underlying problem that I am just hiding with this workaround but I hope Michel can shed some light on this as well.