| |
|
|
|
2 USER MANUAL
2.1 THE TCS INTERFACE
The TCS is composed of many software modules, each of them consisting of one or more processes. To unify and simplify the access from users to the TCS functions the TCS Interface was developed, represented by the tif module.
The tif module is responsible for providing the central and only command interface between external users and the TCS. The users are typically higher-level applications, such as INS, ROS or HOS software, or interactive user interfaces related to these applications. The user processes communicate with the TCS by sending commands to and receiving replies from the tif. The tif internally dispatches the commands to the responsible TCS processes, receives their replies and passes them back to the originator (see also the man-page in section 3.1).
The overall TCS design foresees to run one tif instance per telescope focus station, named:
Each tif instance has access to all TCS processes involved in controlling the corresponding focus, but only one instance at a time is controlling the telescope, because only one focus at a time has the light-beam. An instrument which is connected to a certain focus always talks to the same tif instance, whether it has the light beam or not.
Note:all tif instances have access to the telescope at the same time, whichever focus has the beam. The TCS Interface itself provides no access control functionality. Instrument operators have to take care of not accessing the telescope when another instrument has the focus and is operating.
If for maintenance reasons it is necessarey to e.g. move an adapter for an instrument which doesn't have the beam, this can be done by the TCS operator, who can access all tif instances and all TCS modules and who can also use maintenance commands.
To enable multiple read access to TCS public data, a Data Query Library is provided which is linked to the user process. Also a public Event Configuration Library is provided to attach events to TCS data items. These libraries are described in section 2.3.
The Data Query Library is independent from the tif instances and has no relation with the tif instance under use by an application (if any). All data retrieved via the Data Query Library correspond to the current focus configuration and are always the same, independent of which tif instance is used. This means that, for example, the rotator position is always the position of the rotator with the light beam.
There are two operational configurations for a user (instrument):
depending on which focus is active.
2.2 COMMANDS
This section gives a list of all TCS commands available up to now, together with a brief description. See section 3.2 for a detailed description of each command, and section 5.1 for sample programs.
NOTE: the command list below reflects the current implementation state of the TCS and is not final. The commands listed here are available with the delivered version of the software. Future releases might include additional commands, as necessary.
NOTE: the command list below applies to the VLT telescope and is slightly different for the NTT telescope. NTT users should check specific NTT documentation for an accurate list of commands available via tif.
The following table alphabetically lists the telescope control commands, i.e. those commands available to an application which has the light-beam. On top of these TCS commands, the tif control process accept all the usual VLT standard commands and a small set of specific commands used for maintenance purposes.
The complete set of commands accepted by a tif control process is described in the reference section 3 of this manual and in the CDT in section 5.4
Units and coordinate systems for command parameters follow VLT conventions.
These are perhaps not the ones some users would expect, or might be different to what is used in other contexts (like FITS Headers). Please, make sure that you always check units and conventions on the Command Definition Table (5.4).
(*) available only for Nasmyth adapters, i.e. these commands are rejected for the Cassegrain adapter.
The following table lists briefly the commands available (currently only for simulation) to an application which has acecess only to an adapter (i.e. which doesn't have the telescope beam).
(*) available only for Nasmyth adapters, i.e. these commands are rejected for the Cassegrain adapter.
2.2.1 Sending commands to TIF processes
In order to be able to send commands to tif processes it is necessary:
2.2.2 Procedures
In this chapters some commands and procedures are described in detail to interact with tif correctly.
Store instrument configuration data in the TCS instruments data table for retrieval and use by Instruments and TCS applications.
For each instrument and each instrument mode that has different parameters a separate entry has to stored using SETINSD. The command triggers no action at all, unless it concerns the currently selected instrument. Then the new data might be retrieved and used by TCS applications, e.g. setting a different rotator offset.
The Operator of TCS makes the instrument selection on the telescope side. The instrument uses the command GETINS to find out which instrument is selected, i.e. to find out if it has the beam.
Select an entry of the instrument data table (previously stored with SETINSD) as the current instrument. TCS applications are notifed only of the new parameters, e.g. different rotator offset, and they trigger some action of their own accord.
Before using this command, the instrument should use the command GETINS to find out if it has the beam. If so, it can issue a SELINS to set the mode of the instrument. If the instrument does not have the telescope beam, it should set TCS in simulation automatically.
2.2.2.1 Focusing of the telescope using SETINSD, OFFSFAD
The following information has been excerpted from [12].
The UTs should only be focused using the active optics software. NO subsystem other than active optics is permitted to instruct the secondary unit to move in the Z (focus direction). The determination of the focal plane for the instrument is done by changing the focus of the guide probe, running active optics (with active optics OFFSET set to 0) an letting the active optics system determine the best value for the secondary mirror position. Then inspection of the image quality in the instrument will tell wether this is the best position for the focal plane. Once this value is determined then no further checks are necessary. Assuming the instrument focal plane does not change.
So for each focal plane of the instrument the guide probe offset has to be determined using OFFSFAD and the resulting value set afterwards with an SETINSD in the instrument configuration table, where it's retrieved automatically when a SELINS is issued. SETINSD has no other purpose than storing values for reference. It doesn't move anything, unless one issues SETINSD for the currently selected instrument. If a SELINS is issued the various subsystems retrieve the data set by the appropriate SETINSD.
2.3 APPLICATION PROGRAMMING INTERFACE
The TCS Interface provides some public libraries to be called by any user process to get access to TCS data and to interact programmatically with specific TCS subsystems.
The Data Query Library retrieves TCS data items. This includes functions to retrieve FITS header keywords.
The M2 Communication Library allows instruments to control M2 for Rapid Guiding, using the special RapidGuiding LAN
The two data libraries are combined in the tifLibs library files (both static and shared versions) under $VLTROOT/lib and can be linked to an application in the usual way (see man-page of the vltMakefile). The sources need to include the tif.h header file to access library functions. See section 3.3 and 3.5 for man-pages of the libraries, and section 5.1 for a sample program.
Both libraries use the concept of addressing data items by "name". These names are character strings and are also available as #defines. At implementation level, data items are configured via online database tables to allow an easier configuration. Previous versions of the library had a different implementation based on enumerations. This new approach makes the named access easily configurable without having to rebuild application executables.
The M2 Communication Library is available as a CCS library, as a NON CCS library and as an LCU library and is called m2com. The different versions are automatically installed in the proper directory under $VLTROOT, depending on the system configuration and can be linked to an application in the usual way (see man-page of the vltMakefile). The sources need to include the m2com.h header file to access library functions. See section 3.6 for man-pages of the library's functions.
As already mentioned, the tif libraries are independent from the tif instances and have no relation with the tif instance (if any) under use by an application. All data retrieved via the Data Query Library correspond to the current focus configuration and are always the same, independent of which tif instance is used. This means that, for example, the rotator position is always the position of the rotator with the light beam.
2.3.1 Data Query Library
The Data Query Library is intended to export all TCS data items which may be of interest for a user without forcing him to have detailed knowledge about the TCS database. The library has one general routine that retrieves single data items, three special functions that return groups of related data and two functions that produces FITS header data. The FITS functions are described in the following section.
The supported data items (configured by tif in the database) are read only once at startup of any tif application.
The set of functions which return groups of related data items in structures:
The information returned by the Data Query Library always reflects the state of the TCS correctly even after TCS shut-down or when a process crashes.
is provided to query single data items by name. The routine takes a symbolic name, as a string or by using provided defines, as input parameter and returns the data associated with that name in a user buffer, and also information about the data type.
The Table 3: below presents a list of all currently supported named data items and their data types.
The actual name for the name to be used in the call to tifGetByName() is obtained adding the prefix tifDATA_ to the name in the first column of the table. The name and the corresponding define are identical.
Units and coordinate systems for command parameters follow VLT conventions.
These are perhaps not the ones some users would expect, or might be different to what is used in other contexts (like FITS Headers). Please, make sure that you always check units and conventions here and on the man pages before using these values
Entries in the "Unit" column mean:
2.3.2 FITS header data
The Data Query Library provides two functions to obtain the standard TCS FITS keywords, synchronized to when the functions are called. It is recommended the INS software makes use of these functions in order to obtain the latest version of TCS FITS keywords as approved by DICB. These functions internally make use of tifGetByName, and they produce an ASCII file ready to be incorporated in the completed FITS file.
The table below gives all possible keywords produced by these functions
Units and coordinate systems for FITS Header Keywords follow ESO Data Interface Control Board conventions[11].
These are not always identical to VLT conventions, used for the TCS control software development. Please, make sure that you always check units and conventions before using these values.
2.3.3 Event Configuration Library
The Event Configuration Library provides functions to attach events to certain TCS database attributes, by using the CCS event system. This enables the user to configure events from his functional viewpoint, e.g. on LOSS OF TRACKING, without needing knowledge by which TCS database attribute this event is reflected.; see the following table for a list of supported events and also the man-page of the Event Configuration Library, section 3.5.
The supported event items (configured by tif in the database) are read only once at startup of any tif applica
tion.are provided to respectively attach and detach database events by name (actually, using an enum).
The following table presents a list of all currently supported named events.
The actual name for the enum to be used in the call to tifAttachEvent() is obtained adding the prefix tifEVENT_ to the name in the first column of the table.
This list will evolve in subsequent releases of this document and software.
2.3.4 Using the TCS Database and Event Interface Library
In order to use the TCS Database Interface Library it is necessary:
· The code should be written in C++ or at least compiled with the C++ compiler, i.e. the files should have the .C (capital C) filename extension. For more details on how C and C++ code interact, refer to the eccs[4] and evh[5] user manuals.
· The library tifLibs must be linked with the code. A typical VLT C++ application requires also the following set of libraries: evh eccs fnd C++ CCS.
It is then suggested the following minimal set of libraries for the Makefile:
USER_LIB = tifLibs evh eccs fnd C++ CCS
· If tifGetFitsStart() and tifGetFitsEnd() are used also the following libraries must be linked with the code; oslx slx misc tcsVcc msw.
Section 5.1 contains three complete and working sample programs, two using the Data Query Library and the other one using the Event Configuration Library.
The second Data Query Library example demonstrates how to use the tifGetFitsStart() and tifGetFitsEnd() to generate a complete FITS header.
2.3.5 M2 Communication Library
The M2 Communication Library provides functions to communicate with the M2 Unit via the Rapid Guiding Lan and to send M2 position offsets at high frequency.
are provided to respectively connect, to M2, send offset corrections and disconnect from M2.
2.4 ONLINE DATABASE ACCESS CLASSES
The tif module provides a set of public on-line database classes to allow access to TCS public data items via the on-line database instead that via the tif Data Query Library.
The class tifTCS_PUBLIC can be instantiated in any user (instrument) database to provide a local image of the TCS public data items. This class is used when the TCS database, real or simulated, is NOT in the same environment as the user (instrument) database. In this case, the scan system is used to update the user database with values from the TCS environment (real or simulated).
The class tifTCS_LOCAL has the same structure as tifTCS_PUBLIC (it is a subclass) and provides the same items, but can be instantiated in the same environment where TCS itself is running, i.e. when simulated TCS data are a part of the user (instrument) database. In this case, the items are updated using the calculation engine, instead of the scan system.
These classes have been implemented to provide access to TCS data for UIF instrument panels and Sequencer scripts, while C and C++ applications should use the tif Query Library.
For performance reasons, not more than one instance of the classes should be used in each environment.
2.4.1 Structure of the tifTCS_XXX public on-line database classes
The tifTCS_PUBLIC on-line database class (see the man page for details) is structured in sub-points that group the public items by category.
This has been done in order to allow a more structured access to the items themselves and to optimize performance on the update of the items, that is based on the RTAP calculation engine.
What follows is the structure of the class:
For more information about the meaning of the items, their units and their availability, see the Data Query Library section 2.3.1, and in particular Table 3 on page 19.
2.4.2 Using the tifTCS_PUBLIC database class
This class can be instantiated in any place in a user environment to get access to TCS public data via the scan system.
It cannot be instantiated in the same environment on which TCS itself is running.
In order to use the class, it is necessary to perform the following steps (for an example see the modular test of the tif module:
1. Configure the TCS database to allow scanning from the remote user environment.
To this purpose it is necessary to add a scan device for the environment in the TCS database.
For example, add the following lines in the USER.db file of the TCS environment:
POINT "<VLT scan dev>" ccs_config:scan\ config:LAN:wsIns
BEGIN
ALIASwsIns
END
2. Configure the user database to perform scanning from the TCS environment.
To this purpose it is necessary to add a scan device for the TCS environment in the user database.
For example, add the following lines in the USER.db file of the user (instrument) environment:
3. Add an instance of the tifTCS_PUBLIC class anywhere in the user database. The Makefile must contain proper definitions for the TARGET_TCS to be built (see section 2.6.2.2)
4. Configure the scan system by running the tifTcsScanSetup command.
See the man page for details on the command.
If a standard TCS configuration is used and if the environment variables are properly set, it is only necessary to pass the "-p" parameter with the symbolic address of the instance of the tifTCS_PUBLIC class.
5. In order to minimize the resources used by the scan system, it is suggested to disable the scan links for all the items not used, by using the CCS Engineering Interface tools or writing a proper script for this purpose.
2.4.3 Using the tifTCS_LOCAL database class
This class can be instantiated in any place in a TCS environment to get access to TCS public data via calculation engine expressions. This is typically used when a simulated TCS database is part of a user (instrument) database, and it is then used during simulation to temporary replace an instance of tifTCS_PUBLIC.
The class can also be used internally within TCS, by applications running on the TCS workstation.
If the TCS database is not placed in the standard branch Appl_data:TCS, it is necessary to (re)define tifTCS_DBROOT BEFORE including tifTCS_LOCAL.class in the database configuration file.
2.5 PANEL EDITOR CLASSES
The tif module provides a set of standard panel editor[8] User Interface Classes.
The purpose of these classes is to provide a standardized access for user interfaces to TCS data, provide a common look and feel and simplify and centralize under TCS modules responsibility some operations, like conversion from state indexes to strings that would otherwise be distributed in user applications.
In the current implementation only a class to display the status of TCS is provided.
Since it is very difficult to define "a priori" how TCS items will be displayed in instruments user interfaces, it has been decided not to initially design a set of classes but to incorporate in the library classes provided by the real applications designers.
Users are encouraged to develop and submit as soon as possible their classes for access to TCS data.
These classes will be checked for coherence with VLT UIF standards, evaluated for general interest, incorporated in this library, maintained and made public for reuse.
All classes are designed to get data from TCS via an instance of the tifTCS_PUBLIC or tifTCS_LOCAL class. The current working point[8] of the main panel and of the panel class instance must be set to provide the right database path to access such a database point. For an example of correct implementation, see the implementation of the panel class tifTcsState_uifClass in the tif module. For an example of correct usage, see the implementation of the panel tcssimTcsControl.pan in the tcssim module.
2.5.1 tifTcsState_uifClass
The panel class tifTcsState_uifClass provide access to TCS global status information.
The following figure displays the look and feel of the class. The conversion from the indexed values available on the database and the corresponding strings is performed internally by the class.
In order to use the class, it is necessary to insert an instance into a panel and configure its current working point in order to reach the required support instance of the tifTCS_PUBLIC or tifTCS_LOCAL database class. For an example of correct usage, see the implementation of the panel tcssimTcsControl.pan in the tcssim module.
2.6 SIMULATION PACKAGE
2.6.1 Introduction
The TCS Simulation Package consists of the TCS (as far as available, except LCU parts) being customized for simulation purposes by means of a special database configuration and the tcssim software module. The package is provided to enable testing instrument software which interacts with the TCS by simulating the relevant parts of TCS. It contains everything needed for the simulation which is not already provided by a standard VLT software environment.
The tcssim module consists of a set of scripts to control the simulation, dummy programs to simulate some not existing or not included TCS modules (e.g. trk) and a database branch, being a sub-set of the real TCS database branch. Further it uses the complete TCS modules for TCS Interface (tif), presetting (prs), tracking (trkws) and mode switching (msw). Later versions of the simulation package will include more TCS modules (complete, replaced by dummies or simulated by command manager) when these will be defined or implemented.
The simulation is focused on the communication between user processes and the TCS and NOT on the internal functionality of the TCS. The simulation allows to send commands to the TCS via the TCS Interface and get replies from there, as well as using the TCS Data Query Library, but internally nothing is done on some commands, except that some database items are updated with simulated values.
The simulation of TCS modules is achieved in general in three ways:
1. A module may not exist at all but is simulated by the command manager. Only the module CDT is needed. In general, this way is chosen for all TCS modules which are not yet implemented.
2. A module may be replaced by a dummy program which accepts the module commands, returns pre-configured replies and provides some simulated data items in the TCS database. This requires that the module CDT and the dummy program are installed. Currently there are such dummies for the tracking LCU part and the adapter module.
3. A module exists and runs in its internal simulation (or normal, if no difference) mode. This requires that the full module is installed. In the current version this is done by the TCS Interface (tif), Tracking Workstation (trkws), Preset (prs) and Mode Switching (msw) modules.
2.6.2 Creating a TCS Simulation Environment
The TCS Simulation Package may run locally, i.e. on the users development workstation, either in the same environment as the instrument application or in a dedicated environment, or it may run on a different workstation.
The following sub-sections will describe the steps necessary to create and configure a separate TCS Simulation environment.
A TCS simulation system requires a WS CCS environment. Although existing environments can be used, we suggest to perform the configuration using new environments. Once you are familiar with that, the integration of the TCS simulation software to an existing environment is a straight forward process.
This section assumes that you master the process of creating/configuring CCS environments, including the directory structure and available tools. (If not, please have a look to the configuration and verification section of [7]).
2.6.2.1 Environment variables.
The following environment variables are used and therefore must be defined:
INS_ROOT
name of the root directory where data dictionaries and configuration files are stored/retrieved (see [6] for the full directory structure). Such directory must exist and will be populated in the next step. Subdirectories needed by the TCS Simulation Package are:
Note that INS_ROOT is also used for instrumentation sw, and it has to be defined and must exist also for TCS.
In the following sections we assume as example that the following definitions are done:
2.6.2.2 vltMakefile and target TCS definitions
The TCS software can be configured to produce software and database for the VLT telescope and for other telescopes (currently the NTT, the Astronomical Site Monitor and the VLT Auxiliary Telescopes are foreseen).
This must be configured in the makefile using the TARGET_TCS symbol.
By default, software for the VLT is built (but warnings are issued if the TARGET_TCS is not explicitly defined).
It is anyway cleaner and safer to explicitly define the TARGET_TCS.
In the case of the VLT, this must be set to VLT_TCS and passed explicitly to the C compiler and to dbl.
A typical Makefile will contain the following definitions:
# The following variable is used to define the target telescope:
# Programs require the preprocessor variable TARGET_TCS set to VLT_TCS
# or to NTT_TCS to distinguish between the two.
# To pass the TARGET_TCS to the C compiler
USER_CFLAGS = -DTARGET_TCS=${TARGET_TCS}
DBL_FLAGS = -DTARGET_TCS=${TARGET_TCS}
A standard environment variable that is defined is TCSID.
It defines for which of the UTs the software has to be configured.
TCSID can only be used for database configuration and user interface configuration.NOTE: It must NOT be used in code!!
TCSID can take the values 0,1,2,3,4,5. Where 0 stands for the VLT control model and 5 for the NTT. 1 to 4 defines the UT.
It can be used e.g. in user interfaces to genereate the environment name like lt$(TCSID)alt, etc.
2.6.2.3 Files needed for TCS operations
To install all files needed for operation of the TCS simulation system run from the UNIX shell:
Note: The Data Dictionary is still subject to review. There might be changes in a future release.
2.6.2.4 WS Environment
1. Create a new environment as in 4.3.2 in [7]. Remember, the environment shall be named as in $RTAPENV. Do not forget to properly configure /etc/services, /etc/$RTAPROOOT/RtapEnvList, etc.
5. Verify that the needed processes are running in the CCS environment (use RtapPerfMon for verification):
Proc Name pid prio %cpu qid rx #msg bytes debug select
1 RtapScheduler 18102 NRT . 1217 . . . . ..
2 RtapMonitor 18104 NRT . 1218 . . . . ..
3 RtapQServer 18105 NRT . 1219 . . . . ..
4 RtapEventTrig 18106 NRT . 1220 . . . . ..
5 RtapEventConfg 18107 NRT . 1221 . . . . ..
6 RtapTimeKeeper 18108 NRT . 1222 . . . . ..
9 RtapDbCfServer 18115 NRT . 2524 . . . . ..
10 RtapScanMngr 18116 NRT . 1225 . . . . ..
11 ccsScan 18124 NRT . 1231 . . . . ..
12 cmdManager 18121 NRT 1 2527 . . . D ..
13 msgServer 18117 NRT . 1226 . . . . ..
15 RtapASServer 18119 NRT . 1228 . . . . ..
16 RtapASLogger 18120 NRT . 1229 . . . . ..
58 RtapMQDBM 18112 NRT . 2523 . . . . ..
2.6.2.5 Verification
To verify the installation and configuration, execute the following steps:
panels:
Start the TCS Simulation Control panel tcssimSimControl. From there start the TCS Control, TCS User and Adapter User panels.
scripts and processes:
From the TCS Simulation Control panel select simulation setup 3 and start/stop it.
2.6.3 Using a TCS Simulation Environment
In order to allow applications to use a TCS Simulation Environment, as well as to interface to the real VLT TCS, i.e. to send commands to TCS and to use the tif libraries to access TCS data, it is necessary to specify the environment name, the mount point of the database branch by setting three shell environment variables and to set one database attribute:
TCS_ENVNAME specifies the CCS environment name in which to run the simulation package. If not set, the value of the RTAPENV environment variable will be used, assuming that TCS is running on the same environment of the user application. This will NOT be the normal case, so it is suggested to always set properly this environment variable, also during testing and development.
TCS_DBPOINT specifies the absolute path of the TCS simulation database branch. If not set the default ":Appl_data:TCS" value is used. This should be the normal case and, except for special testing purposes, it should not be necessary to explicitly set this environment variable. If set, it must point to an instance of the tcssimDB on-line database class.
Typically such and instance is declared in the database configuration file for the environment in the following way:
#include "tcssimDB.class"
POINT tcssimDB ":Appl_data:TCS"
BEGIN
ALIAS "TCS"
END
TCSGAENV specifies the CCS environment name of the Guide Acquisition environment. If not set,
the value of the RTAPENV environment variable will be used, assuming that the Guide Acquisition tasks (CCD) are running in the same environment as the application.
$(TCS_DBPOINT):msw:foc.currentFocus must be set to a valid focus value before starting any TCS application. Valid values are: 2 = Nasmyth A, 3 = Nasmyth B, 4 = Cassegrain. The default value is 0, which means undefined.
The simulation start-up scripts temporarily sets the RTAPENV environment variable to TCS_ENVNAME to start the simulation processes in the desired environment and restores the original value afterwards.
Also the environment variables for setup file handling must be properly set (see the section 2.6.2.1 for details).
The shell environment variable CCSSTATE must be set to SIMULATION.
NOTE: THE USER MUST MAKE SURE THAT THESE ENVIRONMENT VARIABLES ARE PROPERLY SET FOR ALL USER PROCESSES WHICH ACCESS THE TCS. PAY ATTENTION TO THE VISIBILITY SCOPE OF ENVIRONMENT VARIABLES in SUB-SHELLS, PARENT-SHELLS, SPAWNED PROCESSES, etc.
2.6.4 Tracking Simulation
The tracking module consists of a workstation part (trkws) and a LCU part (trk). In simulation the trkws is used in normal mode since it has no special handling of module simulation mode, and the trk is replaced by a dummy program, on the workstation, which incorporates no functionality except updating the "actual position" data items with the values received in command parameters. Note that this information is static; no tracking motion is simulated!
If a command specifies coordinates as RA/DEC, the corresponding hour angle and ALT/AZ coordinates are computed, and vice versa. Thus, the current positions which are returned by the Data Query Library always consistently reflect the status at the time when the last preset or offset command was given.
The local sidereal time is simulated with the current UTC.
2.6.5 Data and Event Simulation
The TCS Data Query and Event Configuration Libraries are available also in simulation mode, however the data items are maintained only with setup 3 (see section 2.6.6), where some data items are maintained with simulated values and some are set to fixed values.
The following data items are provided by the Data Query Library in simulation:
· The Module States Data Structure tifSTATES, returned by tifGetStates() provides the TCS global state and sub-state as in normal operation (msw and trkws modules runs in normal mode). Hence, the state information is as reliable as in normal mode and can be used by instruments to detect if the TCS runs properly.
· The Telescope Position Data Structure tifPOSITION, returned by tifGetPosition(), is filled with simulated position values, which are written to the database by the tracking module dummy.
The table below shows how the named data items are handled in simulation mode. See also Table 3: for a description of the named data items.
The TCS event library works as in normal mode, i.e. events are attached to the same database attributes as in normal mode, and those are maintained as in normal mode.
A special TCS simulation database branch is delivered with the simulation package as the tcssimDB database class. It is a sub-set of the original TCS database branch, i.e. it contains only the points and attributes which are needed for simulation but those are identical with the original structure, names and data types.
Database items not updated by the simulation software can be manipulated by hand (if necessary) by the user to test special behaviors.
To this purpose, it is necessary to keep in mind that:
· The TCS Simulation assumes that only the ALT and AZ LCUs are used for tracking (this is configured in the Simulaiton Mode Switching List)
· Writing in an LCU attribute correpsond to simulate the scan system of the true TCS going and picking up the values from the actual LCU.
For example, in order to set a specific vaule for the ramaining tracking time, it is just necessary to write the required value in the following database attributes:
@TCSENV:Appl_data:TCS:LCU:alt:trk.remTrkTime
@TCSENV:Appl_data:TCS:LCU:az:trk.remTrkTime
For this purpose, the dbWrite command line utility or any database write tool can be used.
dbWrite @wt0tcs0:Appl_data:TCS:LCU:alt:trk.remTrkTime 0.1
dbWrite @wt0tcs0:Appl_data:TCS:LCU:az:trk.remTrkTime 0.1
2.6.6 Simulation Setups
The TCS Simulation Package provides various setups, differing in what amount of software has to be installed on the target workstation and in degree of simulated functionality. Each setup simulates the whole TCS; all commands are always accepted.
The following setups are delivered:
More setups will be added or the setup 3 will be extended as more TCS modules become available.
For each setup, bourne-shell scripts are provided to start, check and stop the simulation. These are named:
See section 3.7 for man-pages of these scripts.
2.6.6.1 Setup 1
The Simulation Setup 1 implements the lowest level approach where the tif is simulated by the command manager and nothing else of TCS exists. This setup contains:
· a script tcssimStartSetup1 to switch the TCS environment into command simulation and tell the command manager to simulate the tif instances
· a script tcssimStopSetup1 to shutdown the simulation setup and bring the TCS environment back to normal mode.
This setup is provided to verify the basic communication channel between an instrument application and the tif, but it is not sufficient to test any functionality.
The command manager replies whatever is defined in the CDT of the simulated module (here the tif) under keyword DEFAULT_REPLY. This is set to "OK" for all commands by default. The user can change the behaviour by either
It is not feasible to access the TCS Data Query Library or the Event Configuration Library in this setup. The data items are fixed and not updated with simulated values. The same for the Event Configuration Library: it is available but the events will never be triggered!
2.6.6.2 Setup 2
In setup 2 the tif exists and all TCS modules for which CDT's are available are simulated by the command manager. This setup contains:
· a script tcssimStopSetup2 to shutdown the simulation setup and bring the TCS environment back to normal mode.
In this setup the TCS internal routing of commands really takes place and thus can be used to verify aspects of command validity, consistency between CDT's and tif routing table, some aspects of command and reply timing (sequence, performance, etc.). It is possible to access the TCS Data Query Library, however the data items are fixed and not updated with simulated values. The same for the Event Configuration Library: it is available but the events will never be triggered.
2.6.6.3 Setup 3
This setup provides the most realistic behaviour of the TCS. The TCS Interface, Mode switching, Preset and Tracking WS modules are running in their normal mode (there is no special handling of simulation mode in these modules). The Tracking LCU and the Adapter modules are replaced by dummies on the WS (no LCU's are involved in simulation mode) and the Autoguiding and Field Stabilization module is simulated by the command manager.
· a script tcssimStopSetup3 to shutdown the simulation setup and bring the TCS environment back to normal mode.
This is the setup providing the highest degree of simulated TCS functionality.
2.6.7 Instruction Sequence
This section describes the steps to be performed to start-up a TCS simulation scenario. It is important to keep the sequence described below. NOTE: THESE INSTRUCTIONS MUST BE GIVEN TO A BOURNE SHELL OR EXECUTED AS A BOURNE SHELL SCRIPT!
1. If the environment where TCS should run does not yet exist, create it (see [3], section 2.4 for instructions on how to create an environment).
3. Define the shell environment variables used for setup file handling INS_ROOT, INS_USER and INS_SETUPPATH as described in section 2.6.2.1.
4. Define the shell environment variables TCS_ENVNAME and TCS_DBPOINT as described in section 2.6.2.
5. Execute the appropriate start-up script tcssimStartSetupN, N=1,2,3 or use the tcssimSimControl panel
8. Shutdown the simulation setup by running the appropriate shutdown script tcssimStopSetupN, N=1,2,3 or use the tcssimSimControl panel
2.6.8 Commands
This section gives a list of the public TCS commands supported by the TCS simulation package, and a description of what they are doing in simulation mode. See the Reference chapter, section 3.2 for a general description of these commands.
In the tables below the entries in column "Effect" mean:
normal action: the corresponding process is the real one and runs in normal mode (or in simulation mode, but executing this command as in normal operation).
default reply: the corresponding process is simulated by the command manager and the command causes just the return of a default reply, normally "OK".
(*) available only for Nasmyth adapters, i.e. these commands are rejected for the Cassegrain adapter.
2.6.9 PANELS
Several panels to communicate with the TCS are delivered as part of the simulation package:
An example of a Telescope User Panel, i.e. a panel providing all user commands currently available for telescope control.
An example of an Adapter User Panel, i.e. a panel providing all user commands currently available for adapter control.
The Data Monitor Panel displays the position and time data which can also be acquired by the Data Query Library.
2.6.9.1 Simulation Control Panel
A panel is provided to control the execution of simulation setup's and to start other TCS panels. The name of this panel if tcssimSimControl. In detail it allows to:
· select terminal mode (for setup 2 and 3 only), i.e. if each TCS process shall be run in an individual xterm window or not. This is mainly for debugging purposes and allows the user to analyse the output produced by the TCS processes.
The Simulation Control Panel is started by just entering:
from a shell. Since all other panels provided with the package can be started from here, the Simulation Control Panel should serve as the main entry to the TCS simulation control and monitoring.
First select a setup type with the radio button. If you want to have the output of each process in an individual xterm window then enable the "xterm" check-box.
After these selections start the setup with the START button and check if all processes are active, by using the PING button.
Now you can pop-up further panels: the TCS operator panel, an example of a Telescope User Panel and an example of an Adapter User Panel.
Stop the setup with the STOP button.
The START, STOP and PING actions require some time and during this time the panel is blocked and does not provide any feedback. Please wait for the completion of the command (about one minute) for the panel to become active again. Depending on the selected options, a feedback is given when operations are completed as an xterm or as an TCL text panel. The xterm closes automatically when the operations are completed, but the TCL text panel must be closed by hand selecting the File/EXIT menu. Please, do not use the Close option in the window frame, since this will leave the main panel in an inconsistent state.
These are known limitations and will be solved in a next release.
2.6.9.2 TCS Operator Panel
The TCS operator panel allows to switch the TCS global state by sending operator level commands to the mode switching module, which dispatches appropriate state transition commands to the other modules.
The panel is started by entering
The following state transitions are supported by buttons:
The following mode switching commands are supported by button:
CHANGE FOCUS: Changes the current focus station (one of Nasmyth A, Nasmyth B, Cassegrain). TCS must be in STANDBY
SELECT INS: Changes the current instrument and, if necessary, move to the corresponding focus station. TCS must be in STANDBY.
Further, the panel displays the current TCS global state in the form of:
In the lower part, the Data Monitor shows those positions and times which are also provided by the TCS data query library.
At the very bottom there is a scroll-list which receives the replies to all commands sent from the panel.
2.6.9.3 Telescope User Panel
This panel provides an example for a user having the full TCS, i.e having the telescope beam. It supports many (but not all) of the commands available for the current TCS version.
The panel is started by entering
from a shell, where [tif] is an optional argument, specifying the tif instance to be connected to. The default is tifNA. The panel expects the TCS simulation already running in the environment specified by TCS_ENVNAME (see section 2.6.2) or in the environment specified by RTAPENV if TCS_ENVNAME is not defined.
The panel consists of combinations of entry fields for command parameters and push buttons which send the corresponding command to the selected tif instance.
In the lower part the push button "Data Monitor" pops-up the Data Monitor panel which shows those positions and times which are also provided by the TCS data query library.
At the very bottom there is a scroll-list which receives the replies to all commands sent from the panel to the selected tif instance.
2.6.9.4 Adapter User Panel
This panel is for use of only an adapter. It supports all adapter commands available for the current TCS version.
The panel is started by entering
from a shell, where [tif] is an optional argument, specifying the tif instance to be connected to. The default is tifNA. The panel expects the TCS simulation already running in the environment specified by TCS_ENVNAME (see section 2.6.2) or in the environment specified by RTAPENV if TCS_ENVNAME is not defined.
The panel consists of combinations of entry fields for command parameters and push buttons which send the corresponding command to the selected tif instance.
At the very bottom there is a scroll-list which receives the replies to all commands sent from the panel to the selected tif instance.
2.6.9.5 Data Monitoring Panel
The Data Monitoring Panel shows the telescope position in various coordinates as well as the related UTC and LST. It is a display panel only which provides no action. The panel is imported as a class in the TCS Operator panel (see 2.6.9.3) and can be called from the Telescope User panel (see 2.6.9.4).
The panel is started by entering
from a shell. The panel expects the TCS database branch in the environment specified by TCS_ENVNAME (see section 2.5.2) or in the environment specified by RTAPENV if TCS_ENVNAME is not defined and under the point specified by TCS_DBPOINT, defaulted by ":Appl_data:TCS:".
2.7 STAR CATALOG INTERFACE
The Star Catalog Interface is based on an external package, called catlib, implementing a set of three libraries with the same functionalities, but supporting different programming languages:
The current implementation of "catlib" provides access to the "guide star catalog" ("gsc@eso"), but only for a limited set of functions:
The description on how to use the "catlib" functions is in document ref. [10]. This document also describes a number of functions that are not yet implemented. They will be included in a future release.
The VLT Star Catalog Interface (the module is called "catif") provides a function, called catifErrAdd, to interface the errors generated by "catlib" to the VLT error system.
For the time being the "catlib" routines do not provide the user a detailed error handling, but just the indication whether the routine was successful or not and in that case they provide a simple description of the error.
catif also provides a set of errors which are VLT standard compliant: see paragraph (5.3.1) or use the error editor utility in "Read Only" mode (they should be reviewed as soon as the star catalog library improves).
NOTE: Programs using catifErrAdd must be linked with C++ library.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|
