We were wondering if it was possible to have a central OPC Gateway installed on a server that the Ignition Service, installed on another server could communicate through. We were also wondering if such a thing is even recommended. The reason we were curious about this is that we have been having some trouble with maxing the communication capabilities of our older PLC models. We have Ignition providing HMIs and use OPCofficelink for data sampling. Both are communicating through their own packaged OPC-UA Servers. We are theorizing we could reduce some of the stress on the PLCs if we were able to link these services through a central OPC Gateway. Thanks for sharing your Knowledge.
Sure, there shouldn’t be any problem with this, and I’d even recommend this as an approach to reduce comms load on your PLCs as you theorized.
1 Like
Thanks for the reply Kevin. So now for the next question. Do we need to use a 3rd party OPC-UA server or can we install the Ignition OPC-UA server on a separate box from the Ignition Service?
You could do either.
If you used Ignition, you would have just the Ignition gateway and the OPC UA module installed. The gateway is what you’re thinking of as the service. It’s perfectly reasonable to run the gateway + OPC UA module on a central server and the gateway + all the modules on another server and add an OPC UA connection to the central server.
I think the biggest thing to worry about is that your central UA server needs to support all the kinds of devices you want to talk to…
1 Like
so we would have to license both servers? or just the one running the paid modules?
Oh! and will the Ignition OPC-UA server connect to our sampling software?
Both would need licenses, but the costs should reflect only what’s running on each.
I believe the gateway itself is basically free, the OPC UA module is technically free, but driver modules are not free. So basically you’d have a license for whatever drivers you need on the central server.
Then on the “full” Ignition server you’d have a license that had everything else you were using, which would no longer include drivers since you should now only need them on the central server.
You’ll have to get the final word on pricing and licensing your sales rep.
1 Like
Oh! and will the Ignition OPC-UA server connect to our sampling software?
No idea, you tell me. It sounded like your sampling software had its own OPC UA server, in which case the question would be can you point your sampling server at 3rd party UA server instead of its own? And does Ignition have drivers for the devices that server was talking to?
1 Like
right I see we would need to split up our services and get new licenses to reflect for each server.
So basically before we make this change we should see if we can route OPCofficelink through our current Ignition server?
That would be a good start.
You can test this entire setup before you attempted to work out the licensing because you can run as many Ignition’s as you want under the 2 hour resettable trial.
1 Like
Thanks for all the help Kevin really great info time to go test some environments
@erfritts if your existing Ignition gateway server is not overloaded, you could just point OPCOfficeLink to the existing Ignition OPS server. This is probably more robust and easier to maintain than introducing a third server.
I suggested the same thing and my boss immediately gave me the single point of failure speech. Which I saw his point sometimes we want to reboot HMI services and not data sampling and vice versa. We have a fairly robust VM environment so spooling up servers a plenty is very little hassle.
1 Like
There are trade-offs between single point of failure and increased complexity. If your Ignition gateway is mission critical, you might want to keep the connection to real-time data as direct as possible.
1 Like