Here are the known limitations based on its operational design:
1. Strictly One-Way Data Flow (No Device Writes)
By design, the module provides a one-way mirror from the Production (PROD) gateway to the Development (DEV) gateway. Because the DEV server relies on a "fake driver," any write commands (like a developer trying to toggle a pump or change a setpoint on the DEV screen) will only update the tag on the isolated DEV server. You cannot write data back to the physical PLC from the DEV environment through this module.
This is the objective of this solution
2. Limited to Raw OPC Data
The module is strictly built to replicate data at the OPC-Tag level (this includes native device drivers and third-party OPC-UA sources).
-
Limitation: It does not automatically replicate standard Ignition Memory Tags, Query Tags, or complex Expression Tags. It is designed to mirror the raw machine data. To duplicate your calculated tags or database queries, you still need to use traditional Ignition tools (like tag exports or EAM).
This is intentional
3. Requires a Multi-Gateway Architecture
The solution cannot be used to duplicate a device internally on a single standalone server. It inherently requires a Gateway-to-Gateway setup:
-
The "Tag Mirroring Module" must be installed on the source gateway.
-
The "Device Mirroring Module" must be installed on the destination gateway.
4. Network and Performance Dependency
Because the real-time tag updates are streamed via a webservice over the destination gateway's HTTP/HTTPS port, the quality of the DEV environment is entirely dependent on the network link between the two servers. If there is high latency, bandwidth throttling, or network drops between the PROD and DEV servers, the "real-time" data on the DEV server will lag or drop out, even if the physical PLC is communicating perfectly with PROD.
This solution has been tested with 100+ device drivers, representing 300k OPC tags.
5. Risk of Driver Name Collisions
Because the module is designed to seamlessly replicate the production environment, it automatically generates a "fake driver" on the destination (DEV) gateway using the exact same name as the device on the source (PROD) gateway.
-
The Limitation: If a real PLC connection or an existing driver already exists on the destination gateway with that exact same name, a collision will occur. Having a real driver and an automatically created fake driver trying to operate under the identical name simultaneously will cause conflicts and unpredictable behavior on the destination gateway. To prevent this, administrators must ensure that the DEV environment is clear of any local device names that might overlap with the devices being actively mirrored from PROD.