10.5. Start-up sequence
Cascade Connect is initiated from Windows when the user clicks on a Cascade Connect icon linked to a specific configuration file. This file specifies all of the available parameters, informing the Cascade Connect program which Windows client should be started and which computer on the network to connect to as a data server.
Here is the start-up sequence:
Cascade Connect starts the appropriate Windows client program.
Cascade Connect then enters a loop in which it periodically attempts to establish a DDE conversation with the Windows client program.
Cascade Connect then contacts the inetd task running on the data server that is specified in the configuration file.
The data server's inetd task establishes a TCP/IP socket connection to Cascade Connect and then starts the Connect Server.
When the Connect Server starts, it checks for a valid license. If a license is not found, the Connect Server will not start and an error message will be displayed on the Cascade Connect runtime window in the Windows computer.
Cascade Connect then configures the Connect Server by sending the following information (which it reads from the configuration file).
The last two items are specific to the Cascade DataHub.
The name that Cascade Connect will declare for itself on the data server.
The name of the default Cascade DataHub domain. (This is used to indicate which Cascade DataHub is to be the main source of data when more than one datahub is specified in the Cascade Connect configuration).
A request to one or more Cascade DataHub to register the Connect Server for exceptions. (This is used to inform each Cascade DataHub that the Connect Server would like to receive all new data values, as and when they occur).
For each Cascade DataHub that the Connect Server attempts to connect to, it will send a message (stating db_datahub_name_up = 1 or 0) to Cascade Connect (1 meaning connected, 0 meaning not connected). This message is then sent to the Windows client program and can be used to remotely monitor the status of the Cascade DataHub from Windows.
Cascade Connect then sends a tcp_link_up = 1 message to the Windows client indicating that the TCP/IP has been established. If the link is ever broken, Cascade Connect sends a tcp_link_up = 0 message to the Windows client.
Cascade Connect minimizes itself (unless you have configured the program to show you debug information).
Each Cascade DataHub sends an update of all of its data point values back to the Connect Server, which sends the information to Windows.
10.5.1. An example start-up
The following example illustrates how Cascade Connect works. The Windows client program is an InTouch application that has been designed to show data generated by a QNX application, which sends data to the Cascade DataHub. The QNX application has also registered for exceptions with the Cascade DataHub so that it will receive new data values from the datahub whenever they change. Some of these new data points are sent from the InTouch application in Windows and transmitted to the Cascade DataHub by Cascade Connect (as shown here):
10.5.1.1. Some assumptions we have made:
The InTouch application contains an internal datahub with 10 data points (InTouch calls data points tags so we will use that expression).
5 of the InTouch tags are read/write points and are defined as DDE tags in the InTouch datahub. These DDE tags are used to send data back to the QNX application. The remaining 5 InTouch tags are read-only tags that display the value of data sent from the QNX application. These read-only tags do not have to be DDE tags and so are defined as Memory tags in the InTouch internal datahub.
The Cascade DataHub receives 20 data points from the QNX application. These points change on a regular basis.
And finally we assume that the QNX application and the Cascade DataHub are already running and the Cascade DataHub contains the 20 most recent 'live' data points from the QNX application.
10.5.1.2. When Cascade Connect starts:
Cascade Connect starts the InTouch application and enters into a loop in which it repeatedly tries to establish a DDE conversation with InTouch (until the conversation is established).
Cascade Connect then contacts the inetd task on the data server.
The data server's inetd task checks for a valid license, then establishes a socket connection with the Cascade Connect, and starts the Connect Server.
Cascade Connect configures the Connect Server with a name, default Cascade DataHub domain setting, and a datahub registration request (so that the Cascade DataHub will transmit all new data exceptions to the Connect Server).
Cascade Connect sends a tcp_link_up = 1 message to the InTouch internal datahub and then minimizes itself.
When the connection to the Cascade DataHub has been established, the Connect Server sends a db_datahub_name_up = 1 message to Cascade Connect, which passes it on to the InTouch client.
The Cascade DataHub sends all 20 data points to the Connect Server, which passes them to Cascade Connect, which in turn passes them on to the InTouch internal database.
The InTouch database only wants to know about the 10 points that are used in the application so it refuses the 10 data points it does not have in its internal database.
Cascade Connect instructs the Connect Server to de-register the 10 rejected points with the Cascade DataHub so that they are not broadcast to the Windows client again.
10.5.1.3. A QNX application generates new data:
If the data corresponds to a Cascade DataHub point which is one of those still registered with the Connect Server (i.e. one of those that InTouch accepted), then the new value is sent to Cascade Connect.
The Connect Server translates the message into a TCP/IP message and sends the message to Cascade Connect.
Cascade Connect translates the message into a DDE message and sends it to the InTouch internal database.
10.5.1.4. An InTouch user sends data to a QNX application:
The user makes a change to one of the DDE tags within InTouch.
InTouch then sends the change as a DDE message to Cascade Connect.
Cascade Connect translates the message into a TCP/IP message and sends it to the Connect Server.
The Connect Server translates the message into a QNX message and sends it to the Cascade DataHub.
If the point is one of the points that the QNX application has registered with the Cascade DataHub, then the point change will be sent from the Cascade DataHub to the QNX application.