Ignition and OPCUA WAGO (PFC200)

Hello,

We’re trying to connect Ignition to a WAGO PLC.

As maybe you know, wago and his software eCockpit provide his own OPCUA server (inside the PLC) so we want to use it.

In youtube there is the following tutorial but doesn’t work:


We’ve tried with ignition 8 and ignition 7.9.

Anybody have a clue about it?

Thanks in advance.

You’ll have to provide more details about what you’ve done so far and what isn’t working.

Kevin,

We think the problem is on the PLC, because we’ve tried to do the same with UAExpert (opcua client) and doesn’t work either.

But talking about ignition, the error is the following:

UaException: status=Bad_ConfigurationError, message=no matching endpoints found
	at com.inductiveautomation.ignition.gateway.opcua.client.ClientManager.initializeObject(ClientManager.kt:107)
	at com.inductiveautomation.ignition.gateway.opcua.client.ClientManager$initializeObject$1.invokeSuspend(ClientManager.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:238)
	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.3 (b2019080717)
Azul Systems, Inc. 11.0.3

Something strage is that the endpoint discovery works fine and find the OPC but the connection fail.

I don’t know if this is enough for the troubleshoting.

Thanks again.

Can you make a new connection and take screenshots at each stage of the discovery wizard?

Sure Kevin. Here it is:

Creating new OPC connection

OPC UA Type

Entering only the IP address, Ignition show this

Here are the security policy. Suggested by ignition again

The authentication fields were left empty

And finally the error

UaException: status=Bad_ConfigurationError, message=no matching endpoints found
	at com.inductiveautomation.ignition.gateway.opcua.client.ClientManager.initializeObject(ClientManager.kt:107)
	at com.inductiveautomation.ignition.gateway.opcua.client.ClientManager$initializeObject$1.invokeSuspend(ClientManager.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:238)
	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.3 (b2019080717)
Azul Systems, Inc. 11.0.3

If i do this but in ignition 7.9, the results are the same. If I’m explicit with the port in the OPC address the error is the same.

I think that’s all i have. Thanks againg for the help.

Thanks. I’m worried because the wizard has some known buggy behavior right now but I’m not sure if that’s what you’re running into. That you can’t connect in 7.9 or with UaExpert means it might not be the discovery wizard bug.

Can you get a Wireshark capture while going through this discovery process?

We use WAGO sometimes. Our instructions say to follow whats in the IA manual: I think this is the right one:
https://docs.inductiveautomation.com/display/DOC80/Connecting+to+Kepware+OPC+UA

but you need two changes:

  1. Discovery Port should be 4840 (So the string you put in for discovery should be: “opc.tcp://10.10.3.48:4840”
  2. Host Over Ride (I think under Advanced settings) needs to be PLC IP address (10.10.3.48)

-Caleb

1 Like

Hello friends,

I have news about this. We made it and here are the steps and diagnostics found:

1.- Wireshark capture
You asked for wireshark captures and here are attached. I can’t upload pcap files so here you have it in json style.
ws_capture_json_20190909.json (98.9 KB)
I’m not an expert with WS but I think that the key is that Ignition is sending or asking for transactions being explicit with ip address (in opc context is opc.tcp://10.10.3.48:4840) and the wago plc is responding with hostname address (opc.tcp://wago01-pfc200:4840).
As the test was made in a local network without DNS, the hostname can’t be resolved and the connection fail.

This was realized with the other software (UAExpert). Here you have some capture from the key aspects:



As you can see, despite of being explicit with IP address, the software change the IP bythe hostname because the response from the OPCUA, so changing back the hostname by the IP address UAExpert works fine.

2.- Host override option
The behavior of UAExpert was the same with Ignition 7.9. There we applied the override option in the advance section of adding an opc server. Doing this, ignition works fine with the OPC.

The problem with this solution is doesn’t work with ignition 8. There, the overrider option seems the do nothing. Maybe there is an issue.
image

3.- Hostname resolution
We can’t use or install a DNS, so we found this solution:
In windows, edit the file “X:\Windows\System32\drivers\etc\hosts” and add the mapped ip address like this


In out case, doing this, ignition could resolve the hostname and the OPC works fine.

Hope this can help you too. Thanks for all and greetings.

2 Likes

There’s a “Skip to Advanced Configuration” link when you set up the connection on 8.0. You can also get to it by re-configuring endpoints (More > Endpoint).

Set the discovery URL to: opc.tcp://10.10.3.48:4840
Set the endpoint URL to: opc.tcp://wago01-pfc200:4840

Then set the Host Override setting to 10.10.3.48.

Wow, this works too.

But I don’t understand why this configuration works and this one don’t:

discovery URL: opc.tcp://10.10.3.48:4840
endpoint URL: opc.tcp://10.10.3.48:4840

Host Override: 10.10.3.48

It’s like if you use the ip address, the override do nothing, but with hostnames it does.

Well, this solution doesn’t need external configurations and anything so i thinks it siuts best.

Because the server is (mis)configured to only have endpoint URLs that have the hostname.

So when you have the connection in Ignition configured with the IP address in the endpoint URL and Ignition connects it doesn’t find a match and gives you the Bad_ConfigurationError you saw.

That it ended up configured this way is a bug in the discovery wizard that should be fixed in 8.0.5.