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.
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.
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!
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.
Inetin has not been implemented in mkdoit3. If and when it is, it will probably be an option to the doit script, like playback.
Serin has not been implemented in mkdoit3. If and when it is, it will probably be an option to the doit script, like playback.
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 |