I think I have everything set right, but still cannot get a connection. I keep getting the following errors.
java.lang.Exception: Server did not return any endpoints matching the current criteria: SecurityPolicy=Basic128Rsa15, MessageSecurityMode=SignAndEncrypt, TransportProfileUri=http://opcfoundation.org/UA/profiles/transport/uatcpAlso, I have no idea what to set Target to. Any help would be appreciated.
I can’t help you with your issue but I do have a question … by what means are you establishing this connection?
I’m just curious … we’ve got a project in the pipeline on which a Beckhoff is used …
Could you start by setting the "OPCUAServer" logger to debug and then trying to establish the connection? After an attempt, you should have in your logs a line that says:
and another couple of lines that say:
Can you post these log entries?
Getting endpoints from "opc.tcp://CX_025B91:4840/PLC1"Received endpoint: opc.tcp://CX_025B91:4840 - [None:None:null]
Received endpoint: opc.tcp://CX_025B91:4840 - [None:Basic128Rsa15:null]
Received endpoint: opc.tcp://CX_025B91:4840 - [Sign:Basic128Rsa15:null]
Received endpoint: opc.tcp://CX_025B91:4840 - [SignAndEncrypt:Basic128Rsa15:null]
Hey Bryan,
Im am trying to connect via their OPC UA server.
[quote=“Kyle Chase”]Hey Bryan,
Im am trying to connect via their OPC UA server.[/quote]
Ah, ok … wasn’t aware they had an OPC UA server available … I’ll have to check it out … thanks.
Well the problem is that they are returning a null Transport Profile URI. I can make changes to handle this specific case, but the problem is really on their end.
This is why the OPC-UA interop and test lab need to happen!
Let me look in the config file. Actually, Ill post it here
[code]<?xml version="1.0" encoding="UTF-8"?>
0
0
0
0
0
50
5000
[NodeName]/Beckhoff/TcOpcUaServer/1
2
false
4 4 4 4 Binary<!--Update: No need to enter IP address -->
<Url>opc.tcp://[NodeName]:4840</Url>
<!--Update: No need to enter IP address -->
<SecuritySetting>
<SecurityPolicy>http://opcfoundation.org/UA/SecurityPolicy#None</SecurityPolicy>
<MessageSecurityMode>None</MessageSecurityMode>
</SecuritySetting>
<SecuritySetting>
<SecurityPolicy>http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15</SecurityPolicy>
<MessageSecurityMode>None</MessageSecurityMode>
<MessageSecurityMode>Sign</MessageSecurityMode>
<MessageSecurityMode>SignAndEncrypt</MessageSecurityMode>
</SecuritySetting>
shrug
Contact the vendor?
Haha, Im already on it. They said they did pass the interop though. Im sure it might just be a setting on my end, but figured Id check to see if anything stood out. The only thing Im not sure of is what the “Target” would be, and if I can set the Transport URI, as the documentation for Beckhoffs UA server is quite poor. Ill let you know
The target really doesn’t matter. I think I’m going to remove that from the settings. If you can set the transport URI, it is supposed to be “http://opcfoundation.org/UA/profiles/transport/uatcp”.
This must be an older verison of the server you are using.
The two products where tested at the last US IOP workshop last year and the Inductive client had exactly this problem with all C++ based OPC UA servers. This problem was fixed in the C++ servers but the client should be able to work also without this information since the opc.tcp prefix in the Endpoint URL gives also a hint regarding the protocol…
There is another problem with the transport URI. There was a wrong one in the generated code from the OPC Foundation. This was fixed in February 2010.
@Kevin
The transport URI you mentioned is wrong
“http://opcfoundation.org/UA/profiles/transport/uatcp”.
The right transport URI is
“http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”
So you may run with your client into servers that
You should provide a fallback detection based on the Endpoint URL prefix
Matthias
[quote=“Matthias Damm”]This must be an older verison of the server you are using.
The two products where tested at the last US IOP workshop last year and the Inductive client had exactly this problem with all C++ based OPC UA servers. This problem was fixed in the C++ servers but the client should be able to work also without this information since the opc.tcp prefix in the Endpoint URL gives also a hint regarding the protocol…
There is another problem with the transport URI. There was a wrong one in the generated code from the OPC Foundation. This was fixed in February 2010.
@Kevin
The transport URI you mentioned is wrong
“http://opcfoundation.org/UA/profiles/transport/uatcp”.
The right transport URI is
“http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”
So you may run with your client into servers that
You should provide a fallback detection based on the Endpoint URL prefix
Matthias[/quote]
After talking with Nathan Pocock and others at the OPC foundation about this a few weeks ago I was told that the correct URI will be “http://opcfoundation.org/UA/profiles/transport/uatcp”. I’ve been told it’s now in the hands of those who actually make and publish the changes to the spec, and that the currently published version of the spec is out of date in other areas as well.
I’ve since modified the client to be more relaxed when connecting to servers returning an unexpected URI.
If you know something or have heard otherwise about the transport profile URI I’d be interested in hearing.
I have not seen any change request for the specification in this area. I discussed this with Randy Armstrong from OPC Foundation in February and now again.
We agreed that the specification is right.
-> “http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”
He will provide more details soon.
Hi Kevin,
I apologize for the confusion, however, we discussed this issue and tried to balance the needs of the existing applications vs. the desire to avoid spec changes so we came up with the following plan:
The specification will not be changed. The official URL is:
http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary
The v1.0 and v1.1 versions of the .NET SDK have been updated and will accept both URIs:
http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary
http://opcfoundation.org/UA/profiles/transport/uatcp
i.e. if an out of date Client passes the incorrect URI to a .NET Server the server will respond as if it have received the correct URI. If a .NET Client receives incorrect URIs from an out of date server it will convert them to the correct URIs before further processing.
My recommendation is other stack developers do the same.
Also: we it comes to specification errata all changes which are proposed are submitted as Mantis issues which you can find here: http://www.opcfoundation.org/mantis/view_all_bug_page.php
Anyone wishing to know what known spec issues exist should look there. Note that the WG will not accept every proposed change (e.g. the transport URI change was rejecetd by the WG).
[quote=“RandyArmstrong”]Hi Kevin,
I apologize for the confusion, however, we discussed this issue and tried to balance the needs of the existing applications vs. the desire to avoid spec changes so we came up with the following plan:
The specification will not be changed. The official URL is:
opcfoundation.org/UA-Profile/Tra … c-uabinary
The v1.0 and v1.1 versions of the .NET SDK have been updated and will accept both URIs:
opcfoundation.org/UA-Profile/Tra … c-uabinary
opcfoundation.org/UA/profiles/transport/uatcp
i.e. if an out of date Client passes the incorrect URI to a .NET Server the server will respond as if it have received the correct URI. If a .NET Client receives incorrect URIs from an out of date server it will convert them to the correct URIs before further processing.
My recommendation is other stack developers do the same.[/quote]
Thanks for clearing that up. I’ll follow suit.
Hi Kevin,
This is one of the details we need to sort out in the beginning of a new specification life cycle…
The goal is always to not change released specs in areas where it breaks compatibility with older versions. The profile URIs are critical parts of the spec, changing them will break compatibility. The mentioned areas in the spec that need updates are more clarifications about expected behaviour that is not defined detailed enough. These missing details are typically found during product implementations, interoperability testing and during the development and use of the compliance test tool.
The good news is that the compliance test tool development makes good progress.
I fully agree with your statement:
[quote]Kevin wrote:
This is why the OPC-UA interop and test lab need to happen![/quote]
At the moment it is important to test products with demo servers / clients based on the different SDKs and stack versions. I assume you are already testing with the .NET SDK from the OPC Foundation.
You should also test with the C++ based UA Demo Server and UaExpert (client) provided by Unified Automation. You can find free downloads at
unifiedautomation.com
A lot of commercial C++ based OPC UA servers are based on the same C++ SDK that was used to build this demo server.
I assume you are also providing demo downloads of your product. I will recommend to Unified Automation that they test releases of their SDK with your server and client. Is there a special version or component they should use for testing?
Thank you
Matthias
Downloading the trial version from here installs the OPC-UA server module along with it. The trial is essentially a full version of the software that runs on a 2-hour time limit that needs to be reset.
CD-Key’s to license the OPC-UA server module can be obtained for free from here.
The server will be running on startup and can be connected to on port 4096 by default to retrieve endpoints. The server does not support RegisterServer and it does not currently attempt to register itself with a well-known discovery server. By default you must connect with a username/password of opcuauser/password, but anonymous access can be turned on. It would probably be useful to add a simulator device so there’s more meaningful nodes present in the address space. This can be done in the Configure area under Ignition OPC-UA > Devices.
To test the client against another OPC-UA server, in the Configure area under OPC Connections > Servers a connection can be added to another OPC-UA server. Choose the non-clustered OPC-UA connection and enter the servers details. Then basic browse/read/write/subscribe functionality can be tested in the quick client located in the same section, OPC Connections > Quick Client. I would advise waiting until we release 7.0.6 in the next few days to test the client as the changes regarding the transport profile URI won’t be in place until then.
I will include the Unified Automation server and client in my testing from here out. I appreciate the cooperation we have going on here. Glad to see you posting on our forums.
Alrighty. I updated to the latest Beckhoff OPC UA server, and the latest Ignition release. I copied the certificate from the Ignition gateway into the beckhoff controller, but I still get
com.inductiveautomation.ignition.gateway.web.pages.config.systemconsole.LogViewer$SerializableLoggingEvent$ClonedThrowable: Error code = Bad_CertificateInvalid. Error message = None.We are getting there!!. What side is the problem on?
It looks like the Beckhoff OPC UA Server is rejecting the certificate for some reason. Maybe the client certificate is not installed correctly or it is not in a valid format?