You can access live OPC data
in Linux, and write to an OPC server or client from any Linux
program, using the OPC DataHub in Windows and the Cascade DataHub in Linux.
The two DataHubs mirror data across a network connection or the
Internet just like OPC
Tunnelling.
![[Note]](images/note.gif) | The OPC DataHub tunnelling connection is sometimes referred to as
a mirroring connection. Mirroring means that
the data and any updates to that data on one DataHub are exactly
mirrored across the network onto the other DataHub, and
vice-versa. For all practical purposes, tunnelling and mirroring
are identical. People working with OPC tend to use the term
"tunnelling" while people from other backgrounds often say
"mirroring". So Cogent uses "tunnelling" for the OPC DataHub, and
"mirroring" for other Cogent products. |
There are two steps to set this up:
11.1. Configuring the OPC DataHub in Windows
- Connect the DataHub to the OPC server or the OPC
client, if you haven't already done so. Please refer to
Section 1.3, “Connect to an OPC server” or Section 1.4, “Connect from an OPC client” for instructions
on how to do this.
Configure the DataHub for tunnelling. To do this,
you must decide which DataHub (on Windows or on Linux) will be
the master, and which the slave. The master DataHub receives
the initial request from a slave to establish the
connection, initially or after a network break. For this
reason, we suggest that the computer with the most expected
up time be the master. This could be either the Windows or
the Linux machine, depending on your individual
circumstances.
![[Important]](images/important.gif) | If the Windows computer is going
to act as the master, follow the first procedure.
Otherwise, follow the second procedure. |
Configure the OPC DataHub as tunnelling master
In the Properties window,
select
Tunnel/Mirror 
.
In the
Tunnelling Master
section, you can configure plain-text or secure
tunnelling. Ensure that at least one of these is
checked. If you want to change any of the other
defaults, please refer to
Section 19.3, “Tunnel/Mirror” for more
information.
![[Note]](images/note.gif) | To optimize
throughput, un-check the Try to send data
even if it is known to be superseded
option. This will allow the DataHub to drop stale values
for points which have already changed before the
client has been notified of the original change. The
latest value will always be transmitted. |
- Click OK to close the
Properties window.
Configure the OPC DataHub as tunnelling slave

In the Properties window, select
Tunnel/Mirror

.
- Check the box Act as a tunnelling/mirror slave to
these masters.
Click the Add Master... button to
assign a master to this slave. The
Tunnel/Mirror Master
Configuration window will open:
Type in the following information:
![[Note]](images/note.gif) | There is a DataHub running on Cogent's server that
you can connect to for testing. Here are the parameters you
will need to enter for it: - Primary Host: developers.cogentrts.com
- Port:
4600
- Local data domain: test
- Remote data domain: test
|
You now have several options for the mirrored
connection.
Data Flow Direction: lets you determine which way the data flows. The
default is bi-directional data flow between slave and master,
but you can effectively set up a read-only or write-only
connection by choosing that respective option.
![[Note]](images/note.gif) | To optimize throughput, check the
Read-only: Receive data from the Master, but do not
send option. Only do this if you actually want a
read-only connection. If you do not require read-write access,
a read-only tunnel will be faster. |
- When the connection is
initiated: determines how the values
from the points are assigned when the slave first connects to
the master. There three possibilities: the slave gets all
values from the master, the slave sends all its values to the
master, or the master and slave synchronize their data sets,
point by point, according to the most recent value of each
point (the default).
When the connection is
lost: determines where to display the
data quality as "Not Connected"—on the master, on the slave,
or neither.
![[Note]](images/note.gif) | If you have configured When the
connection is initiated as Synchronize
based on time stamp (see above), then this option
must be set to Do not modify the data quality here
or on the Master to get correct data
synchronization. |
Connection Properties gives you these options:
- Replace incoming timestamp... lets you
use local time on timestamps. This is useful if the source
of the data either does not generate time stamps, or you do
not trust the clock on the data source.
Transmit point changes in binary gives users of x86 CPUs a way to speed up the data
transfer rate. Selecting this option can improve maximum
throughput by up to 50%.
- Target is a Cogent Embedded Toolkit server allows this slave to connect to an Embedded Toolkit
server rather than to another DataHub.
- Heartbeat sends a
heartbeat message to the master every number of milliseconds
specified here, to verify that the connection is up.
Timeout specifies
the timeout period for the heartbeat. If the slave DataHub
doesn't receive a response from the master within this
timeout, it drops the connection. You must set the timeout
time at least twice the heartbeat time.
- Retry specifies a
number of milliseconds to wait before attempting to
reconnect a broken connection.
- Click OK to close the
Tunnel/Mirror Master window. The fields
in the Tunnelling Slave table
of the Properties Window should now be filled
in.
- Click the Apply button in the
Properties Window. If the master DataHub is running, this DataHub
should establish the tunnelling connection, and the
Status should display
Connected. You can view the data with the
Data Browser, or view
the connection with the Connection Viewer.
Now you are ready to configure the Cascade DataHub on Linux.