A bit of sanity check here. We already have existing OSI PI historian so my thinking was to use a new install of Ignition with OPC COMM DA module to send data to PI.
Now I look at the module closely I realize that the module is designed as a client only and not as a server, am I correct in that interpretation?
Now follow up on that, what's the best option to send data from Ignition to OSI PI? With OPC UA Adapter or Connector?
You aren't really "sending data to PI" so much as PI is "collecting data from Ignition". This distinction can matter if you end up needing to talk to others or support engineers about this. It helps them figure out what's going on.
I wholeheartedly agree with this statement. We use both versions 1.3 and 2.X of the "PI Connector for OPC UA"
1.3 is my preferred version. It's simple and straightforward. You install it and point it at Ignition and your PI server. You then can manage a csv of: tagname from ignition, mapped tag in pi (it will auto create for you), and the poll rate.
2.X is horrible. It's harder to setup and overengineered. They broke the functionality up into multiple programs.
Now you have the connector, a "relay" (which i think is just used to get around firewalls? not sure, seems pointless), and the connector management software.
It also requires AF to be installed and configured because it wants to make an AF assets for all of the data...
One "feature" that would draw you to this version is that it can scan the OPC UA server and create tags for you automatically that match some filters you setup. This "feature" barely works though.
It's supposed to be able to detect changes in the OPC UA server it's reading from but I have never gotten that to successfully work. I usually spend an hour + every time I want to have it browse Ignition again, because it constantly errors out.
One thing to note is that both of the connectors sometimes stop updating the pi tags and need to be restarted.
TLDR: if you go down this route, use 1.3. It's way less of a headache.
Ok, thanks for the feedback. I also started a case with OSI and they told me that "UA Adapter" is the newer version of "Connector" so I should use that if there isn't already a Connector interface in place.
I had many battles with OPC DA but it's something I know. Should be interesting.
Looks like the "Connector" has been updated more recently than the "Adapter". I'll look into the adapters. Maybe they work better than the connectors do.
Seems like they're all configured via a rest API which is cool because you can call those endpoints from Ignition to add new tags
Well, I'm trying out the adapter after viewing the couple videos on YT. Took couple of try and restarting the Adapter service to even get the certificate to show up. So I got those trusted on both side. Now I'm just getting a generic "Connection to the OPC Server timed out" message This is a screenshot of the Ignition log:
Can you copy/paste the full error and stack trace? Aside from screenshots of text being generally unacceptable, some important information is being cut off on the right side.
Sorry, had to sneaker this from an islanded system.
org.eclipse.milo.opcua.stack.core.UaException: no matching endpoint found: transportProfile=TCP_UASC_UABINARY, endpointUrl=opc.tcp://localhost:62541/, securityPolicy=None, securityMode=None
at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.lambda$openSecureChannel$3(UascServerAsymmetricHandler.java:410)
at java.base/java.util.Optional.orElseThrow(Unknown Source)
at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.openSecureChannel(UascServerAsymmetricHandler.java:400)
at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerAsymmetricHandler.lambda$sendOpenSecureChannelResponse$1(UascServerAsymmetricHandler.java:311)
at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$encode$0(SerializationQueue.java:59)
at org.eclipse.milo.opcua.stack.core.util.TaskQueue$TaskWrapper.run(TaskQueue.java:273)
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)
no matching endpoint found: transportProfile=TCP_UASC_UABINARY, endpointUrl=opc.tcp://localhost:62541/, securityPolicy=None, securityMode=None
This client is trying to connect to the endpoint at opc.tcp://localhost:62541/ without security.
If you haven't modified Ignition's OPC UA server settings to allow the "None" security policy, then unsecured connections are not allowed.
You might be able to point this client at opc.tcp://localhost:62541/discovery and see if it can connect, but I'm guessing this is one of the broken client implementations that ignores the endpoint URL in endpoints returned during discovery, and will only be able to connect once you allow unsecured connections.
Ok, I double checked the client (PI OPC UA Adapter) and secureconnection is set to true. It seems other people are having the same issue so I'll see what OSI Tech Support can do. I shall update this thread when I get it working.
Got it working, at first I just changed Ignition policy to None, restarted the gateway then it worked without change the endpoint to add /discovery at the end.
After that I went to OSI's site and dig around some more and it turns out they do have a KB buried there about this issue. It's titled
" OPC UA Adapter - Connecting to a secure endpoint with a separate URL for an insecure endpoint"
It doesn't say it explicitly but implied that it initially connect to the insecure one then switch to secure one if available so I re-enabled security on the gateway and added /discovery, restarted gateway and it worked.
You're probably looking for the Ignition tags from your Tag Providers. Make sure the "Expose Tags" option is on in the Ignition OPC UA server settings.
I don't know what kind of configuration the PI adapter requires, though.