MkDoit2 Manual

Contents

1.0: Compiler Invocation

Mkdoit2 is invoked with the following command format:

      mkdoit2 [ -o <outputfile> ] [ <inputfile> ... ]
Users of the ARP Data Acquisition System will almost never need to invoke the compiler directly; the invocation is handled by appgen and make.

2.0: Introduction

2.1: doit scripts

MkDoit2 is a language to generate "doit" scripts for use with ARP Data Acquisition. It supports options for many features which are handy to have in a doit script.

For compatibility with APPGEN, the input filename should end in ".doit". The doit script can be generated as part of the general make process by adding a line to the .spec file such as:

        abcdoit : abc.doit
The resulting script is designed to work with most if not all standard experimental configurations as specified in the Experiment.config file. Invoking the script should start up the instrument or immediately attach to the instrument if it is already running. Multiple simultaneous invocations are safely arbitrated to avoid conflicts and deadlocks.

In addition, the script can take one of two optional arguments, "not" and "stop". "doit not" is used to prevent an instrument from starting up if it would do so automatically, such as in a flight configuration. (Up until now, users would need to explicitly issue the command "pick_file /dev/null", making sure that the environment variable "Experiment" was properly defined first. With the advent of the Experiment.config file, it is no longer necessary or desirable to have Experiment predefined, since it can be looked up in the file, but pick_file (and most of the other binary utilities) require this definition. By nesting this command within the doit script which reads Experiment.config, this process is simplified.)

"doit not" can also be used to "clean up" in the event that a disorderly shutdown has left some processes still running.

"doit stop" will shut down an instrument that is already running without requiring the full GSE program to be run. This is accomplished by running the command "startdbr quit" on the flight node with the appropriate Experiment definition from the configuration file.

2.2: .doit files

A basic .doit input specification will define a display program and a keyboard client program. For example:
        display abcdisp abc
        client abcclt
specifies that the display program "abcdisp" should be run and that it requires one screen which should be initialized with the scrdes file "abc.fld". The script will also invoke the keyboard client program "abcclt".

To add an algorithm, we could simply add the line:

        algorithm abcalgo

Telemetry applications are classified into one or more of the categories display, extraction, or algorithm. For the purposes of mkdoit2, a display program is any TM client generated from a .fld file or a .tbl file. An algorithm is any TM client which accesses the command server using the "cic" functions, specifically cic_options() as referenced from /usr/local/include/oui/client.oui, which is true of any program generated from .tma source files. Extraction is used for any TM client that is not a display or algorithm, or for a display program for which additional command-line options are desired.

If it is necessary to list an application more than once, the "display" entry must come first. For example, a display program which also sends commands to the command server is actually both a display and an algorithm. In this case, it should be listed first as a display and next as an algorithm. It will appear in the output file with the display programs, but it will have been endowed with the command-line options required by command clients. You might also need to list a program as both display and extraction in order to specify a command-line option:

        display abcdisp abc
        extraction abcdisp -h ABCD

In any case, the listing for "display" must come first. Note that the screen names listed must match those listed in the .spec file in name, number and order or strange problems will result.

There are numerous other options available listed in the Input Syntax below, and more will inevitably be added as time goes by, so stay tuned!

2.2.1: Playback

The playback option can be used to create a doit script which will run on previously logged data. The resulting script takes a run directory as an argument and invokes the rdr to playback the data. It is possible to run displays, algorithms and graphics in this mode, very much the same way as in real time, except that in playback you have the option of running everything fast forward or in slow motion in addition to real time.

In order to create a playback script from a realtime script, replace the client specification with the keyword "playback" and make sure any algorithms listed have the -p option (for Playback). You may also optionally specify the autostart keyword in order to have the data playback begin immediately without requiring a manually-entered "Telemetry Start" command.

2.2.2: Inetin

Inetin is used to specify that the script should run the Inetin program to connect to a data stream on a remote system. As with Playback, this option replaces the client keyword, invoking PBclt instead. This configuration will also accept the autostart keyword. The resulting script requires that the variable RemoteHost be defined in Experiment.config.

2.2.3: Serin [options] <device>

Serin is used to specify that the script should run the serin program to connect to a data stream coming in on a serial port. As with Playback, this option replaces the client keyword, invoking PBclt instead. This configuration will also accept the autostart keyword.

2.3: .fld Fields

In addition to reading the .doit input file, mkdoit2 reads the .fld files which are specified in each "display" statement. The following field contents are recognized:

%STATUS:<app>
Defines the location of a status line for the specified application.
%STATUS
Defines the location of a general status line for all applications which do not have their own status field.
%CLIENT
Indicates that a keyboard client should run on this screen. If no such field is defined, the keyboard client will run on all display screens. This is consistent with prior practice. Keyboard clients always appear on the last two rows of a console, so the only information extracted from this field is which screen it is on: row, column and width are ignored.
%TMA:<app>[:#]
Defines a status field for the specified TMCALGO. The partition number may optionally be specified, with the first partition in the algorithm being numbered 1. If no partition number is specified, the field refers to partition 1. All TMCALGO status fields require two rows and are 80 characters wide, so the only information extracted from this field is the row: column and width are ignored and assumed to be 0 and 80 respectively.

3.0: Input Syntax

display <program> <screen file> [ <screen file> ... ]
Specifies a display program to run and the names of the .fld files which define it. The list of .fld files must match those listed in the .spec file in name, number and order or strange problems will result.
client <program>
Specifies a keyboard client to run
monoconfig <filename>
colorconfig <filename>
Specifies explicit screen configuration files to use for monochrome and/or color displays.
memo [ <log file name> ]
Specifies that "less +F <log file>" should run on a spare console to provide a scrolling status window.
algorithm <program> [ options ]
Specifies an algorithm to run.
extraction <program> [ options ]
Specifies an extraction to run in realtime, for example an rtg extraction. Algorithms are different from Extractions in that they send commands to the command server.
If either an algorithm or an extraction has a -v option specified, the standard msg option ( -c$FlightNode ) is suppressed. This prevents status messages from being sent to memo. Status messages to memo are also suppressed for algorithms in playback mode (-p) accessing a local instrument to prevent duplicate messages in the log.
batchfile <batch file name>
Specifies which script should be run on the flight node. The default is "interact", but this option could be used to specify that the flight "runfile.dflt" be used instead.
rtg <config file>
Requests that rtg be started if it isn't already running, and defines the name of the rtg configuration file to use. The file name should be absolute, since rtg will otherwise look in a standard configuration directory.
playback
Specifies that the script is intended for playback. Playback implies the use of the rdr, the PBreg speed regulation utility and the PBclt keyboard client. No other client should be specified. Any algorithms must have -p specified, for obvious reasons.
inetin
Specifies that the script is intended for connection to a remote data stream via the Inetin program. Like playback, inetin implies the use of the PBreg speed regulation utility and the PBclt keyboard client. No other client should be specified. Algorithms should also have -p specified, since the command server will not be reachable. (It is a fairly simple matter to extend command capability to remote systems via Inetsrvr and Inetcmd programs, but in most cases this is rather undesirable.)
autostart
Used with playback and inetin, specifies that data should begin playing as soon as all the TM clients have registered.

A.0: Invoking Scripts under QNX Windows

The doit scripts generated by mkdoit2 have been carefully designed to operate properly either on standard QNX consoles or in QNX Windows wterm windows. Even invocations of rtg are safe, as the doit script checks to see if windows is running and only launches rtg if it is. Scripts can be invoked via the command line in a wterm shell exactly as they are invoked on a QNX console, but they can also be added to your personal windows configuration to be selectable from the "Programs" menu without first bringing up a shell.

In order to add a doit script to your menu, select "Properties..." from the Workspace menu. This brings up the list of menu items for editting. In the upper right corner, select "Personal" to bring up your private selections.

Suppose we wanted to add an entry to run the NO2 instrument using the script windoit with the menu entry, "Run NO2". Select the "Name:" field and enter "Run NO2". Then select the "Invocation String:" field and enter //9/home/no2/windoit.


Return to Manuals Guide


last updated: Thu Sep 23 10:42:22 2004 webmaster@huarp.harvard.edu
Copyright 2004 by the President and Fellows of Harvard College