| |
|
|
|
6 CONFIGURATION GUIDE
6.1 INTRODUCTION
The instrumentation software has a special software module (xxmcfg) that contains all configuration files related to the instrument. This software module allows to keep the complete configuration in one central location and under strict configuration control.
The xxmcfg module contains a.o. the configuration for the startup tool that is shared with Base ICS and BOSS. This chapter describes the configuration keywords used by the startup tool and explains how to update and test the configuration changes. For a more detailed description of the shared configuration, please refer to the Base ICS User Manual [25] and BOSS User Manual [24].
6.2 CONFIGURATION FILES
The instrument configuration is located in a set of files stored in the xxmcfg module. The startup tool uses the following files:
· xxmcfgCONFIG.cfg: a PAF file that contains the basic information of the INS and START configuration sets. See the Config. Tool User Manual [23] for details.
· xxmcfgSTART.cfg: a PAF file that contains keywords that may be updated by the startup panel. This file is owned by the xxxxmgr, but should have g+w permission to allow the normal instrument user xxxx to update the file.
6.3 FROM THE CONFIGURATION FILES TO THE RUNNING SYSTEM
When the instrumentation software is installed, the configuration files are placed inside the INS_ROOT, in the directory: $INS_ROOT/SYSTEM/COMMON/CONFIGFILES.
The startup panel retrieves the instrument name, number of detectors and detector names from the INS configuration set (mainly the xxmcfgINS.cfg file). The other keywords are retrieved from file xxmcfgSTART.cfg and displayed in the panel. The user can update these values and store them back in the xxmcfgSTART.cfg file; this is also automatically done when the panel START button is pressed, before calling the xxinsStart utility.
Utilities xxinsStart and xxinsStop retrieve first file xxmcfgINS.cfg, then add the keywords in file xxmcfgSTART.cfg to it's internal configuration buffer. The combined data of both files is used to build an internal representation of the instrumentation software (applications, panels and processes), that is used to start resp. stop the software according to the arguments passed to the utility.
6.4 DESIGN CONFIG. PARAMETERS VS. NORMAL CONFIG. PARAMETERS
The configuration files store two types of parameters:
6.4.1 Design Config. Parameters
The design config. parameters have values that are not only stored in the configuration files themselves, but they are also stored (or hardcoded) in the OLDB structure or in the instrument specific part of the instrumentation software. These parameters are set when the instrumentation software is designed, and can not be modified later on without also modifying and reinstalling the control system. I.e., in practice, the design config. parameters are not allowed to be modified once the control system is in operation. As a consequence, the xxmcfgSTART.cfg file should not contain any design config. parameters.
Example: The detector name (OCS.DETi.CCDNAME).
Each detector has an associated OLDB point. The alias name of this point has to be the name of the detector. E.g. the detector `ccdXxxx' has an associated OLDB point with alias `ccdXxxx'. As the detector name is `hardcoded' into the OLDB, it is not allowed to modify this config. parameter. If it is modified, then the OLDB has to be rebuilt.
6.4.2 Normal Config. Parameters
The values of normal config. parameters can be updated at any time. ICS reads the updated values when the ICS WS processes are started, resp. when the ICS LCUs are rebooted. Some normal config. parameters are marked as Calibration Config. Parameters, when they are expected to be updated during calibrations.
6.5 UPDATING AND TESTING THE STARTUP CONFIGURATION
6.5.1 Updating Design Config. Parameters
If you need to update design config. parameters (see section 6.4.1 above), then please refer to the tutorial, section 5.5. Basically, the update has to be done as follows:
Only the responsible software developer is allowed to update design config. parameters!
6.5.2 Updating Normal Config. Parameters
Assuming that the control system is installed and running, the procedure to update normal config. parameters and test the updated configuration is as follows:
2. If file xxmcfgINS.cfg has been updated and the instrument is based on BOSS and/or Base ICS, then distribute the updated configuration:
6. Save the new configuration in the xxmcfg module (replace `xx' with the prefix of your instrument!):
6.6 THE xxmcfgINS.cfg AND xxmcfgSTART.cfg FILES
The xxmcfgINS.cfg file is a PAF file that contains the FITS keywords that describes the instrument. All standard configuration FITS keywords are listed in the dictionaries ESO-VLT-DIC.OSB_CFG, ESO-VLT-DIC.ICB_CFG and ESO-VLT-DIC.STOO_CFG. The xxmcfgINS.cfg file may also contain instrument specific FITS keywords: these are not explained here; if the instrument needs these keywords, then they are described in the instrument specific User's and Maintenance manuals.
Most config. keywords are stored in file xxmcfgINS.cfg. The xxmcfgSTART.cfg file contains only a subset of config. parameters that may be used to customize the startup procedure (see section 6.15). Most of the parameters stored in the xxmcfgSTART.cfg file are updated with the startup panel (xxinsStartup).
The standard startup configuration FITS keywords are grouped as follows:
Apart from the START.* keywords, all other keywords are shared with either BOSS (OCS.*) or ICS (INS.*). Some of these shared keywords are listed below for reference, although the startup tool does not use them. These keywords are marked with italic. The next sections describe the above groups.
6.7 GENERAL STARTUP AND INSTRUMENT CONFIGURATION
6.7.1 Startup Application Type
To start Instrumentation Software, this value should be set to value "INS".
6.7.2 Instrument Identifier
The instrument identifier (e.g. `UVES', represented with `XXXX' in this document) is widely used in the instrumentation software to identify files, processes and data items. In the ICS OLDB, the instrument identifier is used as the alias for the instrument OLDB point :Appl_data:XXXX.
6.7.3 Software Module Prefix
The software module prefix are the two first letters of the instrumentation software modules (e.g. `uv', represented with `xx' in this document, see section 2.2). This value should be defined in agreement with ESO (vltsccm@eso.org), as the corresponding software modules names, derived from the prefix, must be available in the Software Archive. The software module prefix is usually selected to be the same as the network subnet name assigned to the instrument, as listed in [12], section 5.1. For obvious reasons, once selected, the software module prefix can not be modified.
6.7.4 Instrument Workstation Environment
The instrument workstation environment should have the same name as the instrument workstation itself. The name of the instrument workstations are listed in [12], section 5.3.
6.7.5 Startup Application Name
Main application name displayed by the startup tool.
If the application type is "INS" (see below), then the default is the value of keyword INS.CON.ID, therefore normally this keyword does not need to be specified.
6.7.6 Start Application if Panel is Started
If an ICS or OS panel is started (with e.g. xxinsStart -panel <name>), then the corresponding application is started if it is not already running. During development, this feature can be suppressed setting the START.CON.STARTAPP to "F". Default: "T".
6.7.7 Send STANDBY Command to Applications
Normally, a STANDBY command is sent to an application when it is started and stopped. If the START.CON.STBYAPP keyword is set to "F", then the STANDBY command is suppressed when an individual application is started (xxinsStart -proc <appl>) or stopped (xxinsStop -proc <appl>). Default: "T".
6.7.8 Instrument Specific Startup Code
This keyword is only needed, if instrument specific startup TCL code is needed, i.e. if the instrument is using packages that already provide their specific code (e.g. STRAP and RTC) or if it has specific features that can't be described only with the configuration keywords. The latter is the case e.g. when the instrument has a specific Observation Software or specific startup conditions. In these cases, the keyword should specify the file that contains the TCL code. It is suggested to always use file stoo/test/stooTclfileExample.tcl as the starting point for the implementation of a specific code or stoo/test/stooTestSpecialICSs.tcl when using STRAP, RTC or any other package that already provides its specific code. See section 7.2 for more details.
6.7.9 MIDAS Available Flag
If MIDAS is needed in the instrument WS, then flag START.MIDAS.AVAIL should be set to `T'. Default: "F".
6.8 OS GENERAL CONFIGURATION
The keywords described below are shared with BOSS [24]. If file xxmcfgINS.cfg already contains these configuration keywords, then this section can be skipped.
6.8.1 Release Date
Instrumentation Software release date in format "yyyy-mm-dd".
6.8.2 Origin
Instrument location. For Paranal, use the value: "ESO-PARANAL".
6.8.3 Logging Level
This is the Log Level that controls the level of detail logged in the startup window and the standard logs which are stored into the standard VLT log file by BOSS. The BOSS server initializes with this value when it starts. Valid range is: 0-5. Default: 0, i.e. minimum logging.
6.8.4 Start OS Application on start-up
By default, the OS application (if exists) is always started, unless this optional keyword has the value `F'. It may be useful to set it to `F' during development, while OS does not exist.
6.8.5 Flag indicating if OS exists
This keyword is used for instruments/facilities that do not have an OS, e.g. LGSF. If it is set to `F', that means that OS does not exist. In this case, keywords OCS.CON.DEFAULT, START.OSCTRL.DEFAULT/AVAIL and START.OSSTAT.DEFAULT/AVAIL are ignored by the startup tool. Note: Although these keywords are ignored, it is recommended to have them set to `F' for easier understanding of the instrument configuration.
6.9 TCS SUBSYSTEM CONFIGURATION
The keywords described below are shared with BOSS [24]. If file xxmcfgINS.cfg already contains these configuration keywords, then this section can be skipped.
If BOSS/OS does not need to access any TCS directly, then these keywords are not needed. The startup script will not start TCS, it will only verify that the environment variables have the correct values to access the configured TCS (e.g. env. var. TCSID).
6.9.1 Telescope UT Number
VLT telescope name: UT0 (Control Model), UT1, UT2, UT3 or UT4. The value of variable TCSID is derived from the value of this keyword, e.g. UT3 -> TCSID=3.
6.9.2 Telescope Focus
Telescope focus where the instrument is mounted in the telescope:
6.9.3 TCS Access Mode
Mode how TCS is accessed by BOSS/OS. The possible values are:
· IGNORE: TCS is ignored. All requests to the server are ignored, but considered as successfully completed.
The startup panel uses only values NORMAL and IGNORE.
6.9.4 TCS Server Process Name
If the server process name is not specified, then value `tif<OCS.TEL.FOCUS>' is used. This is the value needed to access the VLT UT1-UT4 telescopes.
6.9.5 TCS Environment Name
If the environment name is not specified, then value `wt<number from OCS.TEL.NAME>tcs' is used, e.g. OCS.TEL.NAME="UT2" gives OCS.TEL.ENVNAME="wt2tcs". This is the value needed to access the VLT UT1-UT4 telescopes.
6.9.6 TCS Command Timeout
Timeout in seconds for commands sent to TCS.
6.10 ICS SUBSYSTEM CONFIGURATION
The keywords described below are shared with BOSS [24] and Base ICS [25]. If file xxmcfgINS.cfg already contains all these configuration keywords, then this section can be skipped.
It is assumed that the name of the WS simulation process is xxiSimControl.
6.10.1 Number of ICS Subsystems
Number of ICS subsystems that BOSS will access directly. Normally only one ICS is accessed directly, but the standard startup panel supports also multiple ICSs.
6.10.2 ICS Name
ICS name, normally the same identifier registered in INS.CON.ID should be used (unless several ICSs are present).
6.10.3 ICS Access Mode
Mode how ICS is accessed by BOSS/OS. The possible values are:
· IGNORE: ICS is ignored. All requests to the server are ignored, but considered as successfully completed. The startup script does not start the ICS application.
· FORBIDDEN: ICS is not available. All requests to the server are rejected. The startup script does not start the ICS application.
The startup panel uses only values NORMAL and IGNORE.
6.10.4 ICS Simulation Mode
The initial ICS simulation mode is set with the INS.CON.OPMODE keyword (INSi.CON.OPMODE if i > 1 i.e. for multiple ICSs).
· LCU_SIM: LCU simulation, commands are simulated in the instrument workstation. Select this option, if you do not have any instrument LCU.
If this keyword is not present, the simulation level is set according to the value of the OCS.INSi.SWSIM keyword (NORMAL, LCU_SIM or HW_SIM), if given. Default: NORMAL.
6.10.5 Start ICS Stand-alone Panel
If this flag is T, then the ICS stand-alone panel (xxipanControl) is started by the xxinsStart script. If the panel name is other than xxipanControl, set it with the INSi.UIF.NAME keyword (note: INS.UIF.NAME for the first ICS).
6.10.6 ICS Server and Environment Name
If no ICS server name is specified, then the name "xxiControl" is used, as needed by Base ICS.
The default for the environment is the value stored in keyword: INS.CON.WSENV.
6.10.7 ICS Command Timeout
Timeout for commands sent to ICS.
6.10.8 ICS Local Flag
If the local flag is T, then the startup script starts ICS and BOSS forwards state change commands (ONLINE, STANDBY and OFF) to ICS. If the flag is F, then it is assumed that the subsystem is managed by another OS: the startup script does not start the subsystem and BOSS does not forward state change commands to it. The default is T.
6.10.9 ICS State OLDB Attribute Location
Location of the ICS state OLDB attribute. The default is the location used by Base ICS.
6.10.10 ICS Dictionary and Alias File
FITS dictionary and FITS alias file associated to ICS. If no dictionary and/or alias file is specified, then `<INS.CON.ID>_ICS' is used (for both keywords).
6.10.11 ICS Keyword Filter
The keyword filter is a list of filters (separated by comma without blanks) that specify the FITS keywords accepted by ICS. Wildcards are allowed. The default list is: "INS.*,INS.*.*".
6.10.12 Start ICS Application on start-up
By default, the ICS application is always started, unless this optional keyword has value `F'. This keyword may be useful during development, while ICS does not exist.
6.11 DCS ACE AND FIERA SUBSYSTEM CONFIGURATION
The keywords described below are shared with BOSS [24]. If file xxmcfgINS.cfg already contains all these configuration keywords, then this section can be skipped.
Keyword OCS.DET.NUM specifies the number of detectors (all types). A separate set of OCS.DETi.* keywords has to be supplied to describe each detector (OCS.DET1.*, OCS.DET2.*, ...).
6.11.1 Number of DCS Subsystems
Number of DCS subsystems that BOSS will access directly. The standard startup panel supports up to 4 detectors.
6.11.2 DCS Name
Name used to identify the DCS.
6.11.3 DCS Type
There are different standard detector types used at the VLT. The startup tool supports the following types:
For IRACE CCDs, refer to section 6.12.
6.11.4 DCS Associated Camera Name
The DCS software identifies a detector with a camera name, normally stored in the CCDNAME environment variable. This name should be registered in the OCS.DETi.CCDNAME keyword.
6.11.5 DCS LCU Environment
Environment name of the LCU (or FIERA SPARC workstation) that controls the detector hardware.
6.11.6 DCS OLDB Configuration File
Each individual detector has an associated detector OLDB configuration file. This entry is only used when the detector control system is installed.
WARNING: ALWAYS USE THE RIGHT CONFIGURATION FILE ASSOCIATED TO THE DETECTOR. USING THE WRONG CONFIGURATION CAN DESTROY THE DETECTOR.
6.11.7 DCS Access Mode
Mode how DCS is accessed by BOSS/OS. The possible values are:
· IGNORE: DCS is ignored. All requests to the server are ignored, but considered as successfully completed. The startup script does not start the DCS application.
· FORBIDDEN: DCS is not available. All requests to the server are rejected. The startup script does not start the DCS application.
The standard startup panel uses only values NORMAL and FORBIDDEN.
6.11.8 DCS Simulation Mode
The initial DCS simulation mode is set with the INS.CON.OPMODE keyword.
· LCU_SIM: LCU simulation, commands are simulated in the workstation. Select this option, if you do not have any detector LCU.
The standard startup panel uses only values NONE and LCU_SIM.
6.11.9 Start DCS Stand-alone Panel
If this flag is T, then the DCS stand-alone panel is started by the xxinsStart script.
6.11.10 Start DCS related RTD
If this flag is T, then an RTD attached to the detector is started by the xxinsStart script.
6.11.11 DCS Server and Environment Name
By default, the DCS server name is selected according to the supplied detector type (OCS.DETi.TYPE) and camera name (OCS.DETi.CCDNAME). Default for FIERA is "fcdconCI_$OCS.DETi.CCDNAME", while for ACE is "ccdconCI_$CCDNAME".
The default environment is the value stored in keyword: INS.CON.WSENV.
6.11.12 DCS Command Timeout
Timeout for commands sent to DCS.
6.11.13 DCS State OLDB Attribute Location
Location of the DCS state OLDB attribute. By default, the location of the standard DCS software is used.
6.11.14 DCS Keyword Filter
The keyword filter is a list of filters (separated by comma without blanks) that specify the FITS keywords accepted by DCS. Wildcards are allowed. The default list is: "DET.*,DET.*.*".
6.11.15 DCS World Coordinate System
This keyword stores an array of 6 values, that define the world coordinate system of the detector:
"<xrefpix> <yrefpix> <secpix> <rotate> <equinox> <epoch>".
If the OCS.DETi.WCS keyword is used, then all 6 values must be supplied.
6.11.16 Start DCS Application on start-up
By default, the DCS application is always started, unless this optional keyword has value `F'. This keyword may be useful during development, while DCS does not exist.
6.11.17 Stop DCS Application on shutdown
Normally, the DCS application is always stopped by xxinsStop, unless this optional keyword has value `F'. This may be useful, if the detector needs to stay continuously wiping.
6.11.18 DCS Min. Free Disk Space
Minimum amount of free disk space in directory $INS_ROOT/SYSTEM/DETDATA for which OS will accept the START command. If the free disk space is less, than the START command is rejected.
6.11.19 FIERA Image Directory
For FIERA only, it is possible to specify location where the images for the given detector are saved. This option is used, for example, when we want to dedicate a separate disk for each FIERA in order to speed up the image transfer process. If given, the full file path should be given. Environment variables cannot be used in the path. By default FIERA images are saved into directory $INS_ROOT/$INS_USER/DETDATA.
6.12 DCS IRACE SUBSYSTEM CONFIGURATION
The keywords described below are shared with BOSS [24]. If file xxmcfgINS.cfg already contains all these configuration keywords, then this section can be skipped.
Keyword OCS.DET.NUM specifies the number of detectors (all types). A separate set of OCS.DETi.* keywords has to be supplied to describe each detector (OCS.DET1.*, OCS.DET2.*, ...).
6.12.1 Number of DCS Subsystems
Number of DCS subsystems that BOSS will access directly. The standard startup panel supports up to 4 detectors.
6.12.2 DCS Name
Name used to identify the DCS.
6.12.3 DCS Type
There are different standard detector types used at the VLT. The startup tool supports the following types:
For ACE and FIERA CCDs, refer to section 6.11.
6.12.4 DCS Pre-Processor Host Name
Name of the IRACE pre-processor host that controls the detector hardware.
6.12.5 DCS System Configuration File
IRACE system configuration file.
Note: The default detector configuration file used when the IRACE system is placed ONLINE should be registered in the system configuration file using keyword DET.CON.DETCFG.
WARNING: ALWAYS USE THE RIGHT CONFIGURATION FILE ASSOCIATED TO THE DETECTOR. USING THE WRONG CONFIGURATION CAN DESTROY THE DETECTOR.
6.12.6 DCS Access Mode
Mode how DCS is accessed by BOSS/OS. The possible values are:
· IGNORE: DCS is ignored. All requests to the server are ignored, but considered as successfully completed. The startup script does not start the DCS application.
· FORBIDDEN: DCS is not available. All requests to the server are rejected. The startup script does not start the DCS application.
The standard startup panel uses only values NORMAL and FORBIDDEN.
6.12.7 DCS Simulation Mode
The initial DCS simulation mode is set with the INS.CON.OPMODE keyword.
· LCU_SIM: LCU simulation, commands are simulated in the workstation. Select this option, if you do not have any detector LCU.
The standard startup panel uses only values NONE and LCU_SIM.
6.12.8 Start DCS Stand-alone Panel
If this flag is T, then the DCS stand-alone panel is started by the xxinsStart script.
6.12.9 Start DCS related RTD
If this flag is T, then an infrared RTD attached to the detector is started by the xxinsStart script.
6.12.10 DCS Server, Data Transfer Task and Environment Name
By default, the iracqServer and iracqDtt servers are used. If instrument specific servers are needed, then they have to be registered here. If several IRACE detectors are used, then each detector has to be assigned it's own instance. In this case, the OCS.DETi.PROCNAME must have the format: "<server_name>_<instance_number>", e.g. "iracqServer_1".
The default environment is the value stored in keyword: INS.CON.WSENV.
6.12.11 DCS Front End Command Server Port Number
The default port numbers are as follows:
See [21], sections 8.2.1 and 8.2.2 for details.
6.12.12 DCS UIF Plug-In Software Module
The IRACE control panel (iracqCtrl) allows to add user-supplied widgets to it's notebook area. See [21], section 6.8 for details.
6.12.13 DCS Command Timeout
Timeout in seconds for commands sent to DCS.
6.12.14 DCS State OLDB Attribute Location
Location of the DCS state OLDB attribute. By default, the location of the standard DCS software is used.
6.12.15 DCS Keyword Filter
The keyword filter is a list of filters (separated by comma without blanks) that specify the FITS keywords accepted by DCS. Wildcards are allowed. The default list is: "DET.*,DET.*.*".
6.12.16 DCS World Coordinate System
This keyword stores an array of 6 values, that define the world coordinate system of the detector:
"<xrefpix> <yrefpix> <secpix> <rotate> <equinox> <epoch>".
If the OCS.DETi.WCS keyword is used, then all 6 values must be supplied.
6.12.17 Start DCS Application on start-up
By default, the DCS application is always started, unless this optional keyword has value `F'. This keyword may be useful during development, while DCS does not exist.
6.12.18 Stop DCS Application on shutdown
Normally, the DCS application is always stopped by xxinsStop, unless this optional keyword has value `F'. This may be useful, if the detector needs to stay continuously wiping.
6.12.19 DCS Min. Free Disk Space
Minimum amount of free disk space in directory $INS_ROOT/SYSTEM/DETDATA for which OS will accept the START command. If the free disk space is less, than the START command is rejected.
6.13 OS SUBSYSTEMS (INSTRUMENTS CONTROLLED BY AN SOS)
Complex instruments may consist of several `sub-instruments', all controlled from a single SOS (Super-OS) process. E.g. FLAMES consists of two instruments: the Fibre Positioner (FP) and Giraffe (GIRAFFE)1. The control systems of both `sub-instruments' run in the FLAMES instrument workstation. As a consequence, to start the FLAMES instrument, the Startup Tool needs to:
This can be accomplished as follows:
1. Configure each `sub-instrument' as if they were `stand-alone' instruments. Configure the Startup Tool accordingly. As a result, each instrument has its own configuration files, e.g. the Fibre Positioner has config. files: fpmcfgCONFIG.cfg, fpmcfgINS.cfg and fpmcfgSTART.cfg, while GIRAFFE has config. files: fgmcfgCONFIG.cfg, fgmcfgINS.cfg and fgmcfgSTART.cfg. Test that each instrument can be started individually.
2. Configure the FLAMES SOS with its own configuration files (e.g. flmcfgCONFIG.cfg, flmcfgINS.cfg, flmcfgSTART.cfg). Register the sub-instrument OSs with the OCS.OSi.* keywords (see [24] and the first table below). In particular, the OCS.OSi.NAME value must be the instrument identifier, as also registered in the corresponding `sub-instrument' nnmcfgCONFIG.cfg file, CONFIG.SET1.NAME keyword.
The structures of the sub-instruments should be embedded within the structure of the main instrument (e.g. FLAMES)2.
3. Normally, the complete instrument is executed from BOB talking to the SOS (e.g. FLAMES SOS). This BOB is configured with the ~/.bobrc file located in the user account's home directory. To have BOB communicate directly to a sub-instrument OS, it has to be started with a different *.bobrc file. Sub-instruments can place such a *.bobrc file in $INTROOT/config and register it with the START.BOB.CFGFILE keyword in their nnmcfgINS.cfg file.
The main instrument and each sub-instrument has its own logMonitor and alarm panels. To avoid duplications, delete the panels from the sub-instruments setting the START.LOGMON.AVAIL and START.ALARM.AVAIL keywords equal "F" in the corresponding sub-instrument configuration files. Mark other panels as not available, as needed (see second table below).
6.13.1 Number of OS Subsystems
Number of OS subsystems that SOS will access directly.
6.13.2 OS Subsystem Name
Name used to identify the OS subsystem. This name must be the sub-instrument instrument identifier, as registered in the sub-instrument nnmcfgCONFIG.cfg file, CONFIG.SET1.NAME keyword.
6.13.3 OS Subsystem Environment
Environment where the OS subsystem is running. The default value is INS.CON.WSENV. If the OS subsystem is running on a different environment, then it is ignored by the Startup Tool (The Startup Tool assumes in this case that the OS is running on a different workstation).
The keywords specified in the table above are normally used in the sub-instrument configuration files to configure BOB with a specific *.bobrc file and to suppress not needed panels.
6.13.4 BOB Available Flag
Instruments that are controlled from an SOS may not have an associated BOB panel. In this case, set this keyword to `F'.
6.13.5 BOB Stop Flag
Normally any running BOB panels are stopped before a new instance is started. To allow running multiple BOBs, set this keyword to False.
6.13.6 BOB Configuration File
Configure BOB to use the specified *.bobrc file. The file is searched in directory $INTROOT/config.
6.13.7 Panel Available Flags
Alarm panel, logMonitor and OS panels Control and Status (if OS exists) are considered to be available on every instrument by default. Setting the corresponding flag to F, marks the panel as unavailable.
In particular the logMonitor panel should be marked as available in a single instrument only, to avoid that multiple logMonitors are started. MIDAS panel is not available by default.
6.14 INSTRUMENT SPECIFIC PANELS
The standard startup tool configuration expects that an instrument has the following panels:
If an instrument has more panels, then these can registered to allow to start and stop them as any other panel:
For each panel, the following keywords have to be registered:
6.14.1 Panel Name and Description
Name used to identify the panel and description issued when all panels are listed by xxinsStart and xxinsStop.
6.14.2 Panel Executable and Directory
The START.PANELi.EXECMD keyword contains the command to start the panel (including arguments, if needed).
START.PANELi.DIR is an optional keyword that allows to specify the directory where the panel should be started (this is useful, if the panel has e.g. an File->Open... menu option. The panel can be started in the directory where the files are located, to avoid having to search first for the right directory).
6.14.3 Panel Stop Flag
If this flag is T, then any running panels are stopped before starting a new instance (default: F)
6.14.4 Panel Default Flag
If this flag is T, then the panel is started when xxinsStart is called without arguments (i.e. by default).
6.15 STARTUP CONFIGURATION
The xxmcfgSTART.cfg file contains the configuration keywords that can be modified before starting the instrumentation software to adapt the system to the current situation: available subsystems, simulation, panels to be started. Most keyword values can be set from the standard startup panel.
The following keywords should be placed in the xxmcfgSTART.cfg file3:
6.15.1 Panel Default Flags
If one of these flags is T, then the corresponding panel is started when xxinsStart is called without arguments (i.e. by default).
2Only `sub-instruments' that are located in the same WS environment (OCS.OSi.ENVNAME) as the main instrument (INS.CON.WSENV) are considered by the Startup Tool. E.g. UVES is located on a different workstation (-> different WS environment), therefore while UVES is registered in the FLAMES configuration, it is ignored by the Startup Tool (the Startup Tool is not able to start applications on remote workstations).
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|