Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://curl.sai.msu.ru/mass/download/doc/sv_ug.pdf Äàòà èçìåíåíèÿ: Mon Mar 22 12:27:50 2004 Äàòà èíäåêñèðîâàíèÿ: Mon Oct 1 20:13:13 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: ðåëÿòèâéóôóëïå ä÷éöåîéå

SUPERVISOR program User Guide SV version 0.24
Kornilov V., Shatsky N., Voziakova O. March 22, 2004

1


Contents
1 Basic principles 2 Comp onent programs 3 Writing the scenaria 4 Editing the SV configuration file 5 Starting the system A Command list for the communication of the system Sup ervisor A.1 Commands acknowledgment . . . . . . . . . . . . . . A.2 General purp ose commands . . . . . . . . . . . . . . A.3 TLSP: Telescop e driving commands . . . . . . . . . A.4 MASS/DIMM: Detector commands . . . . . . . . . . A.5 CENT: Centering unit commands . . . . . . . . . . . A.6 CORR: Position correcting unit commands . . . . . A.7 OBJM: Ob ject manager commands . . . . . . . . . . A.8 DOME: Dome driver program commands . . . . . . A.9 METE: Meteorology service program commands . . B Inter-program communication proto col C Description of the observations scenario obs massdimm.tcl C.1 Algorithm functioning . . . . . . . . . . . . . . . . . . . . . . C.2 The list of control variables of algorithm . . . . . . . . . . . . C.3 Pro cedures of algorithm . . . . . . . . . . . . . . . . . . . . . C.4 Algorithm usage . . . . . . . . . . . . . . . . . . . . . . . . . C.5 Parameters of configuration file which tune the scenario work D Visualization utilities for scenaria debugging E Sup E.1 E.2 E.3 E.4 E.5 ervisor programming issues (development engineer Intro duction . . . . . . . . . . . . . . . . . . . . . . . . . Op erating system requirements and p ortability . . . . . Structure of the SV program . . . . . . . . . . . . . . . Starting and stopping the observations and circumstance Possible errors/failures o ccurring in Sup ervisor . . . . . guide) ..... ..... ..... monitor ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . comp onent programs and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15 16 19 20 21 21 21 22 22 23 25 27 27 28 29 29 30 31 31 31 32 35 38 3 4 5 9 11

2


List of Figures
1 2 3 4 5 6 7 SV graphic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . States of the comp onent program and transitions b etween them . . . . . . . . . Blo ck-scheme of the algorithm of observations with MASS/DIMM . . . . . . . XMGRACE output pro duced by the viewlog.sh utility . . . . . . . . . . . . . . XMGRACE output pro duced by the viewhaz.sh utility . . . . . . . . . . . . . Startup of SV algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control variables in starting and stopping the scenaria. Dashed arrows denote errors (emerging in scenaria during use of deleted aliased commands or attempt to call a command in deleted interpreter) which cause catch-construct to work and thus stop scenario evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 17 26 30 31 33

.

37

Intro duction
In this do cument we consider the use of Sup ervisor program for automation of the observations sequence with a numb er of comp onent programs which are running the observational equipment (telescop e, detectors etc). The basic principles and the system tuning and running is describ ed b elow, whereas the MASS/DIMM scenario description, communication proto col accepted in MASS/DIMM and programming topics are lo cated in app endices. Below we briefly rep eat the general ideas of the SV-driven system explained in also in the Rep ort I. on the "Combined MASS/DIMM instrument" do cument (Kornilov et al, 2003).

1

Basic principles

The observational system from the software p oint of view consists of a numb er of driver-programs running on a single or several machines in a lo cal network. Each driver-program is called "comp onent" and allows to manipulate with a single hardware comp onent of the system ­ namely telescop e, some detector, stand-alone meteo-service or anything else. The comp onent normally has two interfaces: lo cal (console or graphic) user interface which allows to work manually with the device, and the command interface for communication with the program via a so cketconnection. The latter is used by the Sup ervisor program, which runs the sp ecially user-written system-tuned scripts. These scripts consist of a numb er of commands sent to the comp onents when some particular action or result is needed from them. Comp onents start the requested action or reply immediately with the ready result to the requesting agent (Sup ervisor). The proto col according to which they should act and accept commands is describ ed in app endix. The main content of latter do cument sp ecifies the demands to the MASS/DIMM system sp ecially. Normally, the observational set is a continuous p erio d of time (say, a night, week or a year) during which Sup ervisor must solve two tasks: 1. Tracing the conditions ­ whether they are go o d or not for starting observations; 2. Start observations when conditions are go o d and stop them (promptly!) when they b ecome bad. The scientific results collection is not the primary task of Sup ervisor, it only provides the extensive logging of own actions and commands exchange. The listed tasks are almost indep endent from each other, b oth in a sense of used comp onents and in a timing. They normally are run asynchronously and in parallel. In other words, SV provides the to ols for sequencing the commands to the comp onents in order to provide the non-excessive and efficient monitoring of observational conditions ­ this is

3


the scenario of the "Circumstance monitor" ­ and logical and optimal chain of commands to detectors, telescop e etc for conducting the observations ­ this is the "Observations" scenario. Both scenaria are written as Tcl scripts, but run not in a pure Tcl interpreter, but from the interpreters started by SV. User must provide the names of these script files (say, circmon.tcl for a monitor and obs.tcl for observations scenario) together with the comp onent parameters in the configuration file of SV ­ this is the sv.cfg file. Latter file may contain some parameters which tune the p erformance of the scenaria themselves ­ in order to easily mo dify their characteristics without edition of scenaria with a dully search for hard-co ded numb ers. Once provided such a go o d configuration file, user may start the comp onents, ensure that they are in a go o d shap e, start SV, and ensure that its start-up sequence has passed well and all comp onents were successfully connected to SV. That's all. In ideal situation, the User may come back home and wait for the e-mails from SV sent in case of o ccurrence of some error situations during observations (sending a mail is a usual option for the emergency sys script in CFG).

2

Comp onent programs

The current release of SV (or, more precisely, the provided scenaria of circumstance monitor and observations) op erates with following comp onent programs: a) OBJM ­ Ob ject Manager (Tcl script objm.tcl). The to ol for selection of the b estviewed star according to the user-provided selection criteria and the star catalogue. Includes the functionality of CIRC. b) CIRC ­ Circumstance Monitor (Tcl script circ.tcl). The computer of astronomical circumstances ­ the Sun and Mo on equatorial co ordinates and altitudes ab ove horizon, stellar and Universal time etc. Included into OBJM since it supp orts all the astronomical calculations needed for ob jects selection. c) METEO ­ Meteo service simulator (Tcl script meteo.tcl). To b e replaced with a real meteo-gathering program or upgraded to make the real conditions requests. Currently conditions are simulated using the random numb er generator. d) TLSP ­ Telescop e driver simulator (Tcl script tlsp.tcl). To b e replaced with a real driver program, or upgraded to send the commands to the mounting when it is needed. Currently, the telescop e activity is simulated by some waiting p erio ds. e) DIMM ­ the Differential Image Motion Monitor program simulator (Tcl script dimm.tcl). To b e replaced by a real DIMM program, e.g Robodimm for Windows or whatso ever app ears. In case of Rob o dimm, it will run on a separated Windows machine. Current simulator supp orts all the needed SV commands to DIMM replacing the real work for measurements with waiting p erio ds of 60 to 120 sec length (random). The simulator also supp orts the centering device functionality rep orting the star shifts in arcseconds on request. Shifts are random numb ers for b oth co ordinates which range increases from (-1,1) to (-100,100) arcsec when the time since the last request increases from 1 to 100 seconds and further. The CENT-functions run indep endently from DIMM functions in current simulator. f ) MASS ­ the Multi-Ap erture Scintillation Sensor program simulator (Tcl script mass.tcl). To b e replaced with a current release of Turbina program (version 2.04 or later) running on the same machine as SV or on the other Linux machine. Simulator provided serves thus only for purp oses of SV testing waiting for 60 sec up on RUN command for main measurements and for 5 sec up on RUN SCEN1 command for background measurement. The requests for data with GET-commands are supp orted (see MASS User Guide, Version 2.04). These comp onents (mostly simulators) may b e started together using the provided start dummies.sh script and killed by the stop dummies.sh script which is created by start dummies.sh.

4


When one wants to replace the simulators with real comp onent programs, the sv.cfg file must b e mo dified resp ectively to change the port, host and ident parameters of them. Then, to use other non-replaced comp onents, the line set comps "mass dimm meteo objm tlsp" in start dummies.sh must b e edited by removal of the names of replaced comp onents.

3

Writing the scenaria

Circumstance monitor and Observations scenaria are normally relatively simple scripts. They do not pay attention to errors which might o ccur in comp onents during execution ­ this is the comp etence of Sup ervisor (see also the end of this section). Also they must not care ab out the connection issues of the comp onents ­ they only know the new Tcl commands cmd, is cmd, wait cmd, wait sec, initialize, stop park and comp1, comp2... compn for communication with them (where comp1... are the comp onent program names listed in the configuration ­ the commands suited to return their configuration and requested parameter values). Both observations and circumstance monitor scenaria MUST take care ab out the initialization or parking of the comp onents b efore and after working with them, resp ectively. Note that this is a demand of SV versions starting with 0.20; earlier versions initialized and parked comp onents automatically. For doing so, the commands (actually, macros) initialize and stop park are provided ­ the scenario may use them as well as their own scripting. Initialization should b e done b efore scenario starts execution of measurements ­ i.e. b efore sending any commands implying the non-parked status of comp onents. Parking while stopping the scenario is more complex: the scenario has no idea when it may happ en. If some actions must b e undertaken while shutting down the observations (parking normally, also some p ossible after-scripts cancellation etc), the pro cedure with the reserved name end (without parameters) must b e written in the scenario. In case the scenario is stopp ed, SV searches for such a pro cedure and, if found, executes it b efore deletion of the scenario interpreter. First thing which this pro cedure must do is to prevent any other pro cedure from sending the commands to comp onents (organized, for example, with help of after-constructs), and then to call stop park "comp.list" if this is needed. Summarizing, the scenaria scripts do have b eginning, but not finalization which is provided by an isolated pro cedure end. Finally, Observations scenario has no idea ab out existence of Circumstance monitor scenario, and the latter knows only the commands start obs, is observations now and stop obs to manipulate the former. Below we sketch out the approximate sequence of actions which the scenaria should p erform in order to make observations: Circumstance monitor: 1. initialize monitoring comp onents (e.g. initialize "CIRC METEO") 2. set the needed parameters in them (optional; e.g.: cmd CIRC set longitude=..) 3. organize p erio dical requests of weather and sun-height conditions and, according to results and current state of observations (run or not), start or stop observations. Observations: 1. ask the new ob ject parameters 5


2. p oint the telescop e to new ob ject. Check that it is found with help of centering comp onent (co ordinate difference is not reserved +999 for the case of NOSTAR-error) If found 3. 4. 5. . 6. . . else 7. . . . try to find an ob ject around the exp ected p osition with telescop e and centering device. If found ­ check that it's likely the searched star, go to p.3. else ­ wait for some time and go to p.1 center the ob ject in field of view with help of centering comp. run a measurement command sequence if it is a time to check background or make some calibration ­ do it with help of telescop e and/or detectors trace whether it is enough with current ob ject. If yes ­ go to p.1, else ­ continue with p.4

As we see, observations scenario is much more complicated as it is. Writing the correct scenario is a key-p oint of successful usage of SV in automated observations. To write a scenario, the user should have at least general knowledge of the Tcl language, but study of the sample circmon.tcl and obs massdimm.tcl scripts may help to do the job without one since Tcl is very simple. Basic p oints are: · each line is a command with command name b eing the first word · command is ended by ";"-character or newline. The command may b e continued on a second line with help of trailing "¨ haracter. -c · a command in brackets [command args] represents the command substitution: e.q. [OBJM port] results in "1234" if sv.cfg has a line "p ort 1234" in "comp onent OBJM" section. This substitution may stand as an argument to another command: e.g. cmd OBJM set longitude="[CIRC longitude]" Here double-quotes are part of the command, since the result of CIRC-command may contain (and contains!) the spaces. · braces "{...}" are used to group the arguments. The content of braces may b e placed on several lines without trailing backslashes. Most common use of this is conditional commands if {condition} then {what then} else {what else}. · variables may b e declared on place of initialization where they b ecome needed. Do not forget that assignment may b e done only as: set a 1; set fi [CIRC latitude] and NOT as a = 1; fi=[CIRC latitude] - THIS IS WRONG. 6


· comments (#-started lines) are also commands - they are interpreted but only not executed. DO NOT PUT non-paired braces or brackets in comments! Avoid comments in switch-commands! The list of commands which user may use in scenaria is given in sections "SAFE INTERPRETERS" of the manual page to Tcl interp command (see man n interp). That's the starting p oint for a b eginner. All commands listed there may b e studied using their own manual pages (section "n"): e.g. man n after. The syntax of SV sp ecial commands is given b elow: cmd - to issue the command to the comp onent. Returns the command identifier. May b e started in background form with trailing "&" as a last parameter. The result of cmd when it rejects the request (e.g. comp onent is disconnected) is -1. NOTE this circumstance, since some scripts may b e based on issuing the command once previous is over! Since "-1"-result do es not cause an error situation in SV (no scenario script interruption is done), this may initiate an infinite lo op of cmd-calls (the SV console will b e full of messages "Attempt to send a command to disconnected comp onent"). Also, do not forget to enclose the string-typ e parameters in double-quotes: e.g.: cmd CIRC get longitude latitude set l [CIRC longitude] cmd TLSP set longitude="$l" latitude="[CIRC latitude]" is cmd comid - check that the command with the identifier comid (returned by cmd call) is still under execution (concerns evidently the cmd started with "&". Others return when execution is over.) Example: set mass_comid [cmd MASS RUN &] ... if {[is_cmd $mass_comid]} then { ... } else { ... } wait cmd comid [comid [... ]] - waits until any of the command(s) with given identifier(s) are over. When one of provided commands finishes - return its comid. wait cmd -1 returns immediately as well (see cmd). Example: set mc [cmd MASS RUN &]; set dc [cmd DIMM run &] ... wait_cmd $mc $dc if {![is_cmd $mc]} {} if {![is_cmd $dc]} {} # Note that at least one of above two conditioned lines will execute! wait sec delay [addlog ] ­ to delay execution of the scenario by the sec seconds. This do es not freeze the SV application up dating it once a second. The optional b o olean parameter addlog may b e set 0, if one wishes to skip the addition of the log-record (e.g. if delay is frequent and short). 7


component parameter - returns the value of the parameter (CFG or returned by the GETcommand) of the comp onent. In other words, there is such a command for all comp onents which are mentioned in CFG. Request of non-existent parameter causes the scenario interruption on error. Example: see cmd-examples. add log record ­ add the record in the log. initialize "components list" ­ a macro of INIT-commands where them are given the all comp onents altogether (INIT &) and then the macro waits for completion of initialization of all comp onents b efore return of control. For a single comp onent, the command is equivalent to cmd COMP INIT. Note that some comp onents may b e initialized with parameters (i.e. like INIT param=value param2=value..., see circ.tcl) ­ they cannot b e thus initialized with initialize. stop park "components list" ­ a macro of STOP NOW and PARK & commands where them are given to all comp onents and then the control is given back to caller when all comp onents get status PARKED. Monitor of circumstances also "knows" start obs - start observations scenario (when "go o d"). E.g.: cmd CIRC get hsun if {[CIRC hsun]<-12} { # Navigation twilight already: start_obs } stop obs - stop observations. E.g.: cmd METEO get cond if {[METEO cond]!="GOOD"} stop_obs is observations now - is the observations scenario under execution now. Example: if {[METEO cond]=="GOOD" && [CIRC hsun]<-12 && ![is_observations_now]}{ start_obs } An example of the observations scenario ­ obs massdimm.tcl ­ is do cumented in the app endix. Handing errors. As it was stated ab ove, SV takes care of handling the errors which o ccur while running the scenaria or rep orted by comp onents in their replies. A normal reaction for fatal errors happ ening with comp onents (such as a loss of connection, fatal error status etc., see Section E.5) is shutting the comp onent down (parking, if p ossible, and disconnecting), then ­ terminate SV or continue, dep ending on the optional parameter of this comp onent. Meanwhile, sometimes it is more vise to try to handle the situation more flexibly in order to make the system p erformance more stable. For this, the scenario (monitor or observations) must provide the pro cedure: 8


proc error_handler {code comp} { # parsing code and comp-onent parameters... ... # if handled successfully: return 1 # else -- unfortunately: return 0 } Such a pro cedure must return 1 ONLY if the error of a king code from the comp onent comp is indeed exp ected ­ for example, due to imp erfections of its co de implementation. See the co des in Section E.5. It is evident that there is no sense to return 1 in some cases: e.g. when the connection is lost (i.e. co de==ECMDLOS, ECMDLOW, ECMPDSC), b ecause the next error will o ccur immediately. Normally, successfully handled are only the ECMPFAT errors, although it is useful sometimes (at developing stage) to rep ort the errors only and to return 1 in any case.

4

Editing the SV configuration file

The SV configuration file name sv.cfg (the file resides in the same directory as sv.tcl!) is the only hard-co ded value of SV. All other settings are made by assignment of resp ective parameters in this file. Sometimes, sv.cfg is a link to the currently active SV setting file. SV comp osition is describ ed b elow and in sv.cfg sample as well in the comment lines (starting with #-character). The parameters of configuration stand in SV as either parameters of SV itself (in this case they are referenced in SV source text as SV(param) and in scenaria as [SV param]) or parameters of a comp onent - e.g. [CIRC latitude] in a scenario or cmp(port) in sv.tcl. This division is made with help of so called sections in SV configuration file. Beginning of a first section is the b eginning of the file. This is the section of SV parameters. They (tmout, oscen etc) last till the first declaration of a next sections: "component name" on a separate line. This declaration starts the section of the comp onent "name" and simultaneously declares that the comp onent program "name" exists in the system and must b e connected on start-up using the parameters sp ecified b elow. A numb er of parameters MUST reside within sv.cfg in order SV to work correctly. These are the parameters oscen and cscen of SV and the parameters port and ident for each comp onent. Their existence is checked during SV startup and error o ccurs if any is missing. A numb er of other parameters are also needed but defaulted within SV if not found in sv.cfg: these are tmout, revive time, interactive, start monitor and emergency sys in SV section , and parameters host and optional in each comp onent sections. Since version 0.20, the parameter obs comp list is obsolete (due to explicit initialization/parking of comp onents in scenaria, see b elow). Finally, a to ol for manipulating the observations scenario (only) interactively is provided in a form of a separate GUI: a window with the arbitrary numb er of buttons. This window app ears when Observations scenario is started and disapp ears when it is stopp ed. The button action is sp ecified in SV configuration file as a line: button1 command in scenario context; there may b e any numb er of lines like this: button2 command2, button3 command3... Normally, these commands are simple: assignment of some control variable or calling of a scenario script pro cedure. Complex commands are not recommended. Usually, such a GUI control is used while developing the system and related observations scenario; when the system is run finally as non-assisted, the resp ective button parameters are removed from sv.cfg. 9


Below we give a short explanation of a use of SV parameters: SV parameters: cscen ­ file name of a Circumstance monitor scenario script. oscen ­ file name of an Observations scenario. tmout ­ the time in seconds to wait for a reaction of a comp onent on a newly given command. Default is 10 sec. revive time ­ time in seconds after which the SV is self-restarting after shutting down up on a fatal error o ccurred with a comp onent while running scenario. This is made in a (mayb e fictious) hop e that after some time the problem may disapp ear itself. Defaulted to 0, i.e. do not restart. emergency sys ­ the system command or the name of a system script which is executed up on o ccurrence of a fatal error b efore termination of SV. Normally it is shaping out and sending the problem rep ort by e-mail. Defaulted to simply typing "SV termination!" on a lo cal console. interactive ­ logical (0/1) variable sp ecifying the way some error situations are treated. If 0 (non-interactive), SV shuts down up on any unhandable fatal situation calling emergency sys b efore; if 1 (interactive), the message is output in a graphic window allowing some bypassing actions to b e undertaken which is used while debugging the system b ehavior lo cally (i.e. in assisted mo de). Defaulted to 0 (i.e. non-assisted). start monitor ­ logical (0/1) variable sp ecifying whether to start or not the Circumstance monitor immediately up on startup (i.e. as shown in Fig. 6). Defaulted to 1. buttoni command ­ sp ecification of a command to b e invoked in Observations scenario when it is running. Comp onent parameters: ident ­ comp onent program identifier (string), returned up on the request GET IDENT (see b elow). p ort ­ so cket p ort numb er of a comp onent. host ­ name of the machine (IP or DNS name) where comp onent is running. Defaulted to 127.0.0.1 (i.e. lo cal host). optional ­ role of a comp onent in a system. If sp ecified as 1, the comp onent is parked and disconnected up on o ccurrence the fatal error with it and the system pro ceeds running. If not sp ecified or given as 0 ­ o ccurrence of a fatal error with the comp onent causes the system to shut down. It is fully due to the scenaria writer to decide which comp onent is optional and which is the mandatory, i.e. the one without which the system p erformance is not p ossible at all. Defaulted to 0 (i.e. mandatory). All the rest parameters are suited for the scenaria needs only and ignored by the SV co de itself. Note that there is NO principal difference where to put these parameters ­ in a section of SV or of some comp onent; it's a matter of taste and free logics. A go o d habit is to put the p ersonal parameters of comp onents (which control their usage or which are set in them with 10


SET command) in the section of resp ective comp onent. Note that similar comp onent parameters may have the same name for different comp onents. In principle, the user is free to hard-co de all the parameters in scenaria scripts and to leave only the obligatory parameters in sv.cfg. Example of usage of SV configuration parameters in Circumstance monitor scenario is given in sample circmon.tcl.

5

Starting the system

The SV package should b e unpacked in some directory, normally it is /usr/src. No ro ot privileges are demanded for SV running. So, its useful to change the p ermissions for the user going to start SV (e.g. mass) to b e able to write in the SV directory. Also, the log-files *.log and temp orary files (tmp.*,.tmp), if present, and SV configuration files *.cfg must b e writable or owned by this user. sv.tcl and the comp onent scripts such as meteo.tcl, circ.tcl, objm.tcl etc. must have execution p ermissions. The comp onent programs apart from those residing in SV directory must b e installed separately and must b e accessible via network. Their IP addresses (127.0.0.1 for the same machine as SV runs on) and p ort numb ers must b e written in SV configuration file sv.cfg. Note, that p ort numb ers on the same machine cannot b e shared! All comp onent programs should b e started BEFORE SV starts and continue to b e on-line all the time the system works. Once the connection is lost, SV stops working and disconnects the comp onent. If the parameter "optional 1" is not set in the resp ective comp onent section of SV, the SV terminates (or gives the resp ective message if run in interactive mo de). You may use client.tcl port [host] script for connecting to the particular comp onent program to check how it works and how it is seen to SV through network. The commands there are enumerated automatically, so the first input word from the console should b e the command keyword (INIT, RUN etc). Finally, shap e out the emergency sys parameter in sv.cfg to have the prop er error handling command ready. Try to initiate the error situation (disconnect or shut down one of comp onents) and see what will happ en: someb o dy should receive an e-mail in reserved address with the fragment of SV log file if your emergency sys is set to running of the provided sv error.sh script. Then start Sup ervisor from the current directory: $ ./sv.tcl The window like shown in Fig. 1 app ears in the screen. The history of commands exchange app ears on the console and (somehow shortened, command-reply pasted) - in the SV window panel. Log-file is created with the name YYMMDDsv.log, where YYMMDD is the evening lo cal date of the night (it is given by the moment 12 hours b efore). The circumstance monitor scenario will b e started automatically and may b e stopp ed by the [Stop monitor] button. When monitor (or you ­ via [Start observations] button) commands to start observations, the observation scenario script with related communication with comp onents will start. To stop observations or monitor ­ press the resp ective Stop-button. When finished completely ­ press [Terminate]. Exp eriment with a trial starts of SV using the manual Start observations (from GUI button). Check that system starts initialization and everything go es Ok. GUI control buttons

11


Figure 1: SV graphic window

12


Comp onent names : these are in practice the buttons which p op up the menu with following items: Command : op ens the dialog for command exchange with the comp onent. Connect : connects the comp onent if it was disconnected. Practical for the manual commands exchange only when no scenario (monitor or observations) using a comp onent is active Disconnect : closes the so cket channel of the comp onent. All the commands sent after this to comp onent are ignored resulting in a resp ective log message only Start Observations : calls the pro cedure start obs of SV. If the observations starting was disabled, enables it first (that's a difference with the starting of observations from the scenario) Stop Observations : calls the pro cedure stop obs of SV and disables starting of observations by the circumstance monitor. Allow Observations : resets the observations starting protection set by Stop Observations button. Observations MAY then b e started by the circumstance monitor Pause/Resume communication with comp onents: delays the comp onents until the rep etitive pressing of the button. scenaria are executed until the control reaches the next is pressed, the delayed command(s) is sent as normally. communication and Terminate button are not blo cked in sending of the commands to the After pressing the button, the cmd call. When Resume button Comp onent Commands dialog the paused state.

Start monitor : starts the circumstance monitor scenario (which is started automatically up on SV startup pro cedure) Stop monitor : stops the execution of the circumstance monitor scenario until next its start by the button Terminate : stops observations parking all the comp onents, disconnect all comp onents, remove GUI and exit the program. The same as a small cross-button of the SV's window (upp erright side normally).

13


Appendices
A Command list for the communication of the system comp onent programs and Sup ervisor
Intro duction
This do cument concerns the further development of the software for the pro ject at the upp er logical level. Here we consider the requirements for the comp onent programs (like MASS, DIMM and Telescop e driving programs and other secondary services) which should b e fulfilled for their successful op eration under the management of the Sup ervisor program. The communication proto col was fixed in the previous rep ort (see Appx."Inter-program communication proto col") while here we sp ecify what in particular is needed to b e supp orted