Interpreter Commands

The macro language understood by the sniffle interpreter is very simple, so there aren't many rules to remember. The interpreter is not case sensitive, so it doesn't distinguish between ``hello world'' and ``HeLLo wORLd.'' A comment is anything from a pound sign (#) to the next end-of-line or semicolon. The only absolute rule is: never place a semicolon inside a comment, or an error will result, because the interpreter thinks the comment ends at the semicolon.

Output

sniffle provides three commands for controlling the digital output functions of the RTI-815 I/O board on our server PC, listed below. See the Analog Devices RTI-800/815 User's Manual for information on pin assignments.

• XAOT <channel> <value> sets the voltage on the specified analog output channel to the given value. The channel parameter must be either 0 or 1, and value must be a number in the range -9.99 to 9.99.
• DOT <value> produces digital output. The value parameter is a decimal number in the range 0-255 or a hex number in the range H0-HFF. You must precede hex numbers with an ``H.''
• DOTB <bit> <1|0> writes zero or one to the specified bit of the digital output, where bit is a number in the range 0-7.

The DOTB command is useful because it is sometimes handy to be able to toggle an individual digital output bit without worrying about or affecting the other digital output bits. The pan-and-tilt control scheme, for instance, relies on DOTB to change the digital output bits we use for controlling our camera platform without knowing or changing the other digital output bits.

Input

Two commands allow the client-end sniffle user to measure the voltages on wires connected to the I/O board of the server PC:

• XAIN <channel> records the voltage on the specified channel and returns this value to the user in the session log. The channel parameter is a number in the range 0-15.
• DIN reads the byte of digital input and records a hex-encoded value in the range 0-FF in the session log.

Digital Oscilloscope

Our server PC is currently connected to a Tektronix 222 digital oscilloscope via a serial connection. Through the commands below the sniffle user can control literally every feature and function of the oscilloscope. For more information on the strings recognized by the oscilloscope, see the Tektronix manual entitled 222 RS-232 Interface Guide.

• TEK SEND <delay> { <string> } sends the string enclosed between curly braces to the Tektronix scope and waits delay seconds before attempting to read a reply from the scope. Any command whatsoever can be sent to the scope using this command; the other two TEK commands are special cases which include a few user friendliness features. It is the user's responsibility to choose the delay interval wisely (ten seconds will almost certainly be long enough for any single command). The reply returned by the oscilloscope is returned to the user in the session log, along with an English decoding of any error codes returned by the scope.
• TEK GET grabs both waveforms from the oscilloscope and stores them in files on the server. The client can obtain these waveforms after the WEBRTI.EXE program has terminated.
• TEK FP? <logfp> obtains from the oscilloscope a string encoding the current state of logfp, where logfp is usually ``acq,'' denoting the acquisition system. A detailed listing of the current logfp settings is returned to the user in the session log. This is how to find out all there is to know about the scope's settings.

Miscellaneous

• DELAY <n> causes the WEBRTI.EXE program to pause for n seconds.
• LOOP <n> { <commands> } causes the given commands to be executed n times. The commands must be enclosed in curly braces. Nested loops don't work, but otherwise an arbitrary list of semicolon-delimited commands can be used.
• SOURCE <filename> executes commands contained in a file on the server. These files are stored in directory C:\HTTPD\HTDOCS\WEBRTI\ and have .RTI extensions. This extension is not part of the SOURCE command. So ``SOURCE FOO'' is correct but ``SOURCE FOO.RTI'' is wrong.

The SOURCE command is worth discussing in further detail. It provides a powerful mechanism for the client-end user to invoke batches of commands stored at the server end. Furthermore, SOURCE commands can be nested. Let's consider an example.

We will use two .RTI files in C:\HTTPD\HTDOCS\WEBRTI\: TEST02.RTI and TEST03.RTI. TEST02.RTI looks like this

#
#  Simple file to test ability of WEBRTI to handle "source" commands.
#
DOT 2; DELAY 2
DOT 3; DELAY 2

SOURCE TEST03

DOT 6; DELAY 2
DOT 7; DELAY 2

and TEST03.RTI looks like this

DOT 4; DELAY 2
SOURCE NOT-HERE
DOT 5; DELAY 2

We go to http://piper.princeton.edu/webrti.htm and enter the following:

dot 1; delay 2
source test02
dot 0

If we submit this set of commands from the vicinity of the server PC, we might be able to watch the digital output slowly count from zero to seven as the commands are executed. After our ``program'' has run, we get the following feedback in the session log:

BEGIN PROGRAM 02:43:06 9/13/95
RTI Initialization: 
COM Initialization: READY; 

0/1 : DOT 0 : 
0/2 : DELAY 2 : 
0/3 : DOT 1 : 
0/4 : DELAY 2 : 
0/5 : SOURCE TEST02 : 
   1/6 : DOT 2 : 
   1/7 : DELAY 2 : 
   1/8 : DOT 3 : 
   1/9 : DELAY 2 : 
   1/10 : SOURCE TEST03 : 
      2/11 : DOT 4 : 
      2/12 : DELAY 2 : 
      2/13 : SOURCE NOT-HERE : file empty or nonexistent:
                      C:\HTTPD\HTDOCS\WEBRTI\NOT-HERE.RTI
      2/14 : DOT 5 : 
      2/15 : DELAY 2 : 
   1/16 : DOT 6 : 
   1/17 : DELAY 2 : 
   1/18 : DOT 7 : 
   1/19 : DELAY 2 : 
0/20 : DOT 0 : 

END PROGRAM 2:43:23 9/13/95

The sniffle interpreter keeps track of the ``depth'' of each command it executes. The commands we submitted to the server are at ``depth'' zero, so in the session log they are labelled 0/1, 0/2, etc.. The commands in TEST02 are at ``depth'' one, so the number before the slash is 1. TEST02 sources TEST03, so the commands in TEST03 are at depth 2. Lines in the session log are indented according to the depth of the commands to which they correspond.