I’m looking for a way to mirror tag values between two Ignition Gateways without having to use Gateway Event Tag Change scripts.
My setup is roughly as follows:
Gateway 1 is connected to PLC 1.
PLC 1 has 10 tags representing the ON/OFF state of 10 part-present sensors.
Gateway 2 is connected to PLC 2.
The two Ignition Gateways are connected through the Gateway Network.
From Gateway 2, I can access the 10 sensor tags from Gateway 1.
I then want Gateway 2 to act as a middleman and write those 10 values into corresponding tags in PLC 2.
Currently, I am accomplishing this with Gateway Event scripts using Tag Change events. Whenever one of the 10 sensor tags changes, I run a simple system.tag.writeAsync() to write the values into the corresponding PLC tags on Gateway 2.
What I would like to know is whether Ignition has a native tag configuration/binding mechanism that can accomplish this without needing to run a Tag Change script.
Ideally, I would like something along the lines of:
Gateway 1 Tag → Remote Tag Provider/Binding → Gateway 2 Tag → PLC 2
where the value is automatically kept synchronized whenever the source tag changes.
I’m specifically interested in whether this can be done using things such as Remote Tag Providers, tag bindings, UDTs, or another native Ignition feature, rather than having to maintain a Gateway Event script for each tag.
The reason I’m trying to avoid the scripts is that I may have more of these signals in the future, and I’d prefer a configuration-based solution that automatically maintains the synchronization.
Has anyone implemented something similar across two Gateways connected through the Gateway Network?
Disclaimer: This is a really bad idea--Ignition isn't really designed to do this. PLCs should be using native technology, like producer/consumer tags in Rockwell, to do this kind of process synchronization. So your SCADA system stays in supervision, not directly in the control loops.
If you must, consider using something like my Integration Toolkit's Bulk Script Action to minimize the configuration effort. (Presumably where the bulk script writes to same-named tags in a remote tag provider.)
Thank you for the suggestion and warning I was not aware.
We do try to keep all sorts of control away from our ignition systems as much as we can. In this example, the reason we resorted to having to do it this way is because a PLC to PLC connection was not able to be established, so we used what was already in place in order to make this communication work.
Reading through the documentation of this toolkit, it sounds like it's exactly what i need, specifically the Republish Action. I'd like to give it a try.
How can i integrate this toolkit module into my gateway?
I did not see instructions on how to acquire it or install it.
tagA value change script that writes its value into tagB
scheduled gateway event with a script that runs periodically that has your list of tags and does a compare against the two values and if there's a difference rewrites tagA into tagB.
Both are necessary because if deviceB comms go down momentarily and the tagB write fails then the value change script won't fire again so tagB will not necessarily equal tagA. So the backup re-check is necessary. Which is also why you shouldn't rely on this for critical values.
If you have the SQL bridge module you could also do this in a transaction group I believe but I haven't gone that route. Not sure about efficiency with that route either.
It is a free (but not open source) 3rd party module. Found through the IA Showcase or directly from my website. I suggest you start here (read the whole thing):
This may also help:
Probably not, as it targets OPC items in the same gateway as the source tag--it cannot work across the gateway network. But a bulk script can assemble a bulk write to tags in a Remote Tag Provider.
The factory where we integrated our solution has separate networks and this machine in specific is technically not allowed to talk to devices outside its network (because IT said so). It was not our decision to make and this was the way they determined it needed to be done.
We are integrators, we don't have much say in how a company's IT determines security and network communications.
Best we can do is guide and make suggestions, but it's ultimately what the customer wants to do.
Okay, so they must have a managed connection of some sort that allows the gateways to talk across the networks but not the PLCs.
I'd make them aware that if the Ignition server for machine 1 is shut down for whatever reason, even if the other machine is running, this data would no longer make it to the second machine if you have to do it this way.
This is the kind of decision path that gives IT a bad name. They've chosen to connect production systems to each other across networks using a very generic technology with opaque traffic instead of using the appropriate vendor-specific protocols (that show up clearly in wireshark and packet captures). Simply because they don't want to properly configure forwarding of the specific, transparent, well-understood protocol. And they've made two production systems intimately dependent on a 3rd system with totally non-PLC non-realtime performance and uptime behaviors. They ought to be fired for making you circumvent their network isolation in this manner. IMNSHO.
I was not aware.