OPC Mirror Usage Tips

OPC Mirror maps data from one control system to another control system through OPC, enabling an operator in one control system to view data of another control system. However; there are some limitations. Note the following when using OPC Mirror:

The tracing messages in MirrorDiagnostics are for debugging. If used indiscriminately, they may significantly decrease the MirrorClient's performance. Once you have finished debugging; you are sure that the configuration is correct; and, you are ready to run OPC Mirror online; you should disable tracing.
If you map two data items of different data types, you may get unexpected values at the destination. OPC MirrorClient uses Microsoft Win32 API VariantChangeType() to coerce item value from source type to destination type. For example, a negative signed integer would be converted to a huge unsigned integer.
OPC Mirror will not write values to the destination if there is no updating from the source or if the updating value does not have good quality. So, if a value at the destination does not change for a long time, either the value is not changing at the source or the source OPC server is not sending good data to OPC Mirror.
For a one-way pipe, only values from the source are written to the destination. If you change values in the destination, they will not be reflected in the source. However, if you have Automatic Refresh turned on, the value will be refreshed. Therefore, if you want to keep the changed value, turn Automatic Refresh off.
For a two-way pipe, if a value is changed at one end, OPC Mirror will write it to the other end. This will generate an updating message from this other end (second end) back to OPC Mirror. OPC Mirror does not pass the same value back to the original end. However, if the value is changed simultaneously at both ends, a race condition will occur, and the final value on both ends will be undetermined. Depending on the nature of the race condition, there may be many messages bouncing back and forth before one value is settled on at both ends.
Note

When two-way pipes are used DISABLE those pipes through the OPC Mirror Diagnostics application BEFORE downloading modules or items that are not on the initial data node to prevent an unintended initial value being propagated back to the initial data node of the pipe.
Be careful when mapping status data like alarm, mode, quality, and so on, between two different systems. OPC Mirror passes the numerical value through without knowing the semantics of the value. The same value may have different meanings on different systems. Use the new scaling function to relate the value in one system to the other system.
By default, OPC Mirror does not pass status values of Uncertain or Bad (that is, <128). To enable OPC Mirror to pass these values, you must create an environment variable named mirror_ValuePassing with the value a.
OPC Mirror has a threshold of 0.01. If the source value is greater than 0.01 of the destination value, Mirror writes to the destination. Otherwise Mirror will not change the destination. For example, changing the source value from 0.111 to 0.12 will not affect the destination. However, if the source value changes from 0.111 to 0.1211, the destination will be modified. The reason behind this is to avoid sending data repeatedly in a bidirectional pipe when the servers at two ends have different floating number precision. The workaround is to amplify the source value by N times, then at the destination, reduce it back by N times.
OPC Mirror only maps data points of different systems. It does not create data points in these systems. Before you map a data point from the source system, make sure that you have already created a data point in the destination system.
If the destination system is a DeltaV system, Emerson recommends that the data point be assigned to the workstation instead of the controller. When the data point is assigned to the workstation, the request/response exception reporting mechanism inherent in the DeltaV system takes care of communicating the point throughout the DeltaV system in the most efficient mechanism possible. This prevents unnecessary traffic in the DeltaV network and eases the controller's workload.
When installing or upgrading DeltaV software, you should shut down all connected OPC Mirror Clients, or disconnect the network cable between OPC Mirror Client and the DeltaV system. Otherwise OPC Mirror Client may attempt to reconnect to the DeltaV System during the installation and may cause undesirable results.
When OPC Mirror adds an item to the DeltaV OPC Server, the server attempts to determine the data type of this item. If the date type cannot be determined, it will default to float type. If the OPC Mirror then attempts to write to the item with a value that cannot be converted to a float type, the write operation will fail. To prevent this, it is recommended that when configuring an alarm pipe, numeric values be used for alarm values. When the item for an alarm pipe defaults to float type due to the server not being able to determine the data type, the OPC Mirror might not be able to write an alarm value to the item depending on the configured alarm values.
OPC Mirror can write an alarm value to the item if the value can be converted to float type, such as 1, 100, and so on.
OPC Mirror cannot write alarm value to the item if the value cannot be converted to float type, such as Alarm On, Write Alarm, and so on.