4 VERIFICATION

If you are already familiar with the VLT Common Software, simply browse section 4.4 to get familiar with any new tool introduced by this version.

This section describes how to setup a simple application environment in order to exercise some, but the most important, features of the VLT Common Software. The purpose of this action is twofold:

· providing a way to verify the correctness of the installation you have just completed

· providing a simple tutorial on the use of the VLT Common Software.

The detailed information on how to configure each module is provided by the appropriate User Manual.

The scope of this section is limited to a WS and a LCU in a one-environment-per-node configuration. For the configuration and verification of Drivers and Motor Control and for more environments on a WS, please refer to the User Manuals.

The following sections assume that:

· you are familiar with configuring UNIX and, as appropriate, RTAP tools and/or VxWorks utilities and that node names, IP addresses, etc. are already correctly configured on your WS.

· you have one WS with Full CCS or CCSLite and one LCU and you set up an environment on each. In this chapter <wsenv> and <lcuenv> will be used to represent the name of the two environments.

Generally speaking, in order to verify the correct file setup, configuration activities should be done by a username that is not the one used for installation. The database is already created having a user called "ccsuser": add it to your system and use it for all configuration activities described by the present chapter. When you are more familiar with CCS, LCC and RTAP or CCSLite, other users can be defined.

4.1 UNDERSTANDING ENVIRONMENTS

The VLTSW is based on the concept of environments where processes can run and exchange messages with other processes, either in the same environment or in a remote environment, on the same machine or in other machines.

Environment can be:

CCS environment (on WS)
based on an RTAP environment, providing database and communication facilities (q-server), and used to build WS applications. There can be one or more such environments per WS.

CCS-Lite (or QSEMU) environment (on WS)
a limited environment used when no RTAP is installed (CCS-Lite).

LCC environment (on LCU)
provides database and communication facilities (lcu-Qserver) to build real-time applications. Maximum one environment per LCU.

An environment is uniquely identified by the environment name. Remember that environment names are limited to 7 chars and the first letter is mandatory "w" for WS and "l" for LCU.

REMARK: Real VLT environment names must follow the conventions defined by the applicable version of "VLT LAN's Specification". In the following example generic names built using the machine node name are used.

From the communication point of view, each environment is identified by the node on which is running and a TCP/IP port number. The same number can be used on different nodes for the same type of environment. Currently we use:

2160 for LCC environments,

one number in the range 2001-2999 for each CCS and QSEMU environment.

4.1.1 Configuring Environments

To be able to communicate, environments need to know about each other.

1. there is a TCP/IP channel (environment name and port number) for each environment. Actually, the couple node-number shall be unique in the system. So the same number can be used for all the LCC environments. TCP/IP channels are defined in the file /etc/services.

2. (for CCS-Lite only) each CCS-Lite (QSEMU) environment needs to know where other CCS, QSEMU, LCC environments are located, they can be both local or remote to the WS. $VLTDATA/config/CcsEnvList provides such a mapping

3. each LCU needs to know from which host it has to boot and which are the other environments: CCSs and QSEMUs (an LCU should not talk directly to other LCUs). This is done by the $VLTDATA/ENVIRONMENTS/<lcuenv>/bootScript file.
If LCU(s) need to communicate with more WS environments than the assigned boot environment, then the file "$VLTDATA/config/lqs.boot" must be created and edited. The standard file in "$VLTROOT/vw/bin/$CPU/lqs.boot" can be taken as template.

4. each CCS (RTAP) environment needs to know where other CCS, QSEMU, LCC environments are located, they can be both local or remote to the WS. /etc/$RTAPROOT/RtapEnvList provides such a mapping.

In addition:

each CCS environment shall have a $VLTDATA/ENVIRONMENTS/<wsenv> for the database files (dbl/ and DB/), snapshots and database image (Rtap...) and process configuration table (RtapEnvTable)

each QSEMU environment shall have a $VLTDATA/ENVIRONMENTS/<wsenv> for the database files (dbl/ and DB/), snapshots and database image and process configuration table (CcsEnvTable)

each LCC environment shall have a $VLTDATA/ENVIRONMENTS/<lcuenv> for the database files (dbl/ DB/) and boot files (bootScript, devicesFile, ...)

In addition to the basic environment configuration, other configuration tables are required by applications like CCS Log System and CCS Scan System.

The verification process will drive you to a first set up of these files.

REMARKS:

the VLT Software Environments Common Configuration User Manual provides a detailed documentation about environments and configuration tools. The panels layout as well as several examples of expected output are also given.

4.2 THE APPLICATION EXAMPLE

To have the possibility to work-out the CCS or CCSLite and LCC software, a simple example, consisting of an LCU application and of a WS application, is provided.

Each application is implemented as a VLT software module and also provides an example of use of the VLT Programming Standards. Please note:

· the standard subdirectory structure,

· the use of naming conventions,

· the standard Makefile,

· the documentation in form of man-pages,

· the command definition table (LCU only),

· the error files.

4.2.1 The LCU Application

The LCU application consists of one process (lcuapp) able to treat the following incoming commands:

SETVAL with one integer parameter (ASCII format):

IF 0 < value < 100

THEN

· the value is written in the :PARAMS:SCALARS.scalar_int32 point of the LCU local database

· the message "Value received = <value>" is logged

· an empty reply is given back

ELSE

· the message "Value received = <value> (out of range)" is logged

· an error message "Value out of range" reply is given back

EXIT:

· an empty reply is given back

· the process quits

The implementation of the LCU application is in ~/VLTSW/example/lcuapp and is generated during the installation.If needed, can be generated as follows:

$ cd ~/VLTSW/examples/lcuapp/src

$ make clean

$ make all

$ make man

$ make install

4.2.2 The WS Application

The WS application consists of two programs:

wsappShowValue that continuously displays an item from the local database until a "q" character is typed in.

wsappSetValue that works with a companion partner, named lcuapp, on another environment. It prompts the user for input:

IF an integer number is typed in:

· the number is formatted into a message (SETVAL) and sent to the partner

· the reply message from the partner closes the loop and prompts for a new input.

IF a "q" character is typed in

· an EXIT message is sent to the partner

· as the reply message from the partner comes back the process terminates as well.

The implementation of the WS application is in ~/VLTSW/example/wsapp and is generated during the installation.If needed, can be generated as follows:

$ cd ~/VLTSW/examples/wsapp/src

$ make clean

$ make all

$ make man

$ make install

4.3 INSTALLING AND CONFIGURING ACC DATABASE

The ACC database contains all the information (IP address, machine type, node name, etc.) used by the configuration tools and it uses mSQL as database engine (see the ~/VLTSW/tcltk/msql-<version>/doc/License for copyright).

Except for the differences explicitly indicated, it is the same procedure for both HP and SUN. This installation is done as "vltmgr". By default, "vltmgr" is also the username authorized to write the database. For more information, please refer to the ACC and msql documentation.

You need only one database running for all machines. The environment variable ACC_HOST tells the VLT Software the host where the database daemon is running. For every machine, including the one where the daemon runs, define:

$ export ACC_HOST=<host>

in the /etc/pecs/releases/000/etc/locality/apps-`hostname`.env and install the mSQL software on that <host> only.

The mSQL code is generated and installed in $TCLTK_ROOT during the buildTcltk step. Such a generation is enough to correctly generate the Sequencer. The following actions are needed to create and to start the database and to load it with the configuration data:

1. create user access list

$ cp $TCLTK_ROOT/include/msql.acl $VLTDATA/msql/msql.acl

(you should not need to edit this file. If you do it while the daemon is running, see below, use the utility msqladmin reload to make the changes effective)

2. Fix /etc/services (HP ONLY):

HP-UX provides a default value for msql in /etc/services. This interferes with our installation.

Please comment in /etc/services as follows:

.....

#msql 1111/tcp # Mini SQL database server

.....

3. start the mSQL daemon:

$ msqld&

mSQL Server 1.0.16 starting ...

4. create acc database:

$ msqladmin create acc

Database "acc" created.

5. load the definition of the basic tables used by the VLT Configuration tools:

$ msql acc < $VLTROOT/config/accCreateVCCTables.sql

Welcome to the miniSQL monitor. Type \h for help.

mSQL > -> -> ->

Query OK.

.......

Bye!

6. check database structure:

$ msqlrelshow acc

Database = acc

+---------------------+

| Table |

+---------------------+

| prog_environment |

| station |

| subnet |

| lcu_progenv |

+---------------------+

$ msqlrelshow acc station

Database = acc

Table = station

+-----------------+----------+--------+----------+-----+

| Field | Type | Length | Not Null | Key |

+-----------------+----------+--------+----------+-----+

| station_name | char | 30 | Y | Y |

| station_type | char | 30 | N | N |

| subnet_name | char | 30 | N | N |

| ip_address | char | 20 | N | N |

| active_status | char | 15 | N | N |

| location | char | 80 | N | N |

| responsible | char | 80 | N | N |

| telephone | char | 80 | N | N |

| email | char | 40 | N | N |

| station_arch | char | 16 | N | N |

| station_cpu | char | 16 | N | N |

| station_bsp | char | 16 | N | N |

| attic | int | 4 | N | N |

+-----------------+----------+--------+----------+-----+

.......

7. create a plain ASCII data file. First get the templates

$ cp $VLTROOT/config/accData.sql $VLTDATA/msql/

then edit the file $VLTDATA/msql/accData.sql as explained by the comments. When ready load it:

$ accLoadData

8. check the database content:

$ msql acc

Welcome to the miniSQL monitor. Type \h for help.

mSQL > select * from station\g

Query OK.

.....

mSQL > \q

Bye!

Test the installation by quering the database from a VLT utility:

$ vccShow

--- VCC: VLT Common Configuration ---

... Hosts defined: ..........

... Environments defined: .....

........

Env Host TCPport IP address Arch CPU BSP

------- ------- ------- -------------- ------- ------- -------

l...

Remember to include the definition of ACC_HOST among the environment variables defined at the login.

4.3.1 Automatic Startup of Database Daemon at boot Time

As "root" do the following steps to have the database daemon always active after a reboot of the machine:

- HP:

# cp /home/vltmgr/VLTSW/PRODUCTS/pecs/templates/msql /sbin/init.d/msql

# chmod 555 /sbin/init.d/msql

# chown bin /sbin/init.d/msql

# chgrp bin /sbin/init.d/msql

# cd /sbin/rc3.d

# ln -s /sbin/init.d/msql S910msql

# cd /sbin/rc2.d

# ln -s /sbin/init.d/msql K089msql

- SUN:

# cp /home/vltmgr/VLTSW/PRODUCTS/pecs/templates/msql /etc/init.d/msql

# chmod 555 /etc/init.d/msql

# chown bin /etc/init.d/msql

# chgrp bin /etc/init.d/msql

# cd /etc/rc3.d

# ln -s /etc/init.d/msql S91msql

# cd /etc/rc0.d

# ln -s /etc/init.d/msql K08msql

4.4 CONFIGURE AND VERIFY

This section guides you through the configuration of one CCS(CCSLite) environment and one LCU. It is assumed that both VxWorks and RTAP or CCSlite are installed.

If VxWorks is not installed, please skip everything concerning LCU.

4.4.1 Configure the LCU TCP/IP Channels

In order to have communication between LCU and WS (Engineering User Interface), a TCP/IP channels (environment name and port number) is required for each environment. TCP/IP Channels are defined in the file /etc/services (you need to be root to edit it). Add to such a file one line for each LCU and for each WS environment. E.g.:

/etc/services

.

.

#------ begin VLT configuration

lted 2160/tcp # lqs on ted

wte19 2301/tcp # ws environment on te19

#------ end VLT configuration

4.4.2 Configure the LOGGING System.

The Logging System is not automatically started with the environment because it is independent to it. The Logging system is installed as follows:

1. log file location:

export VLT_LOG_FILES=/vltdata/tmp

export VLT_LOG_ROOT=/vltdata/config

These variables are normally set by the standard environment (alias PECS).

2. as vltmgr, create the empty files:

$ cd $VLTDATA/tmp

$ touch logFile

$ touch logAuto

$ chmod 666 logFile logAuto

3. as root:

a. configure the syslog:
vi /etc/syslog.conf
. . . . .

insert

*.info;mail,local1,local2.none

<TAB>/var/adm/syslog/syslog.log (HP)

<TAB>/var/adm/messages (SUN)

# The following two lines configure the VLT logging system

#

local1.warning<TAB>/vltdata/tmp/logFile

local2.warning<TAB>/vltdata/tmp/logAuto

b. force syslogd to read the new configuration file

$ kill -HUP `cat /etc/syslog.pid`

c. enable user vlt to use crontab by adding "vlt" to:
HP: /var/adm/cron/cron.allow
SUN: /etc/cron.d/cron.allow

4. as vlt:

a. add the automatic clean-up of the log files to "vlt" crontab:

$ export EDITOR=vi (for the tcsh shell)

$ crontab -e

Add the following line (or substitute any previous line containing the logVLTBackup command):

0,5,10,15,20,25,30,35,40,45,50,55 * * * * bash -c \

'. $HOME/.bashrc; logVLTBackup vlt vlt 12 100000'

5. as vlt, verify the syslog:

a. in one window: $ logger -p local1.warning "this is my text"

b. in another window: $ tail -10 $VLT_LOG_FILES/logFile

.... the second window should show your message.

4.4.3 Configure the WS Environment

Each CCS or CCSlite environment is defined by a name that shall be unique in the network. Hereafter <wsenv> is used to name the CCS or CCSlite (or QSEMU) environment you are configuring. Substitute each occurency of <wsenv> with the real name.

1. as vltmgr, define the environment as the "local" environment, i.e., the one to access data from when environment name is not specified:

$ export RTAPENV=<wsenv>

Do it for all windows you may have opened. This definition is needed from now on and it should be added to the other ones defining the environment (e.g., added to /etc/pecs/releases/000/etc/locality/apps-`hostname`.env)¹

2. make this environment known to the system:

RTAP
Add a line as follows to /etc/$RTAPROOT/RtapEnvList

<wsenv> <VLTDATA>/ENVIRONMENTS/<wsenv> # environment on <ws>

CCSlite
Add a line as follows to $VLTDATA/config/CcsEnvList

<wsenv> <VLTDATA>/ENVIRONMENTS/<wsenv> # environment on <ws>

3. using the configuration tool:

$ vccEnv &

· enter the actual environment name and press Return (or, depending on the keyboard, Enter). Fields are filled with defaults values, normally appropriate.

· click "Create" button. The window will show the log of ongoing operation.

· click "Init" button. say "OK" to confirmation window.

· click "Start" button. The logfiles in $VLTDATA/ENVIRONMENTS/<wsenv>/*.log

· or $VLTDATA/ENVIRONMENTS/<wsenv>/.*.log (note the initial "dot") should not report any errors.

The default database is already configured to support the verification tests. The RtapEnvTable (or CcsEnvTable) file defines the processes that shall automatically start at database startup.

For full CCS, you can use the RTAP tools to inspect the database structure (RtapDbConfig, RtapPtSelector, RtapPtDisplay) or to monitor the running processes (RtapPerfMon).

4.4.4 Verify the WS Environment

The easiest way is to use ccsei to interact with the WS environment. Ccsei is the interactive utility to exchage messages with local and remote applications, to read/write in databases, to monitor the logs, to call other development and debugging tools. The same functions are available for both LCU and WS environments.

If the WS environment has been properly started, all ccsei utilities should work. Invoke the main menu first:

$ ccsei

... the list of available tools is presented.

REMARK: from now on, the main menu of ccsei is supposed to be always displayed on the user screen.

Try some simple operations:

See a log:

1. from the ccsei main menu, click "CCS Log Monitor". The "VLT Log Monitor" tool is started. Enable the monitoring by clicking the "MONITOR" option. On another xterm, create a log:

$ logger -p local1.warning "this text should be displayed"

It should be displayed.

Send a Message

2. click "CCS Command Window". The "ccsei Message Command Window" is presented

3. write "cmdManager" in the "Process" field, click "Help" and select "On Commands". The "Help On Commands" panel is presented.

4. select the "VERSION" command: the command format is displayed and the command name also appears after the prompt of the Command Window (1<wsenv> cmdManager VERSION (Par)>).

5. click after the VERSION (Par)> and press the <Enter> key to send such a command to the cmdManager process. The "Replies" field should give the version number of the currently running cmdManager.

6. close the "Help On Commands" window;

7. click "File" and then "Quit" to close the "ccsei Message Command Window"

Read/Write into the database:

8. click "CCS Database Monitor" in the main menu. The "ccsei Database Monitor" window is presented. Click "CCS Database Monitor" again to have a second window. The first will be used for a continuos monitor of a variable, the second to change the variable content.

9. in both windows: click "Browse", then select "PARAMS", "SCALARS", "scalar_int32", "Accept" to move the point name to the main menu, "Dismiss" to close the point browser. Both should display the same value.

10. In the first window, click "Move to list" and "Activate Monitor"

11. In the second window, click on the "DB Value" field, type another value and press <Enter>. The first window should show the new value in the field labeled "Data Quality and Values:" (a little delay is normal).

12. close all the panels, but the main menu.

More about the ccsei can be found in the "CCS User Manual".

4.4.5 Configure the LCU Files on the WS

To work the LCC requires that some files are set on the WS acting as boot node.

Each LCU environment is defined by a name that shall be unique in the network. Hereafter:

<lcuenv> is used to name the LCU environment you are configuring

<lcunode> is the LCU node name.

Substitute each occurency of <lcuenv> and <lcunode> as appropriate.

For each LCU environment:

1. be sure that:

· the LCU is booted and the remote login from the WS to the LCU is possible (no one is locking the LCU shell).

· the "vx" username is defined and the LCU can execute a remote shell to it (either ~vx/Xauthority or ~vx/.rhosts correctly set)

2. using the configuration tool:

$ vccEnv &

· enter the actual LCU environment name (<lcuenv>) and press Return (or, depending on the keyboard, Enter). LCU-host (<lcunode>), the Boot-env (<<wsenv> or <qsemuenv>) are taken from the database.

· click "Maximum" and then click on "Create".

· click "Init".

· the "Config..." button invokes the "vccConfigLCU" panel to change configuration options. The default values are enough for the validation test, but you can set what needed by your applications. Click "WriteFiles" when ready to regenerate target files. Click "Continue" to override the current files. Then go back to the vccEnv panel.

· click "Start" to reboot the LCU. The log of the reboot process allows you to follow it. At the end of the boot, the console should display the message:

LCC INITIALISATION SUCCESSFUL.

REMARK: to be able to display the boot log, the LCU Configuration tool locks the connection to the LCU for about 120 seconds. After this time the connection is released (vccConfigLcu: connection closed). If the boot process takes longer, part of the log may not be displayed. In such a case, check the LCU console.

3. check that among running LCC processes there are:

$ rlogin <lcunode>

<lcuenv>->i

(the processes may be listed in defferent order!)

NAME ENTRY TID PRI STATUS ......

---------- ------------ -------- --- ---------- ......

...... .... .....

...... .... .....

lccServer _cmdInit 61d964 80 PEND+T

rdbServer _cmdInit 6005cc 80 PEND+T

msgServer 731da6 6864f8 100 PEND

lccTime 737fa0 681548 100 DELAY

lccEvent 71848a 652438 100 READY

lccPeriodic733a92 64d488 100 READY

lccDevice 711d1e 622914 100 DELAY

lccWatchdog73d86e 6c7e50 150 READY

tLqsClk 784410 6ce1bc 250 DELAY

lccLogger 728d18 68b4a8 250 READY

value = 0 = 0x0

<lcuenv>->

and that the LCU environment table has been correctly loaded

lted-> lqsPrintEnvTbl

Environment Host name TCP port ..... .....

----------- --------- --------

wte19 te19 2226

lted ted 2160

value = 59 = 0x3b = ';'

lted->

In case the LCU does not boot correctly check that: the boot directory is NFS mounted:

<lcuenv>-> nfsDevShow

device name file system

----------- -----------

/vltdata wtatcam:/vltdata

/VLTROOT wtatcam:/vlt/OCT99

value = 0 = 0x0

<lcuenv>->

4.4.6 Make the LCU known to the CCS environment

1. make the LCU known to RTAP: add a line as:

<lcuenv> <lcunode> # LCC environment on <lcu>

to:

RTAP: /etc/$RTAPROOT/RtapEnvList (HP 10.20 only)

CCSlite: $VLTDATA/config/CcsEnvList (HP11.00 and SUN)

2. configure reporting node for LCU log activity
$ cp $VLTROOT/include/logLCU.config.template \
$VLTDATA/config/logLCU.config
and modify it according to your configuration.

$ cat $VLTDATA/config/logLCU.config

<lcuenv> <wsenv> (*)

(*) remember to terminate the last line with EOL

3. check the connection

a. by a simple message exchange:

$ msgSend <lcuenv> lccServer LCCGVER ""

MESSAGEBUFFER:

"@(#) LCC ....<version>... ....<date>....."

4. force the logManager to read the new configuration:

$ logConfig

5. from the ccsei main menu, start a "CCS Log Monitor", click on "MONITOR", then create a log from the LCU

$ rlogin <lcu>

<lcuenv>-> logData "test", 101, "this is a log from an LCU"

value = 2 = 0x2

check that the log is displayed by the monitor tool.

REMARK: a delay of few seconds is normal because, in order not to overload the network, logs are transmitted by the LCU to the upper level only periodically.

4.4.7 Verify the LCU environment

Ccsei can also be used to verify the just created LCU environment.

Send a Message

1. click "CCS Command Window". The "ccsei Message Command" window is presented

2. from the [+] menus, select <lcuenv> as environment and then lccServer as process.

3. send the command LCCGVER (either by typing it after the prompt or by selecting from the menu); type `enter". The "Replies" field should display the version number:

REPLY: "@(#) LCC ....<version>... ...<date>..."

In the same way, other commands can be used (see LCC User Manual)

Read/Write into the LCU database:

4. click "CCS Database Monitor" in the main menu. The "ccsei Database Monitor" window is presented. Click "CCS Database Monitor" again to have a second window. The first will be used for a continuos monitor of a variable, the second to change the variable content.

5. continue as in 4.4.4, but from the [+] menus, select <lcuenv> as environment . Notice that the selection of the database point using the "Browse" facility is slower because the system queries the database structure from the running LCU.

4.4.8 Interact with an LCU Application

The lcuapp is used to test and demonstrate the way of working of ccsei.

1. from the ccsei main menu, click "Log Monitor". The "VLT Log Monitor" tool is started. Enable the monitoring by clicking the "MONITOR" option.

2. make the lcuapp known to ccsei. Add one line containing lcuapp to the file $VLTDATA/ENVIRONMENTS/<lcuenv>/PROCESSES

3. load lcuapp into the LCU and start it: open an rlogin on the LCU. Give the following commands

$ rlogin <lcunode>

<lcuenv>-> cd getenv("VLTROOT")

<lcuenv>-> cd "vw/bin/MC68040" (if you use 68k LCUs)

or

<lcuenv>-> cd "vw/bin/PPC604" (if you use PPC LCUs)

<lcuenv>-> ld < lcuapp

<lcuenv>-> sp lcuapp

Two logs should appear in the LCC Log/Inspect Window telling that lcuapp has started and is waiting for commands.

4. start a "CCS Database Monitor" window in monitoring mode (check "Move to list" and "Activate monitor" ) on the <lcuenv>:PARAMS:SCALARS.scalar_int32 variable.

5. from a "CCS Command Window", select <lcuenv> as environment and then lcuapp as process, then send a SETVAL <nn> message to lcuapp to change the value in the LCC database. <nn> is an integer; the valid range is 0-100.

· the Database Monitor should show the new value (<nn>)

· the Log Monitor should report on the LCU activities.

· the Command Window should not display error replies

Repeat for different values. If <nn> is out of range, an error and a different log should be received.

6. from a "Command Window", send EXIT to lcuapp to stop the application.

4.4.9 Verify Cooperation between WS and LCU Applications

The scenario we are going to use now is the same as the one used to test the lccei, but a WS appl cation is used to send commands to the LCU companion.

At this point you are already an expert in configuring both WS and LCU so set things up as follows:

· the WS environment is running (see 4.4.3)

· the Logging system is active (logManager) and a logMonitor window is displayed (see 4.4.2 4.4.6)

· th LCU is properly configured, i.e., it can communicate with the WS environment (see 4.4.6)

· lcuapp is running on the LCU (see 4.4.8)

· ccsei is monitoring the LCC database position :PARAMS:SCALARS.scalar_int32 (see 4.4.8)

At this point you can run the WS application that sends the number you type to lcuapp in order to be stored, if in the range, into the LCC database.

$ wsappSetValue <lcuenv>

wsappSetValue - WS application example - Version 1.1, June 94

Enter a number to send to the LCU ....

Enter 'q' to quit

<nn>

<nn>

....

q

If in range, the number you type will be displayed by the Monitor window. Repeating for different values of <nn> you can experiment with several cases, including logs, errors, replies, etc. Type a "q" to stop both lcuapp and wsappSetValue.

These actions complete the verification of CCS/CCSLite and LCC installation. If you have CCSlite, please go to 4.4.12.

4.4.10 Configure the CCS/Scan System

This sections applies only to Full CCS installations

The Scan System allows you to mirror an LCC database variable into a CCS database variable.

To configure the Scan system follow what is described in the CCS User manual. Briefly:

1. configure the Scan system on the LCU:

a. create in the LCC database the device point corresponding to <wsenv>. Edit the LCC database description on the WS:

$ cd $VLTDATA/ENVIRONMENTS/<lcuenv>/dbl

$ vi USER.db

...edit according to the instructions given in the file itself

$ make db

b. reboot the LCU (vccEnv, select <lcuenv>, "Start")

2. configure the Scan system on the WS.

a. stop the environment (vccEnv, select <wsenv>, "Stop")

b. create in the CCS database the device point corresponding to <lcuenv>

$ cd $VLTDATA/ENVIRONMENTS/<wsenv>/dbl

$ vi USER.db

... edit the USER.db file, and rename (name and alias) the device point according to your <lcuenv>.

$ make db

c. re-Initialize the environment (vccEnv, select <wsenv>, "Init", "Start")

3. enable scanning from LCU:

$ scanDevOn <lcuenv>

4.4.11 Verification of the Scan System

This sections applies only to Full CCS installations

The scenario we are going to use now is the same as the one used to verify the cooperation between WS and LCU applications (see 4.4.9), but the Scan System is used to mirror the LCC database value into the WS and a WS application is used to display it.

Set things up as follows:

· the CCS environment, including Scan System, is running

· the CCS/Logging system is active (logManager) and a logMonitor window is displayed.

· the LCU is properly running, including lcuapp.

Now configure the Scan system so that the content of the variable accessed by lcuapp is also mirrored in a CCS database variable having the same name:

$ scanConfig ":PARAMS:SCALARS.scalar_int32"

"@<lcuenv>:PARAMS:SCALARS.scalar_int32" POLL 1

(both variables are already defined in the database configuration shipped in the tape, so you do not need to create the variables, but only to establish the link.)

Then start the WS application that displays the CCS environment position:

$ wsappShowValue

wsappShowValue - WS application example - Version 1.1, June 94

Display DataBase variable (press 'q' to quit).

==============================================

Reading from: @ccs:PARAMS:SCALARS.scalar_int32

Time: 05:33:54 Value: 88

Change the value in the LCU database

$ dbWrite "@<lcuenv>:PARAMS:SCALARS.scalar_int32" <nn>

<nn> should be displayed.

The last test involves nearly all the CCS and LCC modules. Run again the WS application that sends the number you type to lcuapp.

$ wsappSetValue <lcuenv>

wsappSetValue - WS application example - Version 1.1, June 94

Enter a number to send to the LCU ....

Enter 'q' to quit

<nn>

<nn>

....

q

If in range, the number you type will be displayed by wsappShowValue. As before, you can experiment with several cases, including logs, errors, replies, etc.

4.4.12 WS Environment Shutdown

To terminate the verification, close the environment properly using the vccEnv "Stop" or:

$ vccEnvStop -e<wsenv>

These actions complete the verification of CCS/CCSLite and LCC installation.

4.5 OTHER TESTS

The verification procedure has the purpose to check that basic features work correctly and to get you acquainted with the VLT Software.

During installation you may have decided to install many more modules than the one the verification procedure has tested. The User Manual of each software module contains additional tests. Please refer to such documentation to configure and test drivers, INS software, etc as appropriate to your installation.

4.6 CONFIGURING WORKSTATION STARTUP

As appropriate, the startup of the standard environment, qsemu, logManager, etc. can be part of the WS startup process. The automatic startup of the ACC database server has been described in 4.3.1, the automatic start of the WS environment is described in the RTAP/CCSlite installation procedure (see 3.7.4, 3.7.5).

4.7 REPORT TO ESO

You are kindly request to provide by mail, fax or e-mail (see 2.6 for addresses) the list of the products you have installed and the computer configuration (type, OS, etc).

Please contribute to improve the quality of this manual, especially the trouble-shooting list (see 5): add to your report any suggestions you may have to improve the installation procedure or any mistakes you may have made.

Problems or errors in the installation procedure should be reported using the SPR form (see 2.6).

¹

The standard environment provides the default definition: RTAPENV=w${HOST}

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com