No matching endpoints found

I am evaluating Ignition 8 and am trying to connect to a CODESYS SoftPLC configured as an OPC-UA server. I actually have two PLCs : one locally on my laptop (which also hosts Ignition), and the other one on a Raspberry Pi. In both cases, I encounter the exact same problem. I know the OPC-UA server works, as I was able to connect with a separate client (no certificate, no user/password).

When I try connecting to the OPC-UA server from Ignition's configuration, it seems to work fine. I am able to get to the last step, which shows "opc.tcp://127.0.0.1:4840" as the endpoint, along with Security Policy : none and Security Mode : none. I hit finish, and the connection comes out as "Faulted".

The connection log shows this :

UaException: status=Bad_ConfigurationError, message=no matching endpoints found
...
8.0.2 (b2019060511)
Azul Systems, Inc. 11.0.3

I have seen in the migration notes that the server's certificate needs to be marked as trusted. I have generated a certificate, and marked it as trusted. The problem remains the same.

I must be missing something very simple here, but I have been unable to find what it is.

Thanks in advance for your help.

1 Like

Is this server really running on the same machine as the gateway or are you using some other IP address to being the discovery process?

Can you get a Wireshark capture if it’s not?

The answer is “both”. I have one OPC-UA server on my local machine I am discovering with 127.0.0.1, and another one on a Raspberry Pi I am discovering with the Pi’s address. I get the exact same result.

So at step 1 of setting up the connection you’re also putting in “opc.tcp://127.0.0.1:4840”?

Okay, can you turn the logger level you find searching for the “ClientManager” logger to TRACE and then edit/save the connection and upload the logs?

https://docs.inductiveautomation.com/display/DOC80/Troubleshooting+Guides

I will try do do that. However, something different (still not successful) has happened, which I will explain in case this has an impact.

On the CODESYS side, I had generated an “OPC UA” certificate. There was another certificate listed as “Encrypted Communications”, which I had not generated. I have now done so, and I am getting three possible enpoints listed, one with “None/None” as before, and two more with “Sign” and “Sign and Encrypt”. I have tried all three, still with no result.

I am trying to save the logs and get a 4Mb file even though I have filtered for ClientManager. Is that normal? Is there a way to save only a subset of the entries?

Also, is there a way to open the log (.idb) files to know what it is exactly I would be sending?

The idb file is a sqlite db. It’s easier for you to open the wrapper.log files in $IGNITION_INSTALL_DIR/logs.

You can send either, don’t worry about the size.

I have attached the lines from the log that correspond to my last attempt. Let me know if this is what you were after.

wrapper.txt (5.0 KB)

I don’t know what’s wrong yet, there’s not enough logging there to figure it out.

I may need to add some additional logging that will show up in a nightly build to figure this out.

One more bit of information : when I installed Ignition 8, I restored a backup from Ignition 7, in which there was an OPC-UA connection already configured with the local CODESYS SoftPLC. It worked until I either modified it or deleted and re-created it (I do not remember which).

One question : is the use of certificates really mandatory as the migration guide seems to indicate when connecting to an OPC-UA server? If so, does it make sense that I can select the “none/none” option to try to connect? I know too little about the use of certificate, and I do not know if the “none/none” option means “no certificate” or something different.

You don’t need certificates for the None/None endpoints. They’re not an issue at this stage.

Have you tried creating a brand new connection to this server yet?

Yes, I have started a new connection from scratch several times.

If you want to try a UA module with more logging you can download it here.

You’ll just leave that same logger on DEBUG, do an edit/save, and send me the logs again.

Please see attached file. The log is more verbose, but my untrained eye is not seeing anything that seems to point to the issue.

I noticed that in the OPC Connection status, the error message (which does not show in the log) is now different :

UaException: status=Bad_ConnectionRejected, message=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: /127.0.0.1:4840
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: /127.0.0.1:4840

I cannot tell when/why this changed.

I forgot to actually attached the file… Here it is.

wrapper.log_debug.txt (4.0 KB)

This means you can’t open a TCP connection to the server now… make sure it’s running and if it’s not try restarting it. There’s nothing to troubleshoot on the Ignition side if you’re getting a connection refused like this.

It might be because you didn’t specify a port at the initial discovery step. This logging is reporting your discovery URL as “opc.tcp://127.0.0.1” and it should be “opc.tcp://127.0.0.1:4840”.

You are both right and wrong. You are right, because my server probably was stopped (it is a time-limited demo).

But you are not right about not specifying the port, because, guess what, once I started the server it actually connected. I assume the right port is used automatically.

I created a second connection to the same server, which I tried to make identical, and I have not yet been able to get it to connect.

So basically, I have one “magic” connection that now works, but I cannot replicate this unexpected success.

I have been able to replicate the working connection.

I went to the “advanced configuration” for the endpoint, I specified “opc.tcp://127.0.0.1” as the discovery address (no port), I left the “Endpoint URL” field blank (very important, if I put “opc.tcp://127.0.0.1” it does not work). Last two fields set to “non”. Then it works.