v8.1
A client of mine has Ignition connected to a third party OPC (PI Historian) both to historize Ignition tags, and to pass values from a cloud service into PLCs in the Ignition system. Due to a combination of licensing and company policy, they don’t want the PI node to write data or bridge tags.
Since there’s no bridging tool in Ignition’s OPC server as far as I know, is my best option to use tag event scripts? I’m thinking we read an OPC tag from PI and on value change perform either system.opc.writeValue() (writing directly to the PLC) or system.tag.writeBlocking() (using another PLC OPC tag as the intermediary). The data flow will be unidirectional (PI → Ignition → PLC).
Is it as simple as that? Any pitfalls besides the obvious (only write when quality is good etc)? My gateway has redundancy, and the PI node we’re connecting to will likely be redundant as well – might any of that cause issues?
Thanks!
Sounds fine, the only hang up I have is that one part of your data flow direction sounds backwards. I pretty much only hear of people using PI as an OPC Client to connect to Ignition’s OPC UA server and historize data - I didn’t even know they had an OPC server. If you’re confident they do then carry on.
1 Like
Great, thanks!
I’m not very familiar with the PI side (client has experts that are handling it), but it’s not the first time they’ve had a Cloud → PI → SCADA/PLC setup like this. So apparently it’s possible somehow!
Another option here, if you have SQL Bridge, is to use Transaction Groups. We’ve used them for OPC-to-OPC tag mapping and it’s worked well.
This helps eliminate tag event scripting across many tags. If you only have a handful of tags it may not be worth it, but easy to setup and manage.
1 Like
I actually meant to come back and update this post with that exact solution! Here's a primer from the docs:
Here's how I implemented it for posterity:
This had a number of benefits for us, particularly over our original scripting solution:
- One transaction group per tag mapping to keep things organized (more than a few mappings in one group became cumbersome in our opinion)
- Per-tag write alarms. This would alert us to issues on the Ignition tag side (e.g. someone renames the destination tag name, tag goes bad quality, etc).
- Bad quality alarms on external tags (third-party OPC). Alerts us to tag name changes/OPC server issues external to Ignition.
This can also be setup with direct OPC references, bypassing Ignition tags altogether - this didn't work for our situation because of our gateway architecture. Our machine with third party OPC access did not have direct device access. Instead, it used remote tag gateways, so we were reliant on Ignition tags within the transaction group.
2 Likes
