MkDoit3 Manual

Contents

1.0: Compiler Invocation

Mkdoit3 is invoked with the following command format:

      mkdoit3 [ -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

MkDoit3 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.

“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
client abcclt

specifies that the display program “abcdisp” should be run. The script will also invoke the keyboard client program “abcclt”.

At present, there is no provision or benefit to adding algorithms to a .doit file under QNX6. This is a feature we hope to implement soon.

Telemetry applications are classified into one or more of the categories display, extraction, or algorithm. For the purposes of mkdoit3, a display program is any TM client generated from 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.

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.

In any case, the listing for “display” must come first.

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

In mkdoit2, a separate doit script was required for playback, and hence a separate .doit file was also required. With mkdoit3, the playback option is built into every doit script, so no explicit playback specification is required.

2.2.2: Inetin

Inetin has not been implemented in mkdoit3. If and when it is, it will probably be an option to the doit script, like playback.

2.2.3: Serin [options] <device>

Serin has not been implemented in mkdoit3. If and when it is, it will probably be an option to the doit script, like playback.

3.0: Input Syntax

display <program> [ <options> ... ]
Specifies a display program to run and any options required
client <program>
Specifies a keyboard client to run
memo [ <log file name> ]
Specifies that “less +F <log file>” should run on a spare console to provide a scrolling status window.
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.
phrtg <options>
Requests that phrtg be started if it isn't already running, and defines any options required.

A.0: Invoking Scripts under Photon

The doit scripts generated by mkdoit3 have been carefully designed to operate properly either on a standard terminal or as native QNX Photon applications. To invoke the terminal version, use the doit '-s' option. Invocations of phrtg will be suppressed when running the terminal version, and the 'nc' versions of the display programs will be run instead of the Photon versions.


Return to Manuals Guide


last updated: Mon Apr 8 17:10 2013 webmaster@huarp.harvard.edu
Copyright 2013 by the President and Fellows of Harvard College