May 24, 2019

Grinder - what about ovend?

We have a general idea of what ovend does. It talks periodically to the onboard (V) computers and requests data. It then updates the contents of the database in shared memory. It also generates the on disk files in the form of IRAF images. At least that is what we think it does at a top level.

Default behavior is governed by its parameters, in particular: 

vocl> lparam ovend
     (logdata = yes)            Log data?
      (period = 60)             Polling period (seconds)
      (offset = 5)              Delay after period (seconds)
So normally it runs once a minute, 5 seconds into the minute, and does log data to image files.

A peek at the IRAF "mirror" package

In the top level directory we see mirror.cl -- this is a sort of manifest that lists all the public entry points and indicates that they all (including ovend) are to be found in x_mirror.e. Something like that -- no doubt there is documentation that describes the format of an IRAF package somewhere.

Next, in the src directory, we find x_mirror.x which the following line, which is no doubt important. 

ovend   = t_doven,
This leads us to the file src/oven/t_hoven.x which has a procedure t_doven() which gathers up parameters and then passes all those parameters to "doven" via the following call: 
status = doven (noven, ncomp, logdata, period, offset)
This ends up calling doven_ in hoven.c There is some trickery with a DOVEN macro which is defined as "doven_". This routine performs some initialization and eventually calls: 
status = do_ovend (*logdata, *period, *offset);
This routine is also in hoven.c and consists of the following loop: 
	while (1) {
            if (period) {
                time (&now);
                sleep (period - now%period + offset);
            }
            status = db_dread_oven ();
            stalereport ();
            if (status && logdata)
                datalogger ();
        }

So what is actually going on?

The call to db_dread_oven() is in database.c. It performs network reads on ports PORTRB and PORTRD. The data goes directly into the database (into b_database and d_database). It is not necessary to read parameters (p_database). The intermediate values (i_database) are never read. The errors (e_database) are handled elsewhere (by "ovene").

The call to datalogger() is in datalogger.c -- it will ultimately make the following calls to logdata(): 

	logdata ("adcv", adcv, sizeof(adcv)/sizeof(adcv[0]));
            logdata ("rotv", rotv, sizeof(rotv)/sizeof(rotv[0])); (maybe)
        logdata ("jtmp", jtmp, sizeof(jtmp)/sizeof(jtmp[0]));
        logdata ("ttmp", ttmp, sizeof(ttmp)/sizeof(ttmp[0]));
        logdata ("htmp", htmp, sizeof(htmp)/sizeof(htmp[0]));
        logdata ("hpwr", hpwr, sizeof(hpwr)/sizeof(hpwr[0]));
        logdata ("ztmp", ztmp, sizeof(ztmp)/sizeof(ztmp[0]));
        logdata ("zsct", zsct, sizeof(zsct)/sizeof(zsct[0]));
        logdata ("etmp", etmp, sizeof(etmp)/sizeof(etmp[0]));
logdata() is in its own file. This is a glue routine from C code back to SPP calling: 
LGDATA (pre, pix, &ny);
This is in lgdata.x and is implemented by procedure lgdata (prefix, pix, ny).

This procedure handles the generation of filenames of the form "hpwr180927.imh" -- no special logic is needed at the start of a new day, only to recognize that the generated filename does not exist yet.

What about FITS files someday

How would this be modified to generate FITS files? I am told that is handled by an IRAF environment variable setting somewhere, so it may just magically happen when that environment variable setting is changed.

The variable in question seems to be "imtype". My IRAF on my linux system shows: 
vocl> show imtype
fits
vocl> show imextn
oif:imh fxf:fits,fit fxb:fxb plf:pl qpf:qp stf:hhh,??h
On the old suns, I get the following: 
cl> show imtype
imh
cl> show imextn
oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h
Have any comments? Questions? Drop me a line!

Tom's home page / tom@mmto.org