Chapter 12. OPC to QNX

Table of Contents

12.1. Configuring the OPC DataHub in Windows
12.2. Configuring the Cascade DataHub on QNX

You can access live OPC data in QNX 4 or QNX 6, and write to an OPC server or client from any QNX 4 or QNX 6 program, using the OPC DataHub in Windows and the Cascade DataHub in QNX. The two DataHubs mirror data across a network connection or the Internet just like OPC Tunnellling.

[Note]

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:

  1. Configure the OPC DataHub on the Windows machine.
  2. Configure the Cascade DataHub on the QNX machine.

12.1. Configuring the OPC DataHub in Windows

  1. 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.
  2. Configure the OPC DataHub for tunnelling. To do this, you must decide which DataHub (on Windows or on QNX) will be the master, and which the slave. The master DataHub receives the initial request from a slave to establish the tunnelling 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 QNX machine, depending on your individual circumstances.
    [Important]

    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

    1. Right click on the OPC DataHub system-tray icon and choose Properties.
    2. In the Properties window, select Tunnel/Mirror .
    3. 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]

      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.

    4. Click OK to close the Properties window.

    Configure the OPC DataHub as tunnelling slave

    1. Right click on the OPC DataHub system-tray icon and choose Properties.
    2. In the Properties window, select Tunnel/Mirror .
    3. Check the box Act as a tunnelling/mirror slave to these masters.
    4. Click the Add Master... button to assign a master to this slave. The Tunnel/Mirror Master Configuration window will open:
    5. Type in the following information:

        Primary Host: the name or IP address of the computer running the tunnelling master DataHub.

        Port: the port number or service name for this host. You should use default port number (4600) unless you have changed the entry in the master DataHub.

        Secondary Host: gives you the option to have an alternate host and service/port number. On startup or after a network break, the DataHub will search first for the primary host, then for the secondary host, alternating between primary and secondary until a connection is made. If no secondary host is specified, the connection will be attempted on the primary host only.

        Local data domain: The data domain in which you plan to receive data.

        Remote data domain: the master DataHub data domain from which you plan to receive data. Point names will be mapped from the remote data domain (on the master DataHub) into the local data domain (on this DataHub), and vice versa.

        [Note]

        Unless you have a good reason for making these different, we recommend using the same data domain name on both DataHubs for the sake of simplicity.

      [Note]

      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

    6. You now have several options for the mirrored connection.
      1. 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]

        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.

      2. 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).
      3. When the connection is lost: determines where to display the data quality as "Not Connected"—on the master, on the slave, or neither.
        [Note]

        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.

      4. 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.

          [Note]

          To optimize this setting for slow networks, please refer to Section 18.2, “Tunnel/Mirror (TCP) Connections for Slow Networks”.

          Retry specifies a number of milliseconds to wait before attempting to reconnect a broken connection.

    7. 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.
    8. 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 QNX.