Using InSQL and Alarm Logger in a Terminal Server Environment

Example Architecture:

In this example we have 5 machines:

• INSQLBox : Running IndustrialSQL and hosting the Alarm Logger database, WWALMDB.

• TERMSERV : A Terminal Server running InTouch for Terminal Services and hosting 4unique InTouch applications.

• WS1 through WS4 : Workstations each running InTouch in a Terminal Server Client session.

Assumptions:

• Each of the four InTouch applications (APP1 through APP4) is unique.

• Some Tagnames in one application are identical to Tagnames in another application.

• Each InTouch application communicates with its own PLC (i.e. they have unique AccessNames.

• A single ABTCP I/O Server with four configured Topics (PLCTopic1 through PLCTopic4) is running in the Console session of TERMSERV.

 Goal:

• Capture the unique Process History and Alarms for each InTouch application running in a Terminal Server Client session.

Configuration Steps:

INSQL

1. On the InSQL Server (INSQLBox) edit the …\SYSTEM32\DRIVERS\ETC\HOST file, adding an entry for each Terminal Server Client and associating it with the IP Address of the Terminal Server (TERMSERV – 11.22.33.99).  The HOST file is used to associate (resolve) names to IP Addresses.  In this example, Client1 through Client4 will represent the Terminal Server sessions running on WS1 through WS4 computers.  We will associate each Clients alias with the IP Address of the Terminal Server, since ultimately, the Client sessions running on WS1 through WS4 are running in memory on the Terminal Server machine.

2. Add a New IOServer Type for each InTouch Terminal Server Client session. An InTouch Terminal Server Client session is uniquely identified by the IP Address of the computer on which the Client session is running. A function called TseGetClientId() comes with InTouch for Terminal Services that identifies the Clients IP Address. When making a SuiteLink connection to InTouch running in a Terminal Server Client session, the syntax is VIEW<Client IP Address>. The traditional syntax is simply VIEW, however, in a Terminal Server Environment, you may have multiple VIEWs running in memory. Each VIEW memory session needs to be uniquely identified.

1. From the InSQL Console – Configuration Editor – System Configuration – Data Acquisition, right mouse click on I/O Server Types and select New I/O Server Type… The following dialog illustrates the I/O Server Type associated with Terminal Server session running on workstation WS1 which has the IP Address 11.22.33.144.
   

2. When finished, a new I/O Server Type should be added for each client.

3. Import the desired tags for historical data collection from each of the unique InTouch Applications. Note that InSQL can only import one application per computer. Since all four InTouch applications in this example exist on the same computer, TERMSERV, is it necessary to make some changes during the Import procedure.

1. From the InSQL Console – Configuration Editor – System Configuration – Data Acquisition , right mouse click on I/O Server Types and select Import Tags… Click NEXT and then ADD.

2. Navigate to the Tagname.x file of the first InTouch application (APP1) and click OPEN.

3. From the Tag Importer – InTouch Node Information dialog, in the InTouch Machine Name entry field, replace the Terminal Server name with one of the client alias’ added to the HOST file in Step 1. Click NEXT.

4. From the Tag Duplicates dialog, it may be beneficial to uniquely identify each Tagname with its InTouch application. This will handle any tagnames duplicated in each of the InTouch applications. For example:

5. Continue through to the end of the Import, making the appropriate dialog selections according to your logging requirements.
6. Repeat the Import process for each of the Terminal Server InTouch applications. Below is the final result of the Imports for this example:

4. Change the InTouch (i.e. VIEW) SuiteLink connection to reference the correct communication syntax for Terminal Services. By default, a VIEW reference for each InTouch application is created following the Import process. These VIEW references need to be modified to work in a Terminal Server environment.

1. From the InSQL Console – Configuration Editor – System Configuration – Data Acquisition – IDAS, right mouse click on the \\Client\VIEW and select Properties.
2. From the I/O Server Type combo box, change the VIEW selection to the desired VIEW<Client IP Address> selection created in Step 2. Below is a configuration before and after:

5. Commit all of the changes. From the InSQL Console – Configuration Editor – System Configuration – Data Acquisition, right mouse click and select Commit Pending Changes… . Click on Commit.

NOTE: InSQL keeps track of which Tagnames are associated with which Imported InTouch application. If tagname changes (modifications, deletions, or additions) are made to a particular application a FULL REIMPORT for the InTouch node associated with the changed InTouch application should be performed. The FULL REIMPORT will bring all changes into InSQL, however, it will also change the InTouch I/O Server back to the default of VIEW. It must then be changed back to the correct Terminal Server syntax of VIEW< Client IP Address >.

ALARM LOGGER

1. Start the Wonderware Alarm DB Logger Manager in the Console session of the Terminal Server (TERMSERV). This will be the only instance of the Alarm Logger running and will be responsible for logging all of the alarm information generated by each InTouch Terminal Server Client session.

1. The Alarm DB Logger Manager is found in the Wonderware – InTouch folder.

2. From within SETTINGS, connect and create the Alarm database (WWALMDB) on the InSQL machine (INSQLBox). Click NEXT.
3. In the Query Selection dialog, enter an Alarm Query for each of the InTouch Terminal Server Client sessions. The correct Alarm Query syntax for Terminal Services is: \\<Terminal Server IP Address>:<Client session IP Address>\InTouch!<InTouch Alarm Group>

4. Finish out the configuration and START the Alarm Logger. The alarm for each client session will be logged to the database WWALMDB and the session from which they were generated can be identified from the Provider column.

SUMMARY

This document addresses a specific architecture of InSQL, InTouch, and Alarm Logging in a Terminal Server environment. It is designed to inform the Wonderware user of key differences when configuring Wonderware in a Terminal Server architecture. Those main differences being the syntax used to communicate to the InTouch application running in a Client session. If you are using Wonderware on Terminal Server and your architecture is different then the one discussed here, please give Q-mation a call with any questions.

©2003 Q-mation, Inc. All rights reserved. All trademarks are the property of their respective owners.