No matching endpoints found

Ignition
1

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
2

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?

3

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.

4

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

5

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.

6

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?

7

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.

8

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)

9

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.

10

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).

11

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.

12

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?

13

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

14

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.

15

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.

16

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

wrapper.log_debug.txt (4.0 KB)

17

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.

18

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”.

19

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.

20

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.