| |
|
|
|
8 FAQ AND TROUBLESHOOTING
In no particular order, this chapter contains typical questions and problems encountered during the usage of the startup tool.
8.1 CONFIGURATION FILES
8.1.1 Why are there two configuration files: xxmcfgINS.cfg and xxmcfgSTART.cfg ?
Files xxmcfgINS.cfg and xxmcfgSTART.cfg have different file permissions at the target system. File xxmcfgSTART.cfg can be modified by both, the instrument user account (xxxx) and instrument manager account (xxxxmgr); however file xxmcfgINS.cfg can only be modified by the instrument manager account (xxxxmgr). This prevents that the instrument user is able to delete the main instrument configuration stored in file xxmcfgINS.cfg.
8.1.2 What keywords are stored in file xxmcfgINS.cfg, what keywords in xxmcfgSTART.cfg ?
Both files are merged into a single FITS buffer, creating a single set of keywords, therefore it is the same where the information is stored (xxmcfgSTART.cfg values overwrite xxmcfgINS.cfg values, as file xxmcfgSTART.cfg is loaded after file xxmcfgINS.cfg). In practice however, it is recommended to store the complete instrument configuration in file xxmcfgINS.cfg, and to store in file xxmcfgSTART.cfg only the keywords listed in section 6.15 (or only the keywords updated by the xxinsStartup panel).
8.1.3 During development we need to store the configuration in different files (managed by different teams). Is this possible ?
Yes. This manual uses files xxmcfgINS.cfg and xxmcfgSTART.cfg as representation of the INS and START configuration sets. If needed, several files can be assigned to a configuration set. This is configured in the xxmcfgCONFIG.cfg file with the CONFIG.SETi.FILEi keywords. See the Configuration Tool User Manual [23] for more details.
8.1.4 Why does the Configuration Guide describe keywords that are not used by the startup tool ?
Many config. keywords are shared between BOSS, Base ICS, this startup tool and the installation tool pkgin (in particular detector keywords). All keywords of a shared section are shown, to allow a developer to configure the complete section in one pass, without having to look up the same config. section in all other manuals.
8.2 PROCESSES AND PANELS
8.2.1 Some processes and panels of our instrument have different names to the ones expected by the startup tool.
In general, it is recommended (and easier) to use the standard names described in section 2.3.3. This also simplifies the software maintenance of all instruments. If a non-standard name has to be used, then the name of a process or panel can be modified setting the corresponding option as described in section 7.3.2. Modify option -execCmd (see the stooPROCESS or stooPANEL man page), and if necessary option -procName (in case of a process).
8.3 xxinsStart (stooStart)
8.3.1 We only need to start ICS, however xxinsStart insists in starting also OS and DCS by default (when xxinsStart is called without arguments). Can this be suppressed ?
Yes. Set the config. keywords OCS.CON.DEFAULT and OCS.DETi.DEFAULT to `F'. See section 6.15 for details.
8.3.2 Startup tool does not start the ICS process. What could be wrong?
Insure that keyword OCS.INSi.DEFAULT is set to `T' (default).
8.3.3 Can we also select what panels to start by default ?
Yes. Set the config. keywords OCS.INS1.STRTUIF, OCS.DETi.STRTUIF, OCS.DETi.STRTRTD and keywords START.*.DEFAULT according to your needs. See section 6.15 for details.
8.3.4 Sometimes when a panel is started, the corresponding application is started. Can this be suppressed during development ? Can we suppress sending the STANDBY command to applications when they are started/stopped ?
Yes, use config. keywords START.CON.STARTAPP and START.CON.STBYAPP. See section 6.7 for details.
8.3.5 Environment variables are not passed to the started processes! What is going on ?
If you defined environment variables after starting the WS environment and these are needed by the processes started, then you have to stop and restart the WS environment (with vccEnvStop/vccEnvStart).
Normally, processes are started with msgSchedule. msgSchedule sends a command to the msgServer, that starts the process. Therefore processes inherit the environment variables known to the msgServer, i.e. the environment variables available when the WS environment was started.
8.3.6 There are three ICSs in my instrument. I overloaded the first one, i.e. stooType(ICS), but it seems that the other ICSs are overloaded as well! What is going on ?
For back compatibility reasons, class specified with stooType(ICS), the default is stooICS, is the one used by all ICSs that do not have specific startup code. So, for example, if the instrument has three ICSs and the first ICS is overloaded, then the classes for the other two ICSs should also be explicitly specified, i.e.:
8.4 xxinsStop (stooStop)
8.4.1 Sometimes panels are not stopped by xxinsStop.
xxinsStop can only stop panels that have been started with xxinsStart. Panels started directly `by hand` are normally not touched.
8.4.2 Our instrument specific panel is never stopped.
A panel is started calling the command registered in START.PANELi.EXECMD. The startup tool registers the PID of this command when it is executed. To stop a panel, xxinsStop kills the process with this PID. If the command registered in START.PANELi.EXECMD is not the panel itself, but e.g. a script that in turn starts the panel, then xxinsStop will never stop the panel, because the registered PID belongs to the script (that finished after starting the panel).
If the script calls the panel with:
then the script should be changed to call the panel at the end of the script using the command exec:
8.4.3 Our detector should always stay ONLINE, but it is always stopped by xxinsStop.
Set the config. keyword OCS.DETi.STOP to `F' and make sure that OS does not place the detector in state STANDBY when it receives the STANDBY command (the first step of xxinsStop, is to send the STANDBY command to OS).
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|