Hi All, Thanks in advance for reading my post.
We have an issue with connecting PI OPC UA connector to Ignition’s built-in OPC UA Server. Here is a bit detail of the setup
- Two VMs are setup in AWS, one for ignition and another for PI connector, relay and DCM.
- Upon initial connection, i can see ignition’s certificate being located in PI connector’s folders and the Connector’s certificate showing up in Ignition Server.
- Then i trusted certificates on both sides.
- The next error message is where the mystery happens. Even though i setup the endpoint url in pi connector to be the none discovery one with signandencrypt:Basic256Sha256, Ignition see the requested endpoint being using none:none.
Wondering if anyone has seen this before.
It looks like PI is trying to connect without security initially, presumably to do discovery.
Try configuring the Ignition endpoint URL in pi with “/discovery” at the end, i.e.
Thanks for the reply. I tried that and the same error appears but with the discovery url, plus security model = signandencrypt, security policy = Basic256Sha256. It looks like ignition is interpreting whatever the pi connector requesting in the reverse order.
The initial startup log shows ignition binds ua server binds to the discovery url with none none and the other endpoint with the correct security model / policy.
Its a bit stuck as the config were both right from each other, but somehow the interpretation on the ignition end seems to be different to that configured in PI UA Connector.
This may be a bug in the OSI PI client. I’ve seen this with other clients as well. You should report this problem to OSI, but as a workaround if you enable the “None” security policy in Ignition my guess is PI will be able to connect.
Set the “Security Policies” setting to
None, Basic256Sha256 and then restart the Ignition gateway. Ignition's OPC UA Server - Ignition User Manual 8.1 - Ignition Documentation
Unfortunately, None is not an option. The server will be used for communication over the network so None is not allowed. Was there any other workaround?
I don’t know if there’s any alternative then.
Get in touch with OSI support and impress upon them they need to fix this.
Thanks Kevin, will try that.