File: greg_goebel_hpib_tutorial.html

package info (click to toggle)
linux-gpib-user 4.3.7-3
links: PTS, VCS
area: main
in suites: forky
size: 1,752 kB
sloc: ansic: 10,381; perl: 1,120; xml: 375; makefile: 335; yacc: 335; tcl: 308; python: 173; php: 157; lex: 144; sh: 134; lisp: 94
file content (5608 lines) | stat: -rw-r--r-- 227,987 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>A Tutorial Introduction To HPIB</title>
</head>

<body>
<h1><a name="top">A Tutorial Introduction To HPIB</a></h1>
<p>
<em>v4.1 / 01 jan 99 / greg_goebel / public domain / hpib_tutorial</em>
</p>
<p>
* This document is a tutorial introduction to the HPIB interface, covering
theory and use of the HPIB from fundamental specs to instrument programming
and HPIB card configuration.
</p>

<hr />
<h1>Table Of Contents</h1>
<h2><a href="#ib1_m0">[1.0] HPIB Tutor (1):  Introduction</a></h2>
<h2><a href="#ib2_m0">[2.0] HPIB Tutor (2):  HPIB 488.1 / HPIB Fundamentals</a></h2>
<ul>
<li><a href="#ib2_m1">[2.1] 488.1 OVERVIEW</a>
</li>
<li><a href="#ib2_m2">[2.2] HPIB FUNCTIONS &amp; CAPABILITIES</a>
</li>
<li><a href="#ib2_m3">[2.3] HPIB SIGNAL LINES &amp; COMMANDS</a>
</li>
<li><a href="#ib2_m4">[2.4] HPIB ADDRESSING</a>
</li>
<li><a href="#ib2_m5">[2.5] HPIB COMMANDS</a>
</li>
<li><a href="#ib2_m6">[2.6] HPIB IN OPERATION -- AN HP BASIC EXAMPLE</a>
</li>
<li><a href="#ib2_m7">[2.7] HPIB IN PRACTICE</a>
</li>
<li><a href="#ib2_m8">[2.8] ASCII TABLE FOR HPIB</a>
</li>
</ul>
<h2><a href="#ib3_m0">[3.0] HPIB Tutor (3):   IEEE 488.2 -- Overview &amp; Data Formats</a></h2>
<ul>
<li><a href="#ib3_m1">[3.1] OVERVIEW</a>
</li>
<li><a href="#ib3_m2">[3.2] DATA CODING &amp; FORMATS</a>
</li>
<li><a href="#ib3_m3">[3.3] SYNTAX</a>
</li>
</ul>
<h2><a href="#ib4_m0">[4.0] HPIB Tutor (4):   488.2 Common Commands &amp; Status</a></h2>
<ul>
<li><a href="#ib4_m1">[4.1] 488.2 COMMON COMMANDS &amp; STATUS OVERVIEW</a>
</li>
<li><a href="#ib4_m2">[4.2] ESSENTIAL COMMON COMMANDS</a>
</li>
<li><a href="#ib4_m3">[4.3] STATUS REPORTING</a>
</li>
<li><a href="#ib4_m4">[4.4] SECONDARY COMMON COMMANDS</a>
</li>
</ul>
<h2><a href="#ib5_m0">[5.0] HPIB Tutor (5):  Introduction To SCPI</a></h2>
<ul>
<li><a href="#ib5_m1">[5.1] SCPI OVERVIEW</a>
</li>
<li><a href="#ib5_m2">[5.2] SCPI COMMAND SYNTAX</a>
</li>
<li><a href="#ib5_m3">[5.3] EXAMPLE SCPI COMMAND SETS</a>
</li>
<li><a href="#ib5_m4">[5.4] SCPI DATA FORMATS</a>
</li>
<li><a href="#ib5_m5">[5.5] STATUS &amp; TRIGGERING</a>
</li>
</ul>
<h2><a href="#ib6_m0">[6.0] HPIB Tutor (6):  A SCPI-Based HPIB Instrument -- The 34401 DMM</a></h2>
<ul>
<li><a href="#ib6_m1">[6.1] 34401 OVERVIEW</a>
</li>
<li><a href="#ib6_m2">[6.2] PROGRAMMING THE 34401</a>
</li>
<li><a href="#ib6_m3">[6.3] A SIMPLE 34401 EXAMPLE PROGRAM</a>
</li>
</ul>
<h2><a href="#ib7_m0">[7.0] HPIB Tutor (7):  Notes &amp; Comments</a></h2>
<ul>
<li><a href="#ib7_m1">[7.1] BENCHMARKS</a>
</li>
<li><a href="#ib7_m2">[7.2] PASS CONTROL &amp; NON-CONTROLLER OPERATION</a>
</li>
</ul>

<hr />
<h1><a name="ib1_m0">[1.0] HPIB Tutor (1):  Introduction</a></h1>
<p>
* This section provides a tutorial overview of the Hewlett-Packard Interface
Bus (HPIB) interface system, also known as the General-Purpose Interface Bus
(GPIB) or by its Institute of Electrical and Electronic Engineers (IEEE)
specification number, IEEE-488.  HPIB is a scheme by which groups of devices
may be connected to a controlling computer and communicate under its
direction.  It is highly standardized and instruments from multiple vendors
can be operated in the same HPIB system.
</p>
<p>
The HPIB standard is defined at several levels:
</p>
<ul>
<li> The original 488.1 specification defines the mechanical and electrical

   characteristics of the interface and its fundamental protocols.
</li>
<li> The 488.2 specification refines the 488.1 spec to define an acceptable

   minimum configuration, and adds specifications for a basic set of
   instrument commands and common data formats.
</li>
<li> The SCPI (Standard Commands for Programmable Instrumentation)

   specification provides a detailed description of instrument commands that
   can be transferred over the HPIB.  Strictly speaking, the SCPI commands
   can be implemented on an instrument using <em>any</em> sort of interface --
   HPIB, serial/RS-232, VXI backplane, tins and strings, or whatever -- but
   they are so applicable to HPIB that no discussion of HPIB would be
   complete without them.
</li>
</ul>
<p>
This document is divided into modules to discuss the following topics:
</p>
<ul>
<li> Fundamental HPIB (488-1) operation.
</li>
<li> 488.2 specs and data formats.
</li>
<li> 488.2 commands.
</li>
<li> SCPI commands.
</li>
<li> A SCPI instrument, the 34401A DMM. 
</li>
<li> Comments on benchmarking and passing control.
</li>
 </ul>
<p>
There are plenty of source materials available for these topics and I have
made full use of them.  Materials on 488.1 and 488.2 are derived from the HP
publication A TUTORIAL DESCRIPTION OF THE HEWLETT-PACKARD INTERFACE BUS,
while the SCPI material is derived from Barry Eppler's A BEGINNER'S GUIDE
TO SCPI.  Of course, the section on the ALF draws heavily on the 34401A
manual.
</p>
<p>
This document requires a knowledge of fundamental computer concepts and
nomenclature.  A small knowledge of electronics technology is also useful.
Little other knowledge is assumed.
</p>
<p>
* If you are using this document for self-study rather than reference, a
few guidelines should help you make the best use of it:
</p>
<ul>
<li> All the material on 488.1 is fundamental and very useful, except possibly
   for the discussion of parallel poll (one of the few features of the basic
   spec that is of questionable use).  
<p>
   Very careful attention should be paid to the example program, which shows
   how the protocols actually work in practice.  The section on &quot;HPIB IN
   PRACTICE&quot; helps give more background on the actual environment in which
   HPIB is used.
</p>
</li>
<li> The discussion of 488.2 data formats does not need to be absorbed in
   detail.  Just read it to get a general idea of the different types of
   formats, and refer back to it if necessary.
</li>
<li> The discussion of 488.2 commands provides a core command set for modern
   instrument programming.  Some 488.2 commands are commonly used, however,
   while some are not, and this module has separate sections to discuss the
   two classes of commands.  Please pay close attention to the section on
   important commands, and simply skim through the section on secondary
   commands.  The section on status and triggering should be read carefully,
   but you don't need to absorb it in detail.
</li>
<li> The discussion of SCPI and the ALF should be read carefully, but you don't
   need to absorb it in detail.  That will come when you work on a
   particular instrument in practice.  Tinkering with ALF programming is
   highly recommended, however.
</li>
 </ul>
<p>
* I wrote this document out of a sense of frustration.  HPIB has been a core
concern of my work for many years, but at the same time I never really felt
like I understood the topic through its full spectrum, in the proper balance
between minor details and broad application.  
</p>
<p>
The fact that there was no document available that described HPIB all the way
from the fundamental definitions up to implementations led me to want to
write one myself.  I wanted to not only ensure that I did in fact have an
understanding of that full range, but also to spare others the roundabout
path I took to get there.
</p>
<p>
The first major version was basically a ripoff of the source materials.  The
second major version was a complete rewrite and reorganization of the first
(that started out, ironically, as an attempt to correct a single typographic
error and got <em>remarkably</em> out of hand).
</p>
<p>
The second version is far superior to the first since it focuses on practical
concepts rather than some of the (sometimes bewildering and excessive) theory
devised to support the 488.2 and (in particular) SCPI specs.
</p>
<p>
While this document is necessarily terse -- it covers a very wide range of 
material -- you should find it informative and (if you can get into this sort
of thing) even entertaining.  
</p>
<p>
* Some of the intermediate versions of this tutorial included materials on
actual programming interfaces for HPIB, and how to configure PC HPIB and GPIB
cards for the PC.  For various reasons, this turned out to be a clumsy
organization, and so those intermediate versions evolved into three
independent document:  this tutorial overview; a document on programming
interfaces; and a document on HPIB card configuration.
</p>
<hr />
<h1><a name="ib2_m0">[2.0] HPIB Tutor (2):  HPIB 488.1 / HPIB Fundamentals</a></h1>
<p>
* This module provides an overview of the fundamental HPIB specification,
IEEE 488.1
</p>
<hr />
<ul>
<li>
<a href="#ib2_m1">[2.1] 488.1 OVERVIEW</a>
</li>
<li>
<a href="#ib2_m2">[2.2] HPIB FUNCTIONS &amp; CAPABILITIES</a>
</li>
<li>
<a href="#ib2_m3">[2.3] HPIB SIGNAL LINES &amp; COMMANDS</a>
</li>
<li>
<a href="#ib2_m4">[2.4] HPIB ADDRESSING</a>
</li>
<li>
<a href="#ib2_m5">[2.5] HPIB COMMANDS</a>
</li>
<li>
<a href="#ib2_m6">[2.6] HPIB IN OPERATION -- AN HP BASIC EXAMPLE</a>
</li>
<li>
<a href="#ib2_m7">[2.7] HPIB IN PRACTICE</a>
</li>
<li>
<a href="#ib2_m8">[2.8] ASCII TABLE FOR HPIB</a>
</li>
</ul>
<hr />
<p>
<a href="#top">BACK TO INDEX </a>
</p>
<h2><a name="ib2_m1">[2.1] 488.1 OVERVIEW</a></h2>
<p>
* The Hewlett-Packard Interface Bus (HPIB) is a strictly-defined
general-purpose computer interface system, in effect an external computer bus
that allows interconnection of instruments and other devices to a controlling
computer.  General specifications of HPIB include:
</p>
<ul>
<li> A bus configuration will consist of a single Active Controller (though on

   occasions several controllers may reside on the same bus and &quot;pass
   control&quot; among each other) and one or more devices that can be instructed
   to &quot;talk&quot; or &quot;listen&quot; as instructed by the controller.
</li>
<li> Fifteen devices may be connected to one continuous bus.
</li>
<li> Total transmission path lengths over the interconnecting cables does not
   exceed 20 meters or 2 meters per device, whichever is less (when not using
   a bus extension technique).
</li>
<li> Data rate across the interface does not exceed 1 megabyte per second.
   (This data rate is rarely achieved in practice.) 
</li> 
 </ul>
<p>
Investigations for an interface system that led to the HPIB spec began in
1965, and eventually resulted in the first HPIB spec, now designated IEEE
488.1-1975.  Further work and investigations led to the additional spec for
common commands and data formats, designated IEEE-488.2-1987.
</p>
<p>
There are other specifications related to IEEE-488.1.  The ANSI MC1.1 spec
provides a definition identical to 488.1.  The IEC 625-1 and BS 6146 standards
are the same as 488.1, except that they provide interconnections through a
25-pin subminiature &quot;D&quot; connection, identical to that used on serial (RS-232)
interfaces.  These IEC and BS standards are very little used.
</p>
<p>
The 488.1 and related specifications cover the logical, electrical, and
mechanical specs of the HPIB system.  The 488.2 spec extends this definition
to provide a small set of common instrument commands and specifications for
data to be sent over the HPIB.  A further new specification, known as SCPI
(Standard Commands for Programmable Instrumentation), defines instrument
command sets for use over HPIB or other interfaces.  488.2 and SCPI are 
discussed in later modules in this series.
</p>
<p>
* The key specifications of IEEE 488.1 are listed below:
</p>
<ul>
<li> Interconnected devices:  Up to 15 maximum on one contiguous bus.
</li>
<li> Interconnection path:  Star or linear (or mixed) bus network, up to 20
   meters total transmission path length.
</li>
<li> Signal lines:  16 active lines, consisting of 8 data lines and 8
   communications management lines.
</li>
<li> Message transfer scheme:  Byte-serial, bit-parallel, asynchronous data
   transfer using an interlocking 3-wire handshake.
</li>
<li> Maximum data rate:  1 megabyte per second over limited distances, 250 to
   500 kilobytes per second typical maximum over a full transmission path.
   The actual data rate is determined by the devices on the bus.
</li>
<li> Address capability:  Primary addresses, 31 Talk and 31 Listen; secondary
   addresses, 961 Talk and 961 Listen.  There can be a maximum of 1 Talker
   and up to 14 Listeners at a time on a single bus.
</li>
<li> Pass control:  In systems with more than one controller, only one can be
   active at a time.  The currently active controller can pass control to one
   of the others.  A non-active controller may request control.  Only the
   controller designated as System Controller can demand control.
</li>
 </ul>
<h2><a name="ib2_m2">[2.2] HPIB FUNCTIONS &amp; CAPABILITIES</a></h2>
<p>
* The operation of the HPIB can be compared to that of a committee.  A
committee chairman controls which member talks and implies that the others
should listen.  IEEE 488.1 has one device that controls, deciding who talks
and who listens (under normal circumstances the controlling device will be
one half of the conversation, but it doesn't have to be).  Every IEEE 488.1
device must be capable of performing one or more of the following interface
functions:
</p>
<ul>
<li> Listener:  A device capable of receiving data over the interface when
   addressed to Listen by the Active Controller.  Examples of such devices
   are printers, programmable power supplies, or any other programmable
   instrument.  There can be up to 14 Listeners on the HPIB at one time;
   usually the Active Controller will be a Talker while a single device is a
   Listener.
</li>
<li> Talker:  A device capable of transmitting data over the interface when
   addressed to Talk by the Active Controller.  Examples of such devices are
   voltmeters, data-acquisition systems, or any other programmable
   instrument.  There can be only one addressed Talker on the HPIB at one
   time.  Usually the Active ontroller will be a Listener while a device is a
   Talker.
</li>
<li> Controller:  A device capable of specifying the Talker and Listeners for a
   data or command transfer.  Note that the Active Controller will be
   configured as Listener or Talker to support its end of the transfer.
   There can be only one addressed controller on the interface at one time;
   in multiple controller systems active control may be passed between
   controllers, but only one can be a master &quot;System Controller&quot;.
</li> 
 </ul>
<p>
The IEEE 488.1 spec defines these functions in (agonizingly) concise terms
using abstract state machines labeled with rigorously-defined nomenclature.
These functions are referred to as interface capabilities.
</p>
<p>
There are other interface capabilities besides Listener, Talker, or
Controller, which are also defined in the 488.1 spec as state machines.
These functions are listed below, along with their abbreviations:
</p>
<ul>
<li> Talker / Extended Talker (T / TE):  Capability required for a device to
   Talk.  Extended Talker is a Talker that supports secondary addressing.
</li>
<li> Listener / Extended Listener (L / LE):  Capability required for a device
   to Listen.  Extended Listener is a Listener that supports secondary
   addressing.
</li>
<li> Source Handshake (SH):  Allows a device to send command or data bytes over
   the HPIB using the HPIB &quot;three-wire handshake&quot; (to be explained
   presently).
</li>
<li> Acceptor Handshake (AH):  Allows a device to receive command or data bytes
   over the HPIB using the three-wire handshake.
</li>
<li> Remote / Local (RL):  Provides the capability to switch a device between
   response to its front-panel controls (LOCAL) and response to commands sent
   over the HPIB (REMOTE).
</li>
<li> Service Request (SR):  Allows a device to assert an interrupt, or &quot;service
   request&quot; (SRQ), over the HPIB to obtain service from the Active
   Controller.
</li>
<li> Parallel Poll (PP):  Provides the capability for a device to identify that
   it needs service when the Active Controller requests such status.  This
   particular capability is little used.
</li>
<li> Device Clear (DC):  Allows a device to be reset.  Its actions are
   implementation-dependent.
</li>
<li> Device Trigger (DT):  Allows a device to be &quot;triggered&quot; by an HPIB command
   to perform some implementation-dependent function.
</li>
<li> Controller (C):  Allows a device to send addresses, universal commands,
   and addressed commands to other devices on the HPIB.  It may also include
   the capability to conduct polling to determine devices requiring service.
</li>
<li> Drivers (E):  Describes the type of electrical bus drivers used in a
   device.
</li>
 </ul>
<p>
The IEEE 488.1 spec also defines subsets of these functions, given by a
number appended to the function code.  The spec recommends that each device
be marked near its connector with the interface capability codes for the
functions the device supports.  
</p>
<p>
For example, a device with:
</p>
<pre><strong>
   Talk capability.
   The ability to send status bytes.
   Listen capability.
   A Listen-only mode switch.
   Service request capability.
   Full remote-local capability without local lockout.
   Local configuration of the parallel poll capability.
   Complete device clear capability.
   No capability for device trigger.
   No Controller capability.
</strong></pre>
<p>
-- would be identified with these codes:
</p>
<pre><strong>
   SH1  AH1  T6  L3  SR1  RL2  PP2  DC1  DT0  C0  E1
</strong></pre>
<p>
A full description of the IEEE 488.1 spec's discussion of these capabilities
is far beyond the scope of this document, and is in fact generally only
useful for design engineers building HPIB devices.
</p>
<h2><a name="ib2_m3">[2.3] HPIB SIGNAL LINES &amp; COMMANDS</a></h2>
<p>
* The physical interconnection system used in HPIB uses a shared-bus
structure, with 16 signal lines and 8 ground lines.  The bus signal lines all
use a low-true logic convention, and can be grouped into 3 sets:
</p>
<ul>
<li> data lines
</li>
<li> byte transfer (handshake) lines
</li>
<li> general bus managment lines
</li>
</ul>
<p>
The organization of the signal lines is shown below:
</p>
<pre><strong>
   DIO1 ---------------------------------  -+
   DIO2 ---------------------------------   |
   DIO3 ---------------------------------   |
   DIO4 ---------------------------------   | data lines
   DIO5 ---------------------------------   |
   DIO6 ---------------------------------   |
   DIO7 ---------------------------------   |
   DIO8 ---------------------------------  -+
 
   NDAC ---------------------------------  -+
   NRFD ---------------------------------   | handshake lines
    DAV ---------------------------------  -+

    EOI ---------------------------------  -+
    REN ---------------------------------   |
    SRQ ---------------------------------   | general bus management lines
    ATN ---------------------------------   |
    IFC ---------------------------------  -+
</strong></pre>
<p>
The signal lines use TTL voltage levels.  The pinouts are as follows:
</p>
<pre><strong>
                                            * 
                                       *      * 
                                  *           *
                  SIGNAL GROUND   * [24] [12] *   SHIELD (to earth ground)
   twisted-pair ground with ATN   * [23] [11] *   ATN
   twisted-pair ground with SRQ   * [22] [10] *   SRQ
   twisted-pair ground with IFC   * [21] [ 9] *   IFC
   twisted-pair ground with NDAC  * [20] [ 8] *   NDAC
   twisted-pair ground with NRFD  * [19] [ 7] *   NRFD
   twisted-pair ground with DAV   * [18] [ 6] *   DAV
                            REN   * [17] [ 5] *   EOI
                           DIO8   * [16] [ 4] *   DIO4
                           DIO7   * [15] [ 3] *   DIO3
                           DIO6   * [14] [ 2] *   DIO2
                           DIO5   * [13] [ 1] *   DIO1
                                  *           *
                                       *      *
                                            * 
</strong></pre>
<p>
The data lines allow information transfer a byte at a time.  Device commands
and data are often transferred as strings of ASCII characters for ease of
use, while large blocks of data are often transferred as binary data for
speed and compactness.  The data lines are also used by the HPIB protocol to
send HPIB interface commands and addresses as bytes.
</p>
<p>
The three handshake lines are used to transfer bytes over the data lines from
a source (an addressed Talker or an Active Controller) to an acceptor (an
addressed Listener or all devices receiving interface commands).  The byte
transfer controlled by the handshake lines allows more than one device to
accept bytes simultaneously, and is &quot;asynchronous&quot;:  that is, the rate of
byte transfer is determined both by the source and acceptor(s), and can in
principle take as long as necessary.  When there are multiple acceptors, the
byte transfer will take place at the speed of the slowest one.
</p>
<p>
The three handshake lines are defined as follows:
</p>
<ul>
<li> DAV (DAta Valid):  Used by the source to indicate that a byte is ready to
   be read.
</li>
<li> NRFD (Not Ready For Data):  Used by acceptor to indicate that it is not
   ready to receive a byte.
</li>
<li> NDAC (Not Data Accepted):  Used by the acceptor to indicate that it has
   not yet read the byte.
</li>
 </ul>
<p>
The low-true logic of the handshake lines can be confusing.  The protocol can
be outlined as follows:
</p>
<pre><strong>
   1:  NRFD HIGH   All acceptors ready for byte.
   2:  DAV LOW     Source says byte is valid ...
   3:  NRFD LOW    ... so acceptors drop NRFD line.
   4:  NDAC HIGH   All acceptors have accepted byte ...
   5:  DAV HIGH    ... so source raises DAV line ...
   6:  NDAC LOW    ... and acceptors drop NDAC line.
   1:  NRFD HIGH   All acceptors ready for next byte, cycle begins again.
 </strong></pre>
<p>
Neither NRFD nor NDAC will go high unless all acceptors make them high.
This allows the speed of the byte transfer to be controlled by the slowest
acceptor. <em>all</em> 
</p>
<p>
The following illustration shows the handshake in a different way:
</p>
<pre><strong>
      +---------------------------------------------------------------+
      |                                                               |
      |             .......................               ........... |
 byte | ............                       ...............            |
      |             .......................               ........... |
      |                                                               |
      | ..............                   ....................         |
 DAV  |              :                   :                  :         |
      |              :...................:                  :........ |
      |                                                               |
      |       ...........                            ...........      |
 NRFD |       : : :     :                            : : :     :      |
      | ......:.:.:     :............................:.:.:     :..... |
      |                                                               |
      |                           ...........                         |
 NDAC |                           : : :     :                         |
      | ..........................:.:.:     :........................ |
      |                                                               |
      +-----------+--+--+-------------+--+--+------------+--+--+------+
                  |  |  |             |  |  |            |  |  |
                  1  2  3             4  5  6            1  2  3
 </strong></pre>
<p>
* The five general bus management lines are used to manage the orderly flow
of information over the HPIB:
</p>
<ul>
<li> ATN (ATtentioN):  The ATN line is used by the Active Controller to
   indicate to all the devices on the HPIB that command and address bytes are
   being sent.  These bytes are used to address Listeners and Talkers, obtain
   device status, and the like.  When ATN is asserted, all devices must be
   able to respond to it within 200 nanoseconds and cease their current HPIB
   operations.
</li>
<li> IFC (InterFace Clear):  The IFC line is used by the System Controller to
   reset the HPIB.  When IFC is asserted, all devices must respond within 100
   microseconds:  the Talker and Listeners are unaddressed and Serial Poll is
   disabled.
</li>
<li> REN (Remote ENable):  The REN line is used by the System Controller to put
   devices in the remote programming mode.  When asserted, all Listeners are
   placed in remote mode when addressed to Listen.  
<p>
   The 488.1 spec was relaxed in 1987 to permit devices to ignore the state
   of this line, but older devices will honor it.
</p>
</li>
<li> SRQ (Service ReQuest):  The SRQ line is used by HPIB devices to interrupt
   the Active Controller, which then performs a Serial Poll or Parallel Poll
   to determine which device requested service, and why.  The poll clears the
   SRQ.
</li>
<li> EOI (End Or Identify):  When ATN is asserted, the EOI line is used by the
   Active Controller to conduct a Parallel Poll.  When ATN is false, the EOI
   line may be used by the Talker to indicate the last byte of a stream of
   bytes.
</li>
 </ul>
<p>
The signal lines are driven either by open-collector or tristate drivers.
Maximum data rate is 250 kilobytes per second for open-collector drivers and
1 megabyte per second for tristate drivers.
</p>
<p>
The connector for the HPIB cable allows connectors to be stacked on top of
each other, to allow for daisy-chained or star connections (though the stack
grows clumsy above three levels of stacking).  Some specialized HPIB cables
(such as those often used on personal computers, where access to I/O cards is
mechanically restricted) may have a connector that does not permit stacking.
</p>
<p>
* Note the important distinction between the operation of the HPIB when ATN
is asserted and when it is released.  When ATN is asserted by the Active
Controller, the HPIB is in Command Mode:  the Active Controller configures
the HPIB or performs other control tasks.  When ATN is released, the HPIB is
in data mode:  the addressed Talker sends bytes to the addressed Listeners.
</p>
<p>
In Command Mode, the Active Controller sends four classes of commands:
</p>
<ul>
<li> Talk and Listen addresses are bytes that define which device on the HPIB
   will be the active Talker and which will be the active Listeners.  When
   ATN is asserted, all devices will be waiting for commands.  All will
   receive the address bytes, and those who match those addresses will accept
   them.
</li>
<li> Universal commands are commands the Active Controller sends to <em>all</em>
   devices on the HPIB, and all instruments capable of reacting to the
   commands do so.  The universal commands include five commands encoded as
   bytes sent over the DIO lines (&quot;multiline&quot; commands) and four commands
   sent using the general bus management lines (&quot;uniline&quot; commands).
</li>
<li> Addressed commands are byte commands similar to the universal multiline
   commands, except that they apply only to those devices that have been
   addressed.
</li>
<li> Secondary commands are byte commands that are always used in addition to
   addresses, multiline universal commands, or addressed commands (the
   &quot;primary commands&quot;) to add command functionality.  They are used, for
   example, to support secondary addressing.
</li>
 </ul>
<p>
In data mode (ATN released), device-dependent data (device programming
command bytes, measurement data bytes, and status bytes) is transferred from
the addressed Talker to the addressed Listeners.  Only the addressed
Listeners actually handshake the byte.
</p>
<p>
The actual format for the device-dependent data is beyond the scope of the
488.1 spec.  It can, and does, have any format desired by the device
manufacturers.  The 488.2 and SCPI specs have made substantial progress in
clearing up this chaotic situation, however.
</p>
<p>
* Most common operations on an HPIB consist of byte transfers between an
addressed Talker and addressed Listener(s), as well as capabilities to clear
devices either singly or universally, and trigger them to perform some
device-dependent function.  The signal lines and command set, as described
above, also support some other functionality:
</p>
<ul>
<li> A device can interrupt the Active Controller by asserting the SRQ line, as
   discussed above.  The SRQ is a single line, however, and if there are
   multiple devices on the HPIB that have been configured to assert an SRQ,
   the Active Controller will have to &quot;poll&quot; the devices to figure out which
   one actually asserted the SRQ.  
<p>
   More than one device could in principle assert an SRQ at the same time.
   The Active Controller can poll the devices in one of two ways:  serial
   poll or parallel poll.
</p>
</li>
<li> In a serial poll, the Active Controller asks each device in turn to send
   back a status byte that indicates whether the device has asserted the SRQ.
<p>
   Bit 6 of this byte (where the bits are numbered 0 through 7) is set if the
   device is requesting service.  The definition of the other bits is
   device-dependent (under 488.1 at least; 488.2 provides a much more concise
   definition of the status byte).
</p>
<p>
   The Active Controller performs a serial poll by addressing the device to
   Talk, then sends the SPE (Serial Poll Enable) command byte.  The Active
   Controller releases ATN, and the device returns the status byte.  The
   Active Controller then reasserts ATN and sends the SPD (Serial Poll
   Disable) command byte to end the poll sequence.  The Active Controller
   performs this same sequence with every device it needs to poll.
</p>
</li>
<li> That makes serial poll of a large system relatively slow, so the 488.1
   spec also defines a parallel poll that allows multiple devices to respond
   simultaneously.  However, this scheme is so complicated that it is almost
   never used.  (We had an HPIB product that implemented parallel poll, but
   did it with an unavoidable bug.  We didn't find out about it for almost
   three years after it was introduced.)
<p>
   In a parallel poll, each device is assigned one of the 8 DIO lines to
   respond on, as well as whether to respond with a 1 or with a 0.  This
   assignment is made by sending the PPC (Parallel Poll Configure) command
   byte to the addressed Listeners, followed by a PPE (Parallel Poll Enable)
   secondary command (which can take on a range of values large enough to
   encode all the response options).
</p>
<p>
   To parallel poll the devices, the Active Controller asserts the EOI and
   ATN lines simultaneously, and all the devices capable of responding to
   parallel poll put their approriate 1 or 0 on their appropriate DIO line in
   response.  The Active Controller reads this composite byte and uses it to
   determine which devices have requested service.
</p>
<p>
   To disable parallel poll, the Active Controller sends a PPC command byte
   to the addressed Listeners, followed by a PPD (Parallel Poll Disable)
   secondary command byte.
</p>
</li>
<li> It is also possible to have multiple controllers on the same HPIB.  One is
   designated System Controller; it is the only one that has control of the
   IFC line.  It can pass active control of the HPIB to another controller,
   which can pass control in turn to a third controller, and so on.  The
   System Controller can always take back control from the Active Controller
   by asserting IFC to bring the HPIB back to its reset configuration.
<p>
   The Active Controller can pass control to another controller by addressing
   it to Talk and then sending it the TCT (Take Control) addressed command
   byte.  This capability is infrequently used (and tends to lead to a lot of
   trouble when people use it and don't understand it).
</p>
</li>
 </ul>
<p>
The addressing scheme and command bytes are discussed in more detail in the
following sections.
</p>
<h2><a name="ib2_m4">[2.4] HPIB ADDRESSING</a></h2>
<p>
* Every 488.1 device has at least one Talk and Listen address (with the
exception of freak antique devices that only Talk or Listen).  A device's
address is normally set at the factory, but can traditionally be changed 
(in older devices) by adjusting a set of DIP switches or (in more modern
instruments) with front-panel inputs.  Many devices display their HPIB
address on power-up.
</p>
<p>
If the device has DIP switches, they are usually arranged as follows:
</p>
<pre><strong>
       1    2    4    8   16
   +---------------------------+
   |  +-+  +-+  +-+  +-+  +-+  | 1
   |  |X|  | |  |X|  | |  | |  |
   |  | |  |X|  | |  |X|  |X|  |
   |  +-+  +-+  +-+  +-+  +-+  | 0
   +---------------------------+
       A1   A2   A3   A4   A5
 </strong></pre>
<p>
This switch setting gives an address of 5.  In nearly all cases an instrument
has the same Talk and Listen address.  The 488.1 spec allows them to be
different, but in practice that is a useless complexity.  Most modern
instruments allow the user to press a button to display the current HPIB
address to eliminate the need to turn the instrument around and figure out
the switch settings.
</p>
<p>
The switch settings allow the device to be set to Talk/Listen addresses from
0 to 30.  The Listen address bytes are defined by adding a decimal value of 32
to the address, while the Talk address bytes are defined by adding a decimal
value of 64 to the address.  For the example given by the switch settings
above, this gives the following address bytes:
</p>
<pre><strong>
   Listen address 5 = 32 + 5 = 37 decimal = 001 00101 binary
   Talk address 5 =   64 + 5 = 69 decimal = 010 00101 binary
 </strong></pre>
<p>
The Talk and Listen address bytes are often referred to in documentation by
the mnemonics TAD (Talk ADdress) and LAD (Listen ADdress).  The full range of
Talk addresses is therefore given by TAD0 through TAD30, and the full range
of Listen addresses is given by LAD0 through LAD30.
</p>
<p>
Remember that a Controller also has a Talk and Listen address to allow it to
transfer bytes in data mode to other devices on the HPIB.  21 and 30 are
common Controller Talk / Listen addresses in HP equipment, though it can be
any address.  Note that adding a device with the same address as the
Controller is a common error, and can lead to baffling problems.
</p>
<p>
The Controller's Talk and Listen address are often referred to as MTA (My
Talk Address) and MLA (My Listen Address) for convenience, but there's no
difference between the address format used by the Controller and by devices.
Note that the Controller has to send the address bytes even when it is
addressing itself!
</p>
<p>
Note also that the address switches can physically be set to a value of 31,
but that is <em>not</em> a valid HPIB address!  The address byte that has the
value 32 + 31 = 63 decimal is <em>not</em> LAD31, it's a special address byte
called Unlisten (UNL), which tells the currently addressed Listeners to stop
being Listeners, usually preparatory to addressing new Listeners.
</p>
<p>
Similarly, the address byte that has the value 64 + 31 = 95 decimal is not
TAD31, it's a special address byte called Untalk (UNT), which tells the
currently addressed Talker to stop being a Talker, usually preparatory to
assigning a new Talker.  
</p>
<p>
Actually Untalk is a little redundant, since sending out a new TAD will
automatically Untalk the current Talker -- as there can be only one Talker at
a time.
</p>
<p>
* As noted, the 488.1 spec allows the 31-address limit to be extended to 961
addresses with a &quot;secondary address&quot; byte.  This byte is sent after a
LAD or TAD byte and consists of the decimal value 96 added to an address in
the range of 0 through 30.  This secondary address byte is referred by the
mnemonic SC, giving the secondary address bytes SC0 through SC31.  
</p>
<p>
There is no secondary address 31, even though that byte is not otherwise
used.  Apparently this convention was specified for consistency with the
primary Talk/Listen address bytes.
</p>
<p>
Secondary addresses are not normally used to allow addressing of more devices
on the HPIB.  As noted, the HPIB cannot accommodate more than 15 instruments
under normal conditions, and the idea of a system having anywhere near 961
devices is hard to take seriously.  It is more often used to allow individual
access to different modules in a modular instrument system, such as a VXI
mainframe or data-acquisition box, which in either case consist of a chassis
containing multiple plug-in cards that perform separate functions.
</p>
<p>
There are modular devices in which different modules are selected by sending
a high-level command to the mainframe in which they are plugged.  Such
schemes are not standardized and vary widely, but are collectively referred
to as &quot;subaddressing&quot;, if only as a term of convenience.  Please take care
when programming a modular instrument to determine if the instrument supports
secondary addressing or subaddressing.
</p>
<h2><a name="ib2_m5">[2.5] HPIB COMMANDS</a></h2>
<p>
* The five universal multiline (byte) commands are, as noted, accepted by
<em>all</em> devices on the HPIB.  The commands consist of:
</p>
<ul>
<li> DCL (Device CLear):  The universal DCL command causes all devices to
   return to a device-dependent initial state.
</li>
<li> LLO (Local LockOut):  The LLO command disables the return-to-local front
   panel key on the device; the user can no longer change the device settings
   from its front panel.
</li>
<li> SPE (Serial Poll Enable):  The SPE command tells the addressed Talker to
   return a single status byte.  This status byte tells whether the device
   has asserted an SRQ (indicated by bit 6 set to 1).
</li>
<li> SPD (Serial Poll Disable):  The SPD command takes the device out of
   serial poll mode and returns it to normal Talker activity.
</li>
<li> PPU (Parallel Poll Unconfigure):  The PPU command resets all parallel
   poll devices to an idle state.  As noted earlier, parallel poll is little
   used.
</li>
 </ul>
<p>
* The four complementary uniline universal commands consist of the three
general bus managements lines IFC, REN, and ATN executing their normal
functions, plus the combination of EOI and ATN, which is used to conduct a
parallel poll, as described earlier.
</p>
<p>
* The addressed command bytes are only accepted by addressed devices.
Whether the devices are the Listeners or the Talkers depends on the command.
The five commands are as follows:
</p>
<ul>
<li> GET (Group Execute Trigger):  The GET command tells all the addressed
   Listeners to perform some device-dependent function, like take a
   measurement.  GET allows for synchronizing a measurement function between
   multiple devices.  This is only used in specialized cases.
</li>
<li> SDC (Selected Device Clear):  The SDC command resets the addressed
   Listeners to a device-dependent state.  It performs the same function as
   DCL, but only resets the addressed Listeners, not all the devices.
</li>
<li> GTL (Go To Local):  The GTL command sets the addressed Listeners back to
   local mode.
</li>
<li> PPC (Parallel Poll Configure):  The PPC command causes the addressed
   Listeners to be configured by the Parallel Poll Enable secondary command
   byte that immediately follows this byte.
</li>
<li> TCT (Take Control Talker):  The TCT command tells the addressed Talker to
   become the active Controller.
</li>
 </ul>
<p>
* The two secondary commands consist the PPE (Parallel Poll Enable) and PPD
(Parallel Poll Disable).  Both are send to the addressed Listeners after they
receive the PPC byte.
</p>
<p>
PPE actually consists of a set of commands that have the exact same values
(96 plus 0 through 30) as the secondary address bytes.  A PPE command byte is
distinguished from the matching secondary address byte by the fact that a PPE
byte follows a PPC command byte, while the secondary address byte follows a
Talk or Listen address.
</p>
<p>
PPE configures the addressed Listeners that receive it to respond to a
parallel poll by setting a given DIO line to a particular polarity (1 or 0).
PPD tells the addressed Listeners not to respond to a parallel poll.
</p>
<h2><a name="ib2_m6">[2.6] HPIB IN OPERATION -- AN HP BASIC EXAMPLE</a></h2>
<p>
* Now that we have considered the theoretical aspects of the 488.1
specification, let's put all these details together by observing the HPIB
transactions of a typical HPIB controller.
</p>
<p>
In this case, the controller is a computer running HP's measurement-oriented
HP BASIC language, connected to a 34401 digital multimeter (DMM) over HPIB.
The Controller's HPIB interface is designated by a one-digit number code
called an &quot;interface select code&quot;, or ISC.  The default ISC is usually 7.
</p>
<p>
The DMM is set to its default HPIB address of 22.  HP BASIC locates the
instrument by tacking the HPIB address onto the end of the ISC, so the DMM is
identified by the number 722.  The controller itself in this case has a
default Talk/Listen address of 30.
</p>
<p>
The following HP BASIC program clears the DMM, reads a DC voltage from it,
prints it, serial-polls the DMM, and prints the results.  The only reason
that the serial poll is conducted is to give the program another thing to
show off.  There normally isn't any reason to do a serial poll after taking a
measurement, though it is a simple way to determine if any gross instrument
errors have occurred.
</p>
<pre><strong>
   10    REAL Rdg
   20    INTEGER Stat
   30    ASSIGN @Dmm TO 722                    ! Define DMM HPIB address.
   40    CLEAR 7                               ! Clear HPIB interface.
   50    OUTPUT @Dmm;&quot;*RST&quot;                    ! Reset DMM. 
   60    OUTPUT @Dmm;&quot;*CLS&quot;                    ! Clear DMM.
   70    OUTPUT @Dmm;&quot;MEASURE:VOLTAGE:DC? DEF&quot; ! Measure DC voltage.
   80    ENTER @Dmm;Rdg                        ! Get value back.
   90    PRINT &quot;Reading Value:      &quot;;Rdg      ! Print it.
   100   Stat=SPOLL(@Dmm)                      ! Serial poll DMM.
   110   PRINT &quot;Serial Poll status: &quot;;Stat     ! Print status value.
   120   END
 </strong></pre>
<p>
Let's take a look at the statements in the program in detail.
</p>
<p>
* The first three lines simply declare variables.  &quot;Rdg&quot; is a REAL variable
used to store the voltage reading; &quot;Stat&quot; is an INTEGER variable used to
store the status byte returned by the serial poll; and &quot;@Dmm&quot; is an &quot;I/O
path&quot; or &quot;I/O handle&quot; that stores the device address of 722.
</p>
<p>
The statement:
</p>
<pre><strong>
   CLEAR 7
</strong></pre>
<p>
-- simply clears all the devices on the HPIB, though there's only one in this
case.  The HPIB operations performed are as follows:
</p>
<pre><strong>
   REN  ATN      : DCL
 </strong></pre>
<p>
This table and the ones that follow give the byte(s) transferred by the HP
BASIC statement and the status of the bus-management lines.  The 3-wire
handshake is implied in each byte transfer, and so will not be mentioned.
Just remember that each line in a table defines a single byte transfer using
the 3-wire handshake.
</p>
<p>
The right side of the table gives the byte transferred.  In this case it is
the universal command byte, DCL, or Device CLear, which clears the interfaces
of the instruments on the HPIB.
</p>
<p>
The left side of this table gives the status of the three control lines REN,
ATN, and EOI.  SRQ and IFC are always inactive in this sequence of examples,
so they won't be shown.  REN and ATN are active, indicating a command byte, so
they are shown.  EOI is inactive and is not shown.
</p>
<p>
The next statement is:
</p>
<pre><strong>
   OUTPUT @Dmm;&quot;*RST&quot;
 </strong></pre>
<p>
The OUTPUT statement is used by HP BASIC to send bytes over the HPIB to the
remote device, the DMM.  In this example, the following bytes are sent:
</p>
<pre><strong>
   REN  ATN      : TAD30 (MTA)
   REN  ATN      : UNL
   REN  ATN      : LAD22
   REN           : &quot;*&quot;
   REN           : &quot;R&quot;
   REN           : &quot;S&quot;
   REN           : &quot;T&quot;
   REN           : CR
   REN           : LF
 </strong></pre>
<p>
The first three bytes are sent to set up the Controller as a Talker and the
DMM as a Listener, and then the ASCII string &quot;*RST&quot; (device Reset) is sent to
the DMM.  The string is &quot;terminated&quot; by the carriage-return (CR) and line-feed
(LF) control characters -- that is, when the DMM receives the CR-LF, it
assumes that the command is complete and acts upon it.
</p>
<p>
Note how ATN is active when sending the three HPIB command bytes, and how it
is inactive when sending the instrument command string.
</p>
<p>
Another OUTPUT statement follows:
</p>
<pre><strong>
   OUTPUT @Dmm;&quot;*CLS&quot;
 </strong></pre>
<p>
This performs roughly the same actions as the first OUTPUT statement but
with a different string, &quot;*CLS&quot; (clear status):
</p>
<pre><strong>
   REN  ATN      : TAD30 (MTA)
   REN  ATN      : UNL
   REN  ATN      : LAD22
   REN           : &quot;*&quot;
   REN           : &quot;C&quot;
   REN           : &quot;L&quot;
   REN           : &quot;S&quot;
   REN           : CR
   REN           : LF
 </strong></pre>
<p>
Note that the OUTPUT statement sends the same MTA-UNL-LAD22 addressing
sequence that was sent in the previous step.  In theory that is redundant --
the Controller is already the addressed Talker and the DMM is already the
addressed Listener -- and in fact there is a way in HP BASIC to eliminate the
addressing sequence, but in practice that is generally a useless
micro-efficiency.
</p>
<p>
Note also that &quot;*RST&quot; and &quot;*CLS&quot; are &quot;common commands&quot; that are defined by
the 488.2 spec.  They will be discussed in more detail in a later chapter.
</p>
<p>
The question arises:  why send these commands if we've already sent a DCL?
Simple answer:  DCL only resets the HPIB interface on the DMM, and returning
the instrument to a completely known state requires a little more work.
</p>
<p>
The third OUTPUT statement:
</p>
<pre><strong>
   OUTPUT @Dmm;&quot;MEASURE:VOLTAGE:DC? DEF&quot;
 </strong></pre>
<p>
-- sends the DMM command bytes needed to tell the DMM to read a DC voltage:
</p>
<pre><strong>
   REN  ATN      : TAD30 (MTA)
   REN  ATN      : UNL
   REN  ATN      : LAD22
   REN           : &quot;M&quot;
   REN           : &quot;E&quot;
   REN           : &quot;A&quot;
   REN           : &quot;S&quot;
   REN           : &quot;U&quot;
   REN           : &quot;R&quot;
   REN           : &quot;E&quot;
   REN           : &quot;:&quot;
   REN           : &quot;V&quot;
   REN           : &quot;O&quot;
   REN           : &quot;L&quot;
   REN           : &quot;T&quot;
   REN           : &quot;A&quot;
   REN           : &quot;G&quot;
   REN           : &quot;E&quot;
   REN           : &quot;:&quot;
   REN           : &quot;D&quot;
   REN           : &quot;C&quot;
   REN           : &quot;?&quot;
   REN           : &quot; &quot;
   REN           : &quot;D&quot;
   REN           : &quot;E&quot;
   REN           : &quot;F&quot;
   REN           : CR
   REN           : LF
 </strong></pre>
<p>
Other than the string being longer, this is identical in logic to the
previous two output statements.  Note that the DMM command conforms to the
SCPI command set, which will be discussed in detail in a later chapter.  The
command string's meaning in this case should be obvious, except for the &quot;DEF&quot;
string, which specifies the DEFault voltage range for the DMM.
</p>
<p>
Now that the HP BASIC program has told the DMM to read the voltage using an
OUTPUT statement, the program has to read the voltage value back, using the
matching ENTER statement:
</p>
<pre><strong>
   ENTER @Dmm;Rdg
 </strong></pre>
<p>
This performs the actions:
</p>
<pre><strong>
   REN ATN       : UNL
   REN ATN       : LAD30 (MLA)
   REN ATN       : TAD22
   REN           : &quot;-&quot;
   REN           : &quot;1&quot;
   REN           : &quot;.&quot;
   REN           : &quot;4&quot;
   REN           : &quot;5&quot;
   REN           : &quot;0&quot;
   REN           : &quot;5&quot;
   REN           : &quot;2&quot;
   REN           : &quot;0&quot;
   REN           : &quot;4&quot;
   REN           : &quot;0&quot;
   REN           : &quot;E&quot;
   REN           : &quot;+&quot;
   REN           : &quot;0&quot;
   REN           : &quot;1&quot;
   REN       EOI : LF
 </strong></pre>
<p>
The ENTER statement is similar to the OUTPUT statement, except that the
direction of byte transfer is reversed:  the Controller is the Listener and
the DMM is the Talker.  The DMM returns the voltage value as a string; the
terminator at the end of the value is a line-feed combined with assertion of
the EOI line.  This particular termination scheme is defined in the 488.2
spec.
</p>
<p>
Once the program receives the voltage value back, it is printed to the 
computer's display with:
</p>
<pre><strong>
   PRINT &quot;Reading Value:      &quot;;Rdg
 </strong></pre>
<p>
The HP BASIC program then queries the DMM for serial-poll status with:
</p>
<pre><strong>
   Stat=SPOLL(@Dmm)
 </strong></pre>
<p>
This performs the following actions:
</p>
<pre><strong>
   REN ATN       : UNL
   REN ATN       : LAD30 (MLA)
   REN ATN       : TAD22
   REN ATN       : SPE
   REN           : 0
   REN ATN       : SPD
   REN ATN       : UNT
 </strong></pre>
<p>
The Controller sets itself up as an addressed Listener and sets up the DMM as
an addressed Talker.  The Controller then send the SPE (Serial Poll Enable)
command byte to tell the DMM to respond to the poll.  The DMM returns a byte
with the value of 0 (same as the NULL character) indicating it has nothing to
report.  Note that ATN is released when the poll-response byte is returned,
as only the Controller can send bytes while it is asserted.  ATN is then
asserted again, the Controller sends the SPD (Serial Poll Disable) command
byte, and then UNTalks the DMM.
</p>
<p>
* This example covers the vast majority of what is in practice done by HPIB
users:  it sends a command to one device and reads back a value from it, then
polls the device for errors.
</p>
<p>
To be sure, this example is oversimplified, in that instruments often return
large amounts of data.  Sending numeric data in string format is
time-consuming and clumsy, so in practice large blocks of data are sometimes
sent in binary format.  It would have been nice to have had the DMM assert an
SRQ, but configuring the DMM to do so is too complicated for a simple
example.
</p>
<p>
It is also appropriate in most cases to set an I/O timeout on a device in an
HP BASIC program (using the ON TIMEOUT statement) to prevent the program from
hanging if the DMM doesn't respond in the 3-wire handshake, but again, for
simplicity, this was not done.
</p>
<p>
Note that in this example, there is only one addressed Talker and one
addressed Listener.  While the 488.1 spec does allow for multiple addressed
Listeners, in practice there is usually only one.  No parallel poll is
performed; as noted, it is virtually never done.  A pass control is not
performed; this can be a complicated procedure, and the situations that
require it are rare.
</p>
<h2><a name="ib2_m7">[2.7] HPIB IN PRACTICE</a></h2>
<p>
* After its introduction in the 1970s, HPIB was commonly used to interface
instruments, printers and plotters, and disk drives to early personal
computers and workstations.  HP, not surprisingly, was strongly dedicated to
HPIB and came out with a wide range of HPIB devices that were hooked up to
dedicated BASIC-language workstation computers that often had built-in HPIB
ports.
</p>
<p>
Over time, HPIB printers, plotters, and disk drives, as well as dedicated
BASIC-language workstations, became extinct, but HPIB remained and remains
important for constructing instrumentation systems, using UNIX (tm)
workstations and (in particular) personal computers as Controllers.  A
plug-in HPIB card is used to connect the controller to a benchtop or rack of
instruments; standard languages, such as C or BASIC, are generally used to
direct the system.
</p>
<p>
There are a variety of different plug-in cards available from different
vendors for different platforms, generally based on the Texas Instruments
9920 chip or the Nippon Electric 7210 chip.  National Instruments (NI)
introduced an IC of their own that can be switched to function either as the
TI chip or the NEC chip, and have used it on their own HPIB cards.  The
different vendors' cards are not in general compatible at a hardware level.
</p>
<p>
For the most part, the HPIB cards are controlled by standard programming
languages such as C or BASIC, through a special library of subprogram calls
provided with the HPIB card.  Traditionally, these libraries have not been
compatible, either, though NI did provide a driver for Windows named GPIB.DLL
that other vendors emulated. 
</p>
<p>
HP devised their own standardized interface control library, named SICL
(Standard Instrument Control Language), and further efforts have been made to
create a &quot;universal&quot; interface control library that is supported by multiple
vendors.  This universal library has the name VISA (Virtual Instrument
Standard Interface).  So far, VISA has met with limited success.
</p>
<p>
The libraries are useful for writing programs to control instruments from a
controller.  HPIB is very well thought-out and interfacing from a controller
to an instrument is easy.
</p>
<p>
However, it is much more difficult to use them to write a program that allows
a computer to be used as a &quot;device&quot; by a separate controller, since this
requires a low-level knowledge of the HPIB spec.  An experienced programmer
will take many months to master the specs.  Similarly, multiple-controller
applications are difficult to set up, and should be regarded with caution.
</p>
<p>
External HPIB interfaces are also available that plug into a parallel port.
Software drivers allow such interfaces to be accessed as if they were
directly plugged into the PC.  
</p>
<p>
A particularly interesting new technology is the LAN-HPIB bridge, which is
a small box that contains a LAN and HPIB interface and allows communications
with an HPIB device over a network.  With the proper software, such a
LAN-HPIB bridge can be largely transparent to software, though the user has
to remember that the LAN is a mutual-access interface and that latency times
can be long.
</p>
<p>
HPIB bus extenders are available that allow operation of HPIB systems over
long distances, using a coaxial-cable or fiber-optic link.  There are also
extenders that operate as modems, allowing in principle operation over any
distance, but they are suspect since they don't always meet HPIB timing
specs.
</p>
<p>
National Instruments has defined a &quot;TNT&quot; spec extension to HPIB to
allow extremely high operation speeds, but such a claim should be regarded
skeptically:  the TNT spec will only work if the remote devices support
it, and few do.  
</p>
<p>
In general, maximum performance over an HPIB system is in the 100 KB to 250
KB range when performing long data transfers.  In all but the most highly
optimized systems, overall program operations determines the speed, not raw
HPIB throughput.  Specs for HPIB cards claiming much higher speeds should
also be regarded skeptically:  such performance figures are based on
unrealistic tests, and in practice one HPIB card is just about as fast as the
other.
</p>
<h2><a name="ib2_m8">[2.8] ASCII TABLE FOR HPIB</a></h2>
<p>
* The table below gives the full standard 7-bit ASCII character set and the
values of each character in decimal (D), hexadecimal (H), and octal (0),
along with the corresponding HPIB address or command byte (if one exists).
</p>
<p>
Note that LAD0-LAD30 is abbreviated to L0-L30, and TAD0-TAD30 is abbreviated
to T0-T30.  The secondary command bytes (secondary addresses and the PPE /
PPD commands) are listed in the right-hand column as SC0-SC31.
</p>
<pre><strong>
  __________________________________________________________________________

  ASCII Table For HPIB                                                        
  __________________________________________________________________________

  ch ctl cmd   D  H  O ch cmd  D  H  O  ch cmd  D  H   O  ch cmd    D  H   O 
  ___________________  ________________ ________________  __________________ 

  NUL ^@      0  0  0  sp L0  32 20 40   @ T0  64 40 100   ' SC0   96 60 140 
  SOH ^A GTL  1  1  1   ! L1  33 21 41   A T1  65 41 101   a SC1   97 61 141 
  STX ^B      2  2  2   &quot; L2  34 22 42   B T2  66 42 102   b SC2   98 62 142 
  ETX ^C      3  3  3   # L3  35 23 43   C T3  67 43 103   c SC3   99 63 143 
  EOT ^D SDC  4  4  4   $ L4  36 24 44   D T4  68 44 104   d SC4  100 64 144 
  ENQ ^E PPC  5  5  5   % L5  37 25 45   E T5  69 45 105   e SC5  101 65 145 
  ACK ^F      6  6  6   &amp; L6  38 26 46   F T6  70 46 106   f SC6  102 66 146 
  BEL ^G      7  7  7   ` L7  39 27 47   G T7  71 47 107   g SC7  103 67 147 
  ___________________  _______________  ________________  __________________ 

  BS  ^H GET  8  8 10   ( L8  40 28 50   H T8  72 48 110   h SC8  104 68 150 
  HT  ^I TCT  9  9 11   ) L9  41 29 51   I T9  73 49 111   i SC9  105 69 151 
  LF  ^J     10  a 12   * L10 42 2a 52   J T10 74 4a 112   j SC10 106 6a 152 
  VT  ^K     11  b 13   + L11 43 2b 53   K T11 75 4b 113   k SC11 107 6b 153 
  FF  ^L     12  c 14   , L12 44 2c 54   L T12 76 4c 114   l SC12 108 6c 154 
  CR  ^M     13  d 15   - L13 45 2d 55   M T13 77 4d 115   m SC13 109 6d 155 
  SO  ^N     14  e 16   . L14 46 2e 56   N T14 78 4e 116   n SC14 110 6e 156 
  SI  ^O     15  f 17   / L15 47 2f 57   O T15 79 4f 117   o SC15 111 6f 157 
  ___________________  _______________  ________________  __________________ 

  DLE ^P     16 10 20   0 L16 48 30 60   P T16 80 50 120   p SC16 112 70 160 
  DC1 ^Q LLO 17 11 21   1 L17 49 31 61   Q T17 81 51 121   q SC17 113 71 161 
  DC2 ^R     18 12 22   2 L18 50 32 62   R T18 82 52 122   r SC18 114 72 162 
  DC3 ^S     19 13 23   3 L19 51 33 63   S T19 83 53 123   s SC19 115 73 163 
  DC4 ^T DCL 20 14 24   4 L20 52 34 64   T T20 84 54 124   t SC20 116 74 164 
  NAK ^U PPU 21 15 25   5 L21 53 35 65   U T21 85 55 125   u SC21 117 75 165 
  SYN ^V     22 16 26   6 L22 54 36 66   V T22 86 56 126   v SC22 118 76 166 
  ETB ^W     23 17 27   7 L23 55 37 67   W T23 87 57 127   w SC23 119 77 167 
  ___________________  _______________  ________________  __________________ 

  CAN ^X SPE 24 18 30   8 L24 56 38 70   X T24 88 58 130   x SC24 120 78 170 
  EM  ^Y SPD 25 19 31   9 L25 57 39 71   Y T25 89 59 131   y SC25 121 79 171 
  SUB ^Z     26 1a 32   : L26 58 3a 72   Z T26 90 5a 132   z SC26 122 7a 172 
  ESC ^[     27 1b 33   ; L27 59 3b 73   [ T27 91 5b 133   { SC27 123 7b 173 
  FS  ^\     28 1c 34   &lt; L28 60 3c 74   \ T28 92 5c 134     SC28 124 7c 174 
  GS  ^]     29 1d 35   = L29 61 3d 75   ] T29 93 5d 135   } SC29 125 7d 175 
  RS   ^^    30 1e 36   &gt; L30 62 3e 76   ^ T30 94 5e 136   ~ SC30 126 7e 176 
  US   ^_    31 1f 37   ? UNL 63 3f 77   _ UNT 95 5f 137 DEL SC31 127 7f 177 
  __________________________________________________________________________ 

  GTL   Go To Local.               PPU        Parallel Poll Unconfigure.      
  SDC   Selected Device Clear.     SPE        Serial Poll Enable.             
  PPC   Parallel Poll Configure.   SPD        Serial Poll Disable.            
  GET   Group Execute Trigger.     L0-L30     Listen addresses (32+ADDR).     
  TCT   Take Control.              UNL        Unlisten (= L31).               
  GTL   Go To Local.               T0-T30     Talk addresses (64+ADDR).       
  LLO   Local Lockout.             UNT        Untalk (= T31).                 
  DCL   Device Clear.              SC0-SC31   Secondary commands (96+ADDR).   
  __________________________________________________________________________ 
 </strong></pre>
<hr />
<h1><a name="ib3_m0">[3.0] HPIB Tutor (3):   IEEE 488.2 -- Overview &amp; Data Formats</a></h1>
<p>
* This chapter and the next discusses the IEEE 488.2 specification.
</p>
<hr />
<ul>
<li>
<a href="#ib3_m1">[3.1] OVERVIEW</a>
</li>
<li>
<a href="#ib3_m2">[3.2] DATA CODING &amp; FORMATS</a>
</li>
<li>
[<a href="#ib3_m3">3.3] SYNTAX</a>
</li>
</ul>
<hr />
<p>
<a href="#top">BACK TO INDEX</a>
</p>
<h2><a name="ib3_m1">[3.1] OVERVIEW</a></h2>
<p>
* The 488.1 spec addressed the fundamental problems of interconnecting
digital devices, defining the mechanical and electrical requirements and the
basic communications protocols.
</p>
<p>
Clearly that wasn't enough.  Even though HPIB devices could be connected in a
mechanical, electrical, and logical fashion, that didn't guarantee that they
could communicate.  Devices from different vendors had wildly differing HPIB
capability sets, and used incompatible data formats, serial-poll status
formats, and entirely different command formats.
</p>
<p>
IEEE 488.2-1987 was defined to address these problems.  488.2 provides:
</p>
<ul>
<li> A minimum required set of interface capabilities.
</li>
<li> Data formats.
</li>
<li> Device message protocols.
</li>
<li> A core common command set.
</li>
<li> A well-defined status-reporting model.
</li>
 </ul>
<p>
This chapter discusses the details of data formats and protocols.  The
following chapter discusses the common command set and status reporting.
</p>
<p>
* The minimum required set of interface capabilities defined by 488.2 is
given below:
</p>
<ul>
<li> Source Handshake / SH1 / Full capability.
</li>
<li> Acceptor Handshake / AH1 / Full capability.
</li>
<li> Talker / T(TE)5 or T(TE)6 / Basic Talker, serial poll, unTalk on MLA.
</li>
<li> Listener / L(LE)3 or L(LE)4 / Basic Listener, unListen on MTA.
</li>
<li> Service Request / SR1 / Full capability.
</li>
<li> Device Clear / DC1 / Full capability.
</li>
<li> Remote Local / RL0 or RL1 / None or full capability.
</li>
<li> Parallel Poll / PP0 or PP1 / None or full capability.
</li>
<li> Device Trigger / DT0 or DT1 / None or full capability.
</li>
<li> Controller / (C0 or C4) and (C5 or C7 or C8 or C11) / None or respond to
    SRQ, send interface messages, pass &amp; receive control.
</li>
<li> Electrical Interface / E1 or E2 / Open collector or tristate.
</li>
 </ul>
<p>
This minimum capability set states that <em>all</em> HPIB devices must be able to
send and receive data, request service, and respond to a device clear
command.  It also details the minimum capabilities that a device must have
when it implements controller, parallel poll, and remote-local functions.
</p>
<p>
* 488.2 defines a set of data formats.  For example, it defines a format for
binary, octal, and hexadecimal numbers, as well as formats to send long
blocks of 8-bit bytes or strings of ASCII characters.  The table below lists
the supported formats:
</p>
<ul>
<li> Listener Formats
	<ul>
	<li> &lt;Decimal Numeric Program Data&gt; / REQUIRED
	</li>
	<li> &lt;Character Program Data&gt; / optional
	</li>
	<li> &lt;Suffix Program Data&gt; / optional
	</li>
	<li> &lt;Non-Decimal Numeric Program Data&gt; / optional
	</li>
	<li> &lt;String Program Data&gt; / optional
	</li>
	<li> &lt;Arbitrary Block Program Data&gt; / optional
	</li>
	<li> &lt;Expression Program Data&gt; / optional  
	</li>
	</ul>
</li>
<li> Talker Formats:
	<ul>
	<li> &lt;NR1 Numeric Response Data&gt; / REQUIRED
	</li>
	<li> &lt;Arbitrary ASCII Response Data&gt; / REQUIRED
	</li>
	<li> &lt;Character Response Data&gt; / optional
	</li>
	<li> &lt;NR2 Numeric Response Data&gt; / optional
	</li>
	<li> &lt;NR3 Numeric Response Data&gt; / optional
	</li>
	<li> &lt;Hexadecimal Numeric Response Data&gt; / optional
	</li>
	<li> &lt;Octal Numeric Response Data&gt; / optional
	</li>
	<li> &lt;Binary Numeric Response Data&gt; / optional
	</li>
	<li> &lt;String Response Data&gt; / optional
	</li>
	<li> &lt;Definite Length Arbitrary Block Response Data&gt; / optional
	</li>
	<li> &lt;Indefinite Length Arbitrary Block Response Data&gt; / optional
	</li>
	<li> &lt;Expression Response Data&gt; / optional  
	</li>
	</ul>
</li>
</ul>
<p>
488.2 introduced a new concept that makes it possible for older devices to
communicate with devices that use this new standard:  &quot;forgiving listening --
precise talking.&quot;
</p>
<p>
Forgiving listening means that a 488.2 device can accept a wide range of data
formats.  Precise talking means that a 488.2 device will transmit data in a
rigorous set of formats.
</p>
<p>
* Device message protocols allow devices to communicate by defining how to
send device commands, parameters, and data.  488.2 &quot;syntax&quot; defines what to
do when a device receives multiple commands, an incomplete command, or is
interrupted while processing a command.
</p>
<p>
488.2 also defines the protocols by which devices exchange data.  For
example, it describes the order in which data is sent; requires that a device
cannot send data until commanded to do so; and specifies that when a device
receives a new command it will flush its output queue, and respond to that
command.
</p>
<h2><a name="ib3_m2">[3.2] DATA CODING &amp; FORMATS</a></h2>
<p>
* 488.2 specifies three sets of codes for operation with HPIB devices:
</p>
<ul>
<li> US ASCII 7-bit (ANSI X3.4-1977) for alphanumerics.
</li>
<li> Binary 8-bit integer.
</li>
<li> Binary floating-point codes (IEEE 32- and 64-bit floating-point codes).
</li>
 </ul>
<p>
Using these codes, 488.2 defines data formats for decimal, octal, and
hexadecimal integers, decimal floating point numbers, strings, character
strings, and arbitrary strings.  Most of these formats use ASCII characters
to represent the data.
</p>
<p>
In sending ASCII and 8-bit binary, the order of the bits in the byte sent
over the HPIB matches the numbering of the DIO lines.  That is, bit 1 of an
ASCII character matches DIO line 1.  When sending streams of bytes, the
most-significant byte in the stream is sent first.
</p>
<p>
The data formats are concisely described in 488.2 using &quot;railroad track&quot;
diagrams, which provide a flowchart of the approved order of the elements of
the data format.  The detail provided by these diagrams is not necessary for
this discussion, so we will base our descriptions on a simple description and
some examples.
</p>
<p>
The device listening formats are described below.  They are known as &quot;program
formats&quot; since they are used to configure the instrument, though the formats
do not necessarily define device programming commands as such.
</p>
<p>
* The &lt;Decimal Numeric Program Data&gt; format is also known as &lt;NRf&gt; for
&quot;flexible Numeric Representation&quot;.  This is basically an ASCII decimal
numeric string floating-point format.  Legal numbers in this scheme include:
</p>
<pre><strong>
      .123        
     0.123
   123.        
    12.3
   +12.3
   -12.3       
   +12.3e10    
   -12.3E10
    12.3E+10    
    12.3E-10    
    12.3 E-10   
    12.3 e - 10
 </strong></pre>
<p>
The mantissa cannot have more than 255 characters, and the exponent must be
in the range of -32,000 to 32,000.
</p>
<p>
If a device receives an &lt;NRf&gt; of greater precision than it can handle, it
rounds off the number.  Rounding ignores the sign of the number; values less
than 1/2 round down, and values greater than or equal to 1/2 round up.  For
example, suppose we have an instrument that can only handle two digits;
rounding is performed as follows:
</p>
<pre><strong>
    1.3499 --&gt;  1.3    
    1.35   --&gt;  1.4      
   -2.456  --&gt; -2.5   
   -2.447  --&gt; -2.4
 </strong></pre>
<p>
A suffix, used to define the units and (optionally) the multipliers of the
data, may also be used with &lt;NRf&gt; data.  The defined unit suffixes are as
follows:
</p>
<pre><strong>
   _________________________________________________________________________

   Class                Preferred Suffix           Allowed Suffix
   _________________________________________________________________________

   Ratio                DB     Decibel                   
                        PCT    Percent                   
                                                   PPM    Parts Per Million

   Angle                RAD    Radian                    
                        SR     Steradian                 
                                                   DEG    Degree
                                                   GON    Grade
                                                   MNT    Minute of arc
                                                   SEC    Second
                                                   REV    Revolution

   Time                 S      Second                    
                                                   D      Day
                                                   HR     Hour
                                                   MIN    Minute
                                                   ANN    Year

   Frequency            HZ     Hertz                     
                                                   MHZ    Megahertz

   Temperature          CEL    Degree Celsius            
                        K      Degree Kelvin             
                                                   FAR    Degree Fahrenheit

   Length               M      Meter                     
                                                   FT     Feet
                                                   IN     Inch
                                                   MI     Mile
                                                   NAMI   Nautical Mile
                                                   ASU    Astronomical Unit
                                                   PRS    Parsec

   Volume               L      Liter                     
   Mass                                            G      Gram
                                                   TNE    Tonne

   Atomic Mass          U      Atomic Mass Unit          
   Energy               J      Joule                     
                                                   EV     Electronvolt

   Power                W      Watt                      
                        DBM    DB On 1 Milliwatt         

   Force                N      Newton                    
   Pressure             ATM    Atmosphere                
                        INHG   Inches of Mercury         
                        PAL    Pascal                    
                        TORR   Torr                      

   Fluid Pressure       BAR    Bar                       
   Chemical Measure     MOL    Mole                      
   Viscosity            ST     Stokes                    
                        P      Poise                     

   Charge               C      Coulomb                   
   Current              A      Ampere                    
   Potential            V      Volt                      
   Resistance           OHM    Ohm                       
                                                   MOHM   Megohm

   Conductance          SIE    Siemens                   
   Capacitance          F      Farad                     
   Inductance           H      Henry                     
   Luminous Intensity   CD     Candela                   
   Illuminance          LX     Lux                       
   Luminous Flux        LM     Lumen                     
   Magnetic Induction   T      Tesla                     
   Magnetic Flux        WB     Weber                     
   Radioactivity        BQ     Becquerel                 
   Absorbed Dose        GY     Gray                      
   Dose Equivalent      SV     Sievert                   
   _________________________________________________________________________
 </strong></pre>
<p>
   The defined multipliers are as follows:
</p>
<pre><strong>
   ___________________________

   exponent   mnemonic   name
   ___________________________

   1E18       EX         EXA
   1E15       PE         PETA
   1E12       T          TERA
   1E9        G          GIGA
   1E6        MA         MEGA
   1E3        K          KILO
   1E-3       M          MILLI
   1E-6       U          MICRO
   1E-9       N          NANO
   1E-12      P          PICO
   1E-15      F          FEMTO
   1E-18      A          ATTO
   ___________________________
 </strong></pre>
<p>
In the latest incarnation of 488.2, &lt;Suffix Program Data&gt; may also be used on
its own, without use of a preceding &lt;NRf&gt; element.
</p>
<p>
* The &lt;Non-Decimal Numeric Program Data&gt; format is a numeric string
representation of hexadecimal, octal, and binary numbers:
</p>
<pre><strong>
   #HA2F      a hexadecimal A2F
   #ha3e      a hexadecimal a3e
   #hA3f      a hexadecimal A3f
   #Q73       an octal 73
   #q54       an octal 54
   #B01101    a binary 01101
   #b10010    a binary 10010
 </strong></pre>
<p>
* The &lt;String Program Data&gt; format is for sending ASCII strings (using 7-bit
USASCII characters):
</p>
<pre><strong>
   'this is a legal string'
   &quot;this is also a legal string&quot;
   &quot;this string contains an embedded ' that is not a delimiter&quot;
   'this string contains an embedded &quot; that is not a delimiter'
   &quot;this string contains an embedded &quot;&quot; that is not a delimiter&quot;
 </strong></pre>
<p>
Note that the two last examples do exactly the same thing, but in different
ways.
</p>
<p>
* The &lt;Arbitrary Block Program Data&gt; spec provides a scheme for sending
binary or 8-bit ASCII) data.  There are two formats:  a definite-length
format and an indefinite-length format.
</p>
<p>
Both formats start with a &quot;#&quot; character to distinguish them from other
device-listening formats.  In the definite-length format, the &quot;#&quot; character
is followed by:
</p>
<ul>
<li> A single ASCII digit that gives the number of ASCII digits in the field
   following it.
</li>
<li> A string of ASCII digits (where the field length was defined as above)
   that gives the number of data bytes to follow the field.
</li>
<li> A stream of data bytes of a length given by the field above.
</li>
 </ul>
<p>
This format may be a little easier to understand with some examples (note
that &lt;DAB&gt; stands for some arbitrary data byte):
</p>
<pre><strong>
    #15&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;
    #213&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;
 </strong></pre>
<p>
In the first example, the length field is 1 digit long and specifies 5
following data bytes.  In the second example, the length field is 2 digits
long and specifies 13 following data bytes.
</p>
<p>
In the indefinite-length format, the length field evaluates to 0 and is
followed by a stream of data bytes that is terminated by a newline
(line-feed) character, along with assertion of the EOI line.  (It is necessary
to use EOI because arbitrary data bytes will often evaluate to a line-feed
character, a revelation that novice I/O programmers usually find out about
the hard way.)  For example:
</p>
<pre><strong>
   #0&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;NL&amp;EOI
 </strong></pre>
<p>
* The &lt;Expression Program Data&gt; format evaluates to a scalar, vector, matrix,
or string value.  It is very general-purpose and consists solely of a
string of ASCII characters in the range of codes 32 to 126, with the
exception of 5 characters: <em>very</em> 
</p>
<pre><strong>
   [ &quot; ]     [ # ]     [ ' ]     [ , ]     [ ; ]
 </strong></pre>
<p>
-- with the entire string enclosed in parentheses.  This format basically
evaluates to ANY sequence of characters enclosed in parenthesis.  It can be
considered an &quot;escape&quot; format that allows for command formats not allowed by
the rest of the 488.1 spec.
</p>
<p>
The device listening formats discussed above are very broad and forgiving.
The device talking formats are much more precise.
</p>
<p>
* The &lt;NR1 Numeric Response Data -- Integers&gt; format defines integer decimal
numbers with no decimal point or fractional part.  For example:
</p>
<pre><strong>
      123
     +123
   -12345
 </strong></pre>
<p>
* The &lt;NR2 Numeric Response Data -- Fixed Point&gt; format defines decimal
numbers with a fractional part but no exponent.  For example:
</p>
<pre><strong>
   12.3
   +1.234
   -0.12345
 </strong></pre>
<p>
* The &lt;NR3 Numeric Response Data -- Floating Point&gt; format defines decimal
numbers with a fractional part and an exponent.  For example:
</p>
<pre><strong>
        1.23E+5
      123.4E-56
   -12345.678E+90
 </strong></pre>
<p>
* The &lt;Hexadecimal Numeric Response Data&gt; format is exactly the same as the
listening format for hex numbers, except that lowercase letters are not
allowed.  For example:
</p>
<pre><strong>
   #HAD0E
   #H01F2
   #HF3B
 </strong></pre>
<p>
* The &lt;Octal Numeric Response Data&gt; format is exactly the same as the
listening format for octal numbers, except that lowercase letters are not
allowed.  For example:
</p>
<pre><strong>
   #Q7035
   #Q30572
   #Q765432
 </strong></pre>
<p>
* The &lt;Binary Numeric Response Data&gt; format is exactly the same as the
listening format for binary numbers, except that lowercase letters are not
allowed.  For example:
</p>
<pre><strong>
   #B01101
   #B10101010
   #B1011
 </strong></pre>
<p>
* The &lt;Character Response Data&gt; format defines the means by which mnemonic
strings are sent between devices.  These strings contain only ASCII numeric
digits, upper-case ASCII alphabetic characters, and the &quot;_&quot; character.  They
must start with an upper-case ASCII alphabetic character, and cannot be more
than 12 characters long.  For example:
</p>
<pre><strong>
   START
   R2_D2
 </strong></pre>
<p>
* The &lt;String Response Data&gt; format defines how a device sends an arbitrary
text string.  It is the same as the listening format, except that
double-quotes are legal characters but single-quotes are not.  For example:
</p>
<pre><strong>
   &quot;You say hello&quot;
   &quot;I say &quot;&quot;Goodbye&quot;&quot;.&quot;
 </strong></pre>
<p>
* The &lt;Definite Length Arbitrary Block Response Data&gt; format is for sending
binary data of a specified length.  It is exactly the same as the listening
format:
</p>
<pre><strong>
   #3128&lt;DAB1&gt;&lt;DAB2&gt;&lt;DAB3&gt; ... &lt;DAB128&gt;
 </strong></pre>
<p>
* The &lt;Indefinite Length Arbitrary Block Response Data&gt; format is for sending
binary data of an unspecified length.  It is exactly the same as the listening
format:
</p>
<pre><strong>
   #0&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;&lt;DAB&gt;NL&amp;EOI
 </strong></pre>
<p>
* The &lt;Arbitrary ASCII Response Data&gt; format allows a device to respond with
undelimited ASCII text.  It consists of a stream of ASCII bytes terminated by
a newline-with-EOI.  This is a very general (and somewhat ill-defined)
format -- note that it allows for responses that could easily be confused for
other response types -- and its use is discouraged. <em>very</em> 
</p>
<p>
* The &lt;Expression Response Data&gt; format is the response counterpart to the
&lt;Expression Program Data&gt; type.  It is also general-purpose and consists
solely of a string of ASCII characters in the range of codes 32 to 126, with
the exception of 5 characters:
</p>
<pre><strong>
   [ &quot; ]     [ # ]     [ ' ]     [ , ]     [ ; ]
 </strong></pre>
<p>
-- with the entire string enclosed in parentheses.  Like the response data
format, this format is used to cover any format not otherwise covered in the
488.2 spec.
</p>
<h2><a name="ib3_m3">[3.3] SYNTAX</a></h2>
<p>
* In the previous section we discussed the data formats defined by 488.2 --
the &quot;words&quot; of the &quot;language&quot;, so to speak.  In this section we move up from
simple &quot;words&quot; to the syntax that provides a framework for those &quot;words&quot;.
</p>
<p>
As with the data formats, the syntax that a device will recognize is much
less precise than the syntax that it will generate -- &quot;forgiving listening,
precise talking&quot; again.
</p>
<p>
* The elements of listening syntax fall into the following categories:
</p>
<ul>
<li> Terminators
</li>
<li> Separators
</li>
<li> Commands
</li>
<li> Queries
</li>
 </ul>
<p>
There is only one form of terminator.  The &lt;Program Message Terminator&gt;
defines how to terminate a message to a listening device.  There are three
possible terminators:
</p>
<ul>
<li> A newline.
</li>
<li> A newline with EOI.
</li>
<li> An EOI.
</li>
 </ul>
<p>
A terminator is also sometimes informally referred to as an &quot;arnold&quot;, but
this usage is clearly outside of the 488.2 spec.
</p>
<p>
* Separators fall into three categories.  The &lt;Program Message Separator&gt; is
just a &quot;;&quot; (semicolon), and is placed between commands in a single message to
create a complex command.
</p>
<p>
The &lt;Program Header Separator&gt; is just blank (&quot;white&quot;) space, and is used to
separate commands and their parameters.  This is the only case where white
space is significant in 488.2.  In other listening formats it is ignored, and
in talking formats is not usually generated.
</p>
<p>
The &lt;Program Data Separator&gt; is just a &quot;,&quot; (comma), and is used to separate
data in a data stream.
</p>
<p>
* Commands, or more properly &lt;Command Program Headers&gt;, also fall into three
categories, though in this case the categories are less distinct.
</p>
<p>
The &lt;Simple Program Header&gt; is just a command string, or &lt;Program Mnemonic&gt;.
Legal command strings consist of lowercase and uppercase letters, plus the
&quot;_&quot; (underscore) character.  For example:
</p>
<pre><strong>
   MEASURE
 </strong></pre>
<p>
The &lt;Compound Command Program Header&gt; is a set of &lt;Program Mnemonic&gt; strings,
separated by &quot;:&quot; (colon) characters.  A &quot;:&quot; may be added in front as well.
For example:
</p>
<pre><strong>
   MEASURE:VOLTAGE
   :MEASURE:VOLTAGE
 </strong></pre>
<p>
The &lt;Common Command Program Header&gt; is the format for the common commands
defined by 488.2.  Their distinguishing feature is that they are preceded by
a &quot;*&quot; (asterisk).  For example:
</p>
<pre><strong>
   *IDN
   *RST
   *SRE
 </strong></pre>
<p>
* There are three queries, or more properly &lt;Query Program Headers&gt;.  The
queries are used to interrogate a device for information.  The three queries
are complementary to the three commands, and include:
</p>
<ul>
<li> &lt;Simple Query Program Header&gt;
</li>
<li> &lt;Compound Query Program Header&gt;
</li>
<li> &lt;Common Query Program Header&gt;
</li>
 </ul>
<p>
The three have the same syntax as the complementary commands, except that a
&quot;?&quot;  is tacked on to the end.
</p>
<p>
* The talking syntax is similar to the listening syntax, but much more
concise.  The talking syntax applies to two types of data that a device may
return in response to a query:
</p>
<ul>
<li> Response Data:  This is data returned by the instrument in response to a
   query.  Since a &lt;Compound Query Program Header&gt; may ask for multiple
   responses, a single response data stream may contain the responses to
   multiple queries.
</li>
<li> Learn String:  This is the data returned in response to a query that
   interrogates a device for a setting.  This data includes not only the
   value of the setting but the command header that tells the device to make
   that setting.  This learn string can be sent later, verbatim, to restore
   the setting.
</li>
 </ul>
<p>
There are only four elements to the talking syntax:
</p>
<ul>
<li> &lt;Response Message Terminator&gt;:  The only legal terminator for the talking
   syntax is a newline along with an EOI.  This is used at the end of a
   stream of response data.
</li>
<li> &lt;Response Message Unit Separator&gt;:  This separator is defined as a &quot;;&quot;
   (semicolon), and is used to separate different responses in the response
   stream.
</li>
<li> &lt;Response Data Data Separator&gt;:  This separator is defined as a &quot;,&quot;
   (comma), and is used to separate data items in a response.
</li>
<li> &lt;Response Header Separator&gt;:  This separator is defined as a &quot; &quot; (space),
   and is used to separate the response header from the response data.
</li>
 </ul>
<hr />
<h1><a name="ib4_m0">[4.0] HPIB Tutor (4):   488.2 Common Commands &amp; Status</a></h1>
<p>
* The 488.2 spec also includes a &quot;common command&quot; set that provides a minimal
subset of instrument commands, as well as a consistent way of returning
status information.  This chapter describes these issues in detail.
</p>
<hr />
<ul>
<li>
<a href="#ib4_m1">[4.1] 488.2 COMMON COMMANDS &amp; STATUS OVERVIEW</a>
</li>
<li>
<a href="#ib4_m2">[4.2] ESSENTIAL COMMON COMMANDS</a>
</li>
<li>
<a href="#ib4_m3">[4.3] STATUS REPORTING</a>
</li>
<li>
<a href="#ib4_m4">[4.4] SECONDARY COMMON COMMANDS</a>
</li>
</ul>
<hr />

<p>
<a href="#top">BACK TO INDEX</a>
</p>
<h2><a name="ib4_m1">[4.1] 488.2 COMMON COMMANDS &amp; STATUS OVERVIEW</a></h2>
<p>
* The common commands defined under 488.2 are not bus commands, but strings
sent as data with ATN off.  (These common commands include both commands and
queries, but for convenience they are collectively referred to as commands.)
The complete common command set is as follows:
</p>
<ul>
<li> AUTO CONFIGURE COMMANDS:  Set device addresses via software.
	<ul>
	<li> *AAD / Assign Address / optional
	</li>
	<li> *DLF / Disable Listener Function / optional  
	</li>
	</ul>
</li>
<li> SYSTEM DATA COMMANDS:  Store or retrieve information about HPIB devices,
   such as device descriptions and options.
	<ul>
	<li> *IDN? / Identification Query / REQUIRED
	</li>
	<li> *OPT? / Option Identification Query / optional
	</li>
	<li> *PUD / Protected User Data / optional
	</li>
	<li> *PUD? / Protected User Data Query / optional
	</li>
	<li> *RDT / Resource Description Transfer / optional
	</li>
	<li> *RDT? / Resource Description Transfer Query / optional  
	</li>
	</ul>
</li>
<li> INTERNAL OPERATION COMMANDS:  Control or read the internal operation of a
   device through resets, self-tests, or self-calibration.
	<ul>
	<li> *CAL? / Calibration Query / optional
	</li>
	<li> *LRN? / Learn Device Setup Query / optional
	</li>
	<li> *RST / Reset / REQUIRED
	</li>
	<li> *TST? / Self-Test Query / REQUIRED  
	</li>
	</ul>
</li>
<li> SYNCHRONIZATION COMMANDS:  Control device synchronization within an HPIB
   system.
	<ul>
	<li> *OPC / Operation Complete / REQUIRED
	</li>
	<li> *OPC? / Operation Complete Query / REQUIRED
	</li>
	<li> *WAI / Wait to Continue / REQUIRED  
	</li>
	</ul>
</li>
<li> MACRO COMMANDS:  Allow the user to define new commands as &quot;macros&quot; of
   other commands.
	<ul>
	<li> *DMC / Define Macro / optional
	</li>
	<li> *EMC / Enable Macro / optional
	</li>
	<li> *EMC? / Enable Macro Query / optional
	</li>
	<li> *GMC? / Get Macro Contents Query / optional
	</li>
	<li> *LMC? / Learn Macro Query / optional
	</li>
	<li> *PMC / Purge Macros / optional
	</li>
	<li> *RMC / Remove Individual Macro / optional  
	</li>
	</ul>
</li>
<li> PARALLEL POLL COMMANDS:  Control how a device responds to a parallel poll,
   and allow access to the same information without performing a parallel
   poll.
	<ul>
	<li> *IST? / Individual Status Query / required if PP1
	</li>
	<li> *PRE / Parallel Poll Enable Register Enable / required if PP1
	</li>
	<li> *PRE? / Parallel Poll Enable Register Enable Query / required if PP1  
	</li>
	</ul>
</li>
<li> STATUS &amp; EVENT COMMANDS:  Control device status reporting.
	<ul>
	<li> *CLS / Clear Status / REQUIRED
	</li>
	<li> *ESE / Event Status Enable / REQUIRED
	</li>
	<li> *ESE? / Event Status Enable Query / REQUIRED
	</li>
	<li> *ESR? / Event Status Register Query / REQUIRED
	</li>
	<li> *PSC / Power On Status Clear / optional
	</li>
	<li> *PSC? / Power On Status Clear Query / optional
	</li>
	<li> *SRE / Service Request Enable / REQUIRED
	</li>
	<li> *SRE? / Service Request Enable Query / REQUIRED
	</li>
	<li> *STB? / Read Status Byte Query / REQUIRED  
	</li>
	</ul>
</li>
<li> DEVICE TRIGGER COMMANDS:  Perform a Device Trigger and control how a
   device responds to a trigger command.
	<ul>
	<li> *DDT / Define Device Trigger / optional if DT1
	</li>
	<li> *DDT? / Define Device Trigger Query / optional if DT1
	</li>
	<li> *TRG / Trigger / required if DT1  
	</li>
	</ul>
</li>
<li> CONTROLLER COMMANDS: Defines the means of passing control between devices.
	<ul>
	<li> *PCB / Pass Control Back / required if ctl  
	</li>
	</ul>
</li>
<li> STORED SETTING COMMANDS:  Save and restore the state of the device.
	<ul>
	<li> *RCL / Recall Instrument State / optional
	</li>
	<li> *SAV / Save Instrument State / optional
	</li>
	<li> *SDS / Save Default Device Settings / optional  
	</li>
	</ul>
</li>
 </ul>
<p>
The spec defines some of these commands as required, and some as optional.
In practice the required commands are always implemented on any respectable
modern instrument, while most of the optional commands are implemented only
on certain classes of instruments or never at all.
</p>
<p>
* 488.2 provides a major enhancement of the definition of the serial poll
status byte defined in 488.1 spec.  The original definition only defined bit
6 as the &quot;request service&quot; flag; 488.2 also defines two more bits, the Event
Status Bit (ESB) and Message Available (MAV), plus an additional status
register and provisions for others.  (488.2 also includes an expansion of the
definition of parallel poll provided in 488.1.)
</p>
<p>
* The 488.2 common command set makes programming a device somewhat simpler as
it predefines certain elementary commands common to many devices.  However,
it does not address the command syntax relevant to the specific functions of
the devices.  That domain is covered by the SCPI standard, the subject of the
following chapter.
</p>
<h2><a name="ib4_m2">[4.2] ESSENTIAL COMMON COMMANDS</a></h2>
<p>
* In practice, the most important common commands are those outlined below:
</p>
<ul>
<li> SYSTEM DATA COMMANDS
	<ul>
	<li> *IDN? / Identification Query / REQUIRED  
	</li>
	</ul>
</li>
<li> INTERNAL OPERATION COMMANDS
	<ul>
	<li> *LRN? / Learn Device Setup Query / optional
	</li>
	<li> *RST / Reset / REQUIRED
	</li>
	<li> *TST? / Self-Test Query / REQUIRED  
	</li>
	</ul>
</li>
<li> SYNCHRONIZATION COMMANDS
	<ul>
	<li> *OPC / Operation Complete / REQUIRED
	</li>
	<li> *OPC? / Operation Complete Query / REQUIRED
	</li>
	<li> *WAI / Wait to Continue / REQUIRED
	</li>
	</ul>
</li>
<li> STATUS &amp; EVENT COMMANDS
	<ul>
	<li> *CLS / Clear Status / REQUIRED
	</li>
	<li> *ESE / Event Status Enable / REQUIRED
	</li>
	<li> *ESE? / Event Status Enable Query / REQUIRED
	</li>
	<li> *ESR? / Event Status Register Query / REQUIRED
	</li>
	<li> *PSC / Power On Status Clear / optional
	</li>
	<li> *PSC? / Power On Status Clear Query / optional
	</li>
	<li> *SRE / Service Request Enable / REQUIRED
	</li>
	<li> *SRE? / Service Request Enable Query / REQUIRED
	</li>
	<li> *STB? / Read Status Byte Query / REQUIRED  
	</li>
	</ul>
</li>
<li> DEVICE TRIGGER COMMANDS
	<ul>
	<li> *TRG / Trigger / required if DT1  
	</li>
	</ul>
</li>
 </ul>
<p>
* The *IDN? (Identification) query causes a device to return a string to
identify itself; this string has the format:
</p>
<pre><strong>
   &lt;manufacturer&gt;,&lt;model&gt;,&lt;serial_number&gt;,&lt;firmware_rev_level&gt;
 </strong></pre>
<p>
Note that the serial number and firmware revision level are returned as &quot;0&quot;
if not available.  For example, a device might return a string of the form:
</p>
<pre><strong>
   HEWLETT-PACKARD,347A,222101113,A1
 </strong></pre>
<p>
* While the *LRN?  (Learn Device Setup) query is optional, many devices
implement it; it tells the device to return a &quot;learn string&quot; to the
controller that contains the commands necessary to put the device back into
its current state.  This string can either be in ASCII or binary format,
since the format isn't specified by 488.2.  Oddly, there is no *LRN command,
just a *LRN? query.
</p>
<p>
* The *RST (Reset) command resets the device.  It performs the following
actions:
</p>
<ul>
<li> Sets device functions to a known state.
</li>
<li> Sets the Device Defined Trigger (see *DDT command) to a known state.
</li>
<li> Disables macros (see the section on macro commands).
</li>
<li> Aborts all pending operations.
</li>
<li> Clears any received *OPC or *OPC? commands in progress.
</li>
 </ul>
<p>
The *RST command does not affect:
</p>
<ul>
<li> The state of the HPIB address or its address.
</li>
<li> The bytes in the output queue.
</li>
<li> The service request enable register.
</li>
<li> The standard event status register.
</li>
<li> The power-on flag.
</li>
<li> Macro definitions (though they are disabled), calibration data,
   protected user data, or the Resource Description Transfer Query Response.
</li>
 </ul>
<p>
Note that *RST is the highest of three levels of resets defined under 488.1
and 488.2.  These three levels are:
</p>
<ul>
<li> The 488.1 IFC line causes a level-1 reset.  It unaddresses all devices and
   returns control to the system controller.
</li>
<li> The 488.1 DCL and SDC (universal device clear and selected device clear)
   command bytes perform a level-2 reset.  They clear the device input and
   output buffers and allow it to receive new commands.
</li>
<li> The 488.2 *RST command performs a level-3 reset:  it actually clears the
   device itself as described above.
</li>
 </ul>
<p>
* The *TST? (Self-Test) query causes the device to perform an internal
selftest and report back the status of the test.  It is similar to the *CAL?
command and, like the *CAL?  command, returns &quot;0&quot; if successful, and an error
code in the range &quot;-32767&quot; to &quot;32767&quot; if not.
</p>
<p>
* The *OPC (Operation Complete) command tells the device to set bit 0 in the
Standard Event Status Register (described in the next section) when it
completes all pending operations.
</p>
<p>
The matching *OPC? query tells the device to place an ASCII &quot;1&quot; in the
device's output queue when it completes all pending operations.
</p>
<p>
* The *WAI (Wait to Continue) command makes the device wait until all
previous commands or queries complete, rather than execute a new command in
an overlapped fashion.  The device then continues executing commands that
follow the *WAI command.
</p>
<p>
* The *CLS (Clear Status) command clears the status register and associated
status data structures summarized in the Status Byte, such as the Event
Status Register (described in the next section).
</p>
<p>
* The *ESE (Standard Event Status Enable) command allows you to set the
contents of the Standard Event Status Enable Register.  It takes a decimal
numeric string in the range &quot;0&quot; to &quot;255&quot;, representing the bit pattern in the
register.  If a bit is set, the corresponding bit in the Standard Event
Status Register will be flagged into the Status Byte.
</p>
<p>
The *ESE? query interrogates the Standard Event Status Enable Register.  It
returns a decimal numeric string in the range &quot;0&quot; to &quot;255&quot;.
</p>
<p>
The *ESR? (Event Status Register) query reads the contents of the Standard
Event Status Register; the SESR is then cleared.  A decimal numeric string in
the range &quot;0&quot; to &quot;255&quot;, representing the bit pattern in the SESR, is
returned.  This is explained in more detail in the next section.
</p>
<p>
* The *PSC (Power-On Status Clear) command (which is optional, but often
implemented) controls the clearing of the Service Request Enable Register,
the Standard Event Status Enable Register, the Parallel Poll Enable Register,
and (in the latest flavor of 488.2) such device-specific registers as the
implementor may find useful to reset.
</p>
<p>
Sending a &quot;0&quot; with the &quot;*PSC&quot; command sets the power-on clear flag, causing
the three registers to be cleared at power-up.  Sending any other number in
the range &quot;-32767&quot; to &quot;32767&quot; clears the power-on clear flag, but leaves the
registers in their previous state.
</p>
<p>
The *PSC? query returns the status of the power-on clear flag.  It returns
&quot;1&quot; if the flag is set, and &quot;0&quot; if the flag is cleared.
</p>
<p>
* The *SRE (Service Request Enable) command sets the Service Request Enable
Register (discussed in next section).  It takes a decimal numeric string in
the range &quot;0&quot; to &quot;255&quot; as a parameter, with the string representing the bit
pattern to be stored in the register.  Any bit enabled will cause an SRQ when
the matching bit in the status byte is activated.
</p>
<p>
The *SRE? query returns the contents of the Service Request Enable Register.
The contents are returned as a decimal numeric string in the range &quot;0&quot; to
&quot;63&quot;, &quot;128&quot; to &quot;191&quot;.  (The gap in the range is due to the fact that bit 6,
the RQS bit, cannot be set and is always returned as &quot;0&quot;.)
</p>
<p>
The *STB? (Status Byte) query reads the device Status Byte, with bit 6
representing the Master Summary Status (MSS) bit instead of the RQS bit.  The
query returns a decimal numeric string in the range &quot;0&quot; to &quot;255&quot;.  This is
explained in more detail in the next section.
</p>
<p>
* The *TRG (Trigger) command performs the same function as the GET command
byte.
</p>
<h2><a name="ib4_m3">[4.3] STATUS REPORTING</a></h2>
<p>
* The 488.1 spec, as described in previous chapters, defined a status byte to
be returned by a device in response to a serial poll.  However, the only
thing that 488.1 defined in this byte was bit 6, which was set if the polled
device had asserted a service request.
</p>
<p>
488.2 expands on this status reporting scheme and allows the status to be
retrieved not only via through a serial poll, but also through the 488.2
*STB?  query.  488.2 also extends the definition of the status byte and
provides an additional, second-level status register, plus a mechanism for
determining whether or not a status flag can cause an SRQ.  The following
illustration diagrams the 488.2 status model (explanations follow):
</p>
<pre><strong>
                                             Status Byte
                                         +-----+   +-----+   
                                         | 0   +--&gt;| 0   +--&gt;-+
                                         |     |   |     |    |
                                         | 1   +--&gt;| 1   +--&gt;-+
                                         |     |   |     |    |
                                         | 2   +--&gt;| 2   +--&gt;-+
                                         |     |   |     |    |
                                         | 3   +--&gt;| 3   +--&gt;-+
                                         |     |   |     |    +-[OR]-+
                  from output queue ----&gt;| MAV +--&gt;| MAV +--&gt;-+      |
                                         |     |   |     |    |      |
  +-----+   +-----+           +---------&gt;| ESB +--&gt;| ESB +--&gt;-+      |
  | OPC |   | OPC +--&gt;-+      |          |     |   |     |    |      |
  |     |   |     |    |      |    +----&gt;| RQS +--&gt;| --- +--&gt;-+      |
  | RQC |   | RQC +--&gt;-+      |    |     |     |   |     |    |      |
  |     |   |     |    |      |    |     | 7   +--&gt;| 7   +--&gt;-+      |
  | QYE |   | QYE +--&gt;-+      |    |     +-----+   +-----+           |
  |     |   |     |    |      |    |      *STB      *SRE &lt;mask&gt;      |
  | DDE +--&gt;| DDE +--&gt;-+      |    |                *SRE?            |
  |     |   |     |    +-[OR]-+    +---------------------------------+
  | EXE +--&gt;| EXE +--&gt;-+
  |     |   |     |    |
  | CME +--&gt;| CME +--&gt;-+
  |     |   |     |    |
  | URQ +--&gt;| URQ +--&gt;-+
  |     |   |     |    |
  | PON +--&gt;| PON +--&gt;-+
  +-----+   +-----+
   *ESR?     *ESE &lt;mask&gt;
             *ESE?
 </strong></pre>
<p>
In 488.2 bits 4, 5, and 6 in the status byte are defined as follows:
</p>
<ul>
<li> Bit 4 is the message available bit, or MAV, which indicates whether or not
   the device's data output queue is empty.  Whenever the device has data
   available, this bit will be set.
</li>
<li> Bit 5 is the event-status bit, or ESB, which captures events generated
   from the Standard Event Status Register, which is defined below.
</li>
<li> Bit 6 is defined slightly differently depending on whether the status byte
   is read via a serial poll or through the *STB?  query.  In a serial poll,
   bit 6 is defined as the RQS (request service) bit, and tells the HPIB
   controller whether the device has requested service or not.  If it has
   requested service, the serial poll clears the bit.
<p>
   In a *STB? query, bit 6 is the master status summary (MSS) bit and
   indicates that the device has requested service, even if the device has
   been serial polled and the RQS bit has been cleared.  That is, MSS is
   &quot;sticky&quot; and RQS is not.
</p>
</li> 
 </ul>
<p>
The other bits, as before, are undefined.  However, the other bits are
intended to be used as status-summary bits for device-dependent event
registers.  (The SCPI spec defines these bits in more detail.)
</p>
<p>
The second status register defined by 488.2, the Standard Event Status
register (SRER), contains the following flags:
</p>
<ul>
<li> Bit 0 -- Operation Complete (OPC) -- indicates that the device has
   completed any pending operations and is ready to accept new commands.
   This bit is generated only in response to the Operation Complete (*OPC)
   command.
</li>
<li> Bit 1 -- Request Control (RQC) -- indicates that the device wants to
   become the active controller.
</li>
<li> Bit 2 -- Query Error (QYE) -- indicates an error occurred while the
   controller was trying to read the device's data output queue.  The cause
   will be either the queue was empty, or the queue overflowed.
</li>
<li> Bit 3 -- Device-Dependent Error (DDE) -- indicates some unspecified device
   error occurred.
</li>
<li> Bit 4 -- Execution Error (EXE) -- indicates that the device detected an
   error while trying to execute a command.  The cause will be either the
   device received a command that was inappropriate to the device, or the
   device could not execute a valid command due to some device condition.
</li>
<li> Bit 5 -- Command Error (CME) -- indicates that the device has detected a
   command error.  These errors include being sent commands that do not
   conform to 488.2 format or commands that are incorrectly spelled.
</li>
<li> Bit 6 -- User Request (URQ) -- indicates that the user has activated some
   device-dependent control to request service.
</li>
<li> Bit 7 -- Power On (PON) -- indicates that the device has been power-cycled
   since the last time it was queried.
</li>
 </ul>
<p>
As noted earlier, the ESB bit in the status bit register is set if any
standard events occur -- that is, if any enabled bit in the SESR is set.
</p>
<p>
The SESR can be read with the *ESR? query.  The corresponding standard event
status enable register can be set (to enable events on the SESR bits) with
the *ESE &lt;mask&gt; command, and read with the *ESE? query.
</p>
<p>
The SESR is cleared by a *CLS command, reading the SESR with *ESR?, or by a
power cycle (though in this last case the PON bit will be set after the SESR
is cleared).
</p>
<p>
The 488.2 spec allows other event registers to be implemented and summed into
the unused bits of the status byte, but does not define what these other
registers to be.  (The SCPI spec added these definitions with a vengeance!)
</p>
<p>
* The device data output queue has been mentioned several times in this
discussion; it stores output messages to be read from the device, and can be
read simply by addressing the device to talk and then handshaking the bytes.
The MAV bit will be set as long as there are bytes available.
</p>
<p>
The *CLS command does not clear the output queue.  It can only be cleared by
the *RST command, the 488.1 DCL (device clear) command byte, or by
power-cycling.  This reduces the chances of losing data.
</p>
<p>
* 488.2 enhances the parallel poll protocol defined in 488.1 by adding a
Parallel Poll Enable Register.  Again, as Parallel Poll is rarely used, this
will not be discussed further.
</p>
<p>
* The following example program -- which is for a 34401 DMM, but will work on
any 488.2-compatible instrument -- uses the common commands to conduct a
device verification.  Note how the results of the self-test are obtained by
programming the DMM to assert SRQ when done.
</p>
<pre><strong>
   10    DIM S$[50]                    ! Dimension a string.
   20    CLEAR SCREEN                  ! Clear display.
   30    ASSIGN @Dmm TO 722            ! Assign path to DMM.
   40    !
   50    ON TIMEOUT 7,5 GOTO Timetrap  ! Jump on 5-second timeout.
   60    !
   70    DISP &quot;Clearing DMM!&quot;
   80    CLEAR @Dmm                    ! Send SDC to DMM.
   90    OUTPUT @Dmm;&quot;*RST;*CLS&quot;       ! Reset &amp; clear status.
   100   !
   110   DISP &quot;Getting DMM status!&quot;
   120   OUTPUT @Dmm;&quot;*IDN?&quot;           ! Get ID from DMM.
   130   ENTER @Dmm;S$
   140   DISP S$
   150   !
   160   WAIT 2                        ! Delay 2 seconds.
   170   DISP &quot;Testing DMM!&quot;
   180   ON INTR 7 GOTO Srqtrap        ! Set up interface event.
   181   ENABLE INTR 7;2               ! Enable trap on SRQ.
   190   OUTPUT @Dmm;&quot;*ESE 1;*SRE 32&quot;  ! Enable SRQ on OPC.
   191   OUTPUT @Dmm;&quot;*OPC?&quot;           ! Clear any current pending OPC.
   192   ENTER @Dmm;S$
   200   OUTPUT @Dmm;&quot;*TST?;*OPC&quot;      ! Test DMM, flag OPC.
   210   LOOP                          ! Wait for SRQ.
   220   END LOOP
   230   !
   240 Timetrap:                       ! Go here on timeout.
   250   DISP &quot;Timed out -- done!&quot;
   260   STOP
   270   !
   280 Srqtrap:                        ! Go here on SRQ.
   281   DISP &quot;Got SRQ!&quot;
   290   ENTER @Dmm;S$
   300   DISP &quot;Test result: &quot;;S$;&quot; - done!&quot;
   310   END
 </strong></pre>
<p>
Note how the device is cleared with a CLEAR command and by sending the
*RST;*CLS string.  This is the recommended means of clearing a 488.2 device
back to a known state.  
</p>
<p>
Note also how this program sets up a &quot;timeout&quot; on the HPIB interface which
causes a jump if an HPIB action takes longer than the specified timeout.  For
the sake of keeping things simple, most of the examples in this document
don't set a timeout, but you should <em>always</em> do this in your own programs,
since your program will hang indefinitely if you don't.
</p>
<p>
As a self-test takes a long time, it is likely to exceed a specified timeout,
so this program configures the DMM to do an SRQ when the test operation is
complete.  It would actually be just as simple in this case to use SPOLL to
query the Status Byte and check for Bit 6 set, but knowing how to set up an
SRQ is useful in general.
</p>
<h2><a name="ib4_m4">[4.4] SECONDARY COMMON COMMANDS</a></h2>
<p>
* The remaining commands are implemented only in certain classes of
instruments, or aren't implemented at all.
</p>
<p>
* The optional Macro Commands allow a device to accept &quot;macro&quot; strings that
designate and instruct the device to execute a specific series of commands.
</p>
<p>
The *DMC (Define Macro) command sets up a relationship between a macro name
and the commands the macro will execute.  The macro is defined by sending the
*DMC command, followed by a arbitrary block program element or string
designating the label, followed by a string defining the macro; for example:
</p>
<pre><strong>
   *DMC &quot;HOME&quot;,#18MOVE 0,0
 </strong></pre>
<p>
-- defines a command that moves a pen plotter to its home position.
</p>
<p>
Macro definitions also allow the user to pass parameters within the macro;
dummy parameters appear as a &quot;$&quot;, followed by a single digit in the range &quot;1&quot;
to &quot;9&quot;, within the macro definition.  The dummy parameter can be used several
times within the macro definition string.
</p>
<p>
The macro label may be either in the form of a command or query, though it
cannot be the same as a common command or query.  It may be the same as a
device-dependent command; when the macro label is the same as a
device-dependent command, the device will execute the macro instead of the
device command (as long as macros are enabled).
</p>
<p>
The *EMC (Enable Macro) command enables and disables operation of macros; if
it is sent with a parameter of &quot;0&quot; it disables macros, if it is sent with a
parameter in the range &quot;-32767&quot; to &quot;32767&quot; will enable macros.  Note that
this command only disables macro <em>operation</em>.  The macros will retain their
definitions and will regain their functions when enabled again.  The matching
*EMC? (Enable Macro) query returns &quot;1&quot; if macros are enabled and &quot;0&quot; if they
are disabled.
</p>
<p>
The *GMC? (Get Macro Contents) query allows the user to inspect the
definition of a particular macro; the user send &quot;*GMC?&quot;  followed by the
macro label, and the device sends back the macro definition.  For example,
sending:
</p>
<pre><strong>
   *GMC? &quot;HOME&quot;
 </strong></pre>
<p>
-- returns the definition for &quot;HOME&quot;, which is &quot;#18MOVE 0,0&quot;, as shown in an
earlier example.
</p>
<p>
The *LMC? (Learn Macro) query returns the labels of all currently-defined
macros, as strings separated by commas.  If no macros are defined the device
will return a null string (&quot;&quot;).  The response will be the same whether macros
are enabled or disabled.
</p>
<p>
The *PMC (Purge Macro) command wipes all defined macros from device memory.
</p>
<p>
The *RMC (Remove Individual Macro) command (added in the latest version of
488.2) allows the user to get rid of a single macro.  The name of the macro
to be deleted is included as a string parameter to the command.
</p>
<p>
* The auto-address commands -- *AAD and *DLF -- allow a controller to
software-configure an HPIB system.  Since this capability is optional,
however, there is no necessity that all the devices in an HPIB system
implement auto-addressing even if they are 488.2-compliant, and so this
capability is in practice useless.
</p>
<p>
* The *OPT? (Option Identification) query tells the device to return its
options as a string containing fields separated by commas.  Note that missing
options are returned as a &quot;0&quot;, and that if the device has no options, it also
returns a &quot;0&quot;.  The maximum length of the response is 255 characters.
</p>
<p>
* The *PUD (Protected User Data) command stores up to 63 bytes of
device-dependent data.  The data can be retrieved with a *PUD? query.
</p>
<p>
* The *RDT (Resource Description Transfer) command is similar to *PUD, but it
writes a data that provides information describing the device.  A matching
*RDT? query retrieves the stored data.
</p>
<p>
* The *CAL? (Calibration) query tells the device to perform a
self-calibration.  It returns &quot;0&quot; if successful, or an error code from
&quot;-32767&quot; to &quot;32767&quot; if not.
</p>
<p>
* The parallel poll commands -- *IST?, *PRE, and *PRE? -- support Parallel
Poll operations, which almost nobody uses to begin with.  They will not be
discussed further.
</p>
<p>
* The *DDT (Define Device Trigger) command stores a sequence of commands that
a device will execute when it receives a GET command byte or a *TRG common
command.  It has a matching *DDT? query.
</p>
<p>
* The *PCB (Pass Control Back) command is used by the active controller to
tell what device to return control to after control has been passed to it.
The command takes a decimal numeric string in the range of &quot;0&quot; to &quot;30&quot;,
representing the controller's address, as a parameter.
</p>
<p>
* The instrument state commands allow a device to store a configuration in
its own memory and then recall it later.  The *RCL (Recall Instrument State)
command restores the device state from a state definition stored in local
(device) memory.  The command takes a number defining which memory block to
use, with the numbers starting at &quot;0&quot; and going up to a device-defined upper
limit.  The state restored by the *RCL command are the same functions
affected by the *RST command.  (The device may have a protection mechanism
that prevents the recall unless it is enabled.)
</p>
<p>
The *SAV (Save Instrument State) command stores the device state in local
memory.  The command is followed by a numeric parameter defining which block
to use.  (The device may have a protection mechanism that prevents the store
unless it is enabled.)
</p>
<p>
The *SDS (Save Default Device Settings) command allows a default state
definition to be stored in a given memory block in the device.  The command
takes a number (as defined for *RCL and *SAV) defining which memory to
restore to its default setting.
</p>
<hr />
<h1><a name="ib5_m0">[5.0] HPIB Tutor (5):  Introduction To SCPI</a></h1>
<p>
* This chapter provides an overview of the Standards Commands for
Programmable Instruments (SCPI) command set spec.
</p>
<hr />
<ul>
<li>
<a href="#ib5_m1">[5.1] SCPI OVERVIEW</a>
</li>
<li>
<a href="#ib5_m2">[5.2] SCPI COMMAND SYNTAX</a>
</li>
<li>
<a href="#ib5_m3">[5.3] EXAMPLE SCPI COMMAND SETS</a>
</li>
<li>
<a href="#ib5_m4">[5.4] SCPI DATA FORMATS</a>
</li>
<li>
<a href="#ib5_m5">[5.5] STATUS &amp; TRIGGERING</a>
</li>
</ul>
<hr />
<p>
<a href="#top">BACK TO INDEX</a>
</p>
<h2><a name="ib5_m1">[5.1] SCPI OVERVIEW</a></h2>
<p>
* The SCPI specification defines a programming language used to control test
and measurement instruments such as oscilloscopes, function generators, power
supplies, and spectrum analyzers.  Such instruments implement SCPI in their
firmware.
</p>
<p>
SCPI is in some senses a follow-on to IEEE 488.2.  The 488.2 spec defined
general commands, while SCPI provides the commands required for the operation
of specific types of instruments.
</p>
<p>
The first pass at a more comprehensive programming language spec was HP's
Test &amp; Measurement Language (TMSL), announced in August 1989 and offered as
an industry standard.  This first attempt defined 850 commands.  In April
1990, a consortium of manufacturers adopted the TMSL definition as the basis
for SCPI, incorporating some features (a Data Interchange Format, or DIF)
proposed by Tektronix.
</p>
<p>
The initial SCPI consortium consisted of HP, Tektronix, Fluke, Phillips,
Wavetek, Racal-Dana, Keithley, Bruel &amp; Kjaer, and National Instruments.  The
SCPI Consortium now maintains the SCPI definition and the formal document
that describes it.
</p>
<p>
The benefit of SCPI is compatibility -- that is, interoperability between
different instruments.  The same command that performs a certain function on
one instrument will perform exactly that same function on an entirely
different instrument, as long as both share that capability.  An instrument
control program designed for a certain type of instrument, such as a function
generator, will work for a comparable function generator from a different
vendor with few or no changes.
</p>
<p>
SCPI is designed with commands at several levels of generality to help
provide this compatibility.  A high-level SCPI command such as
MEASURE:VOLTAGE:AC? (&quot;read an AC voltage&quot;) will work on both an oscilloscope
and a DVM.  At the same time, SCPI also provides commands for low-level
instrument control that allow precise instrument programming, but are not
likely to work on another instrument.
</p>
<p>
While SCPI may seen a little intimidating and obscure at first (some refer
to it as &quot;C for instruments&quot;), it is much more consistent and understandable
than other instrument command sets.  Since it does cover the full range of
programmable instrumentation, the full SCPI spec is of course complicated,
but the basic rules are not hard to understand and you can pick them up
easily.
</p>
<h2><a name="ib5_m2">[5.2] SCPI COMMAND SYNTAX</a></h2>
<p>
* SCPI is, as noted, a superset of the 488.2 spec in terms of its data
formats, its usage of common commands, and the 488.2 status system, and uses
much of the same nomenclature.  SCPI &quot;program messages&quot;, for example, are the
data sent from the controller to the instrument.  Similarly, SCPI &quot;response
messages&quot; are the formatted data returned from the instrument to the
controller.  They both adhere to the 488.2 principle of &quot;forgiving listening,
precise talking&quot;.
</p>
<p>
Also as with 488.2, SCPI defines both commands and queries.  One of the nicer
principles on which SCPI is based, in fact, is if there is a command that
sets a value, there is a matching query that reads back that value.
</p>
<p>
The 488.2 commands encompassed by SCPI were explained in the previous chapter
and will not be examined in any more detail here.  The &quot;subsystem commands&quot;
are the heart of SCPI and the focus of the rest of this discussion.
</p>
<p>
* SCPI organizes commands into various sets that match &quot;subsystems&quot; of the
target instrument.  The commands for each subsystem are defined in a
hierarchical structure similar to the hierarchical file system found on most
computers.  In SCPI, this command structure is called a &quot;command tree&quot;.  A
simplified example, for the SENSe command as implemented on a DMM, is shown
below:
</p>
<pre><strong>
                              SENSe
                                |
                +---------------+---------------+
                |                               |
             CURRent                         VOLTage
                |                               |
         +------+------+                 +------+------+
         |             |                 |             |
       RANGe       RESolution          RANGe        RESolution
         |             |                 |             |
     +---+---+         |             +---+---+         |
     |       |         |             |       |         |
   UPPer    AUTO      AUTO         UPPer    AUTO      AUTO
 </strong></pre>
<p>
Definitions of the other subsystems are irrelevant for the moment.  The SENSe
subsystem is just a good way to discuss the syntax of SCPI, and other
subsystems will be illustrated in the next section.
</p>
<p>
The command tree is described with nomenclature similar to that used for file
systems.  The command at the top of the tree is the &quot;root&quot; command, and
subsystem commands are linked into &quot;paths&quot; through the tree.  For example,
one path through the tree is defined by the command sequence:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe:AUTO
 </strong></pre>
<p>
-- which sets the DMM to read voltages and uses autoranging.  Note how
colons (&quot;:&quot;) are used as path separators.  Another path is:
</p>
<pre><strong>
   :SENSe:CURRent:RANGe:UPPer
 </strong></pre>
<p>
-- which sets the DMM to read currents and uses the upper current range of
the DMM.  Note that the full path of a command does not need to be sent
to the DMM each time, but how and why that is so needs more detailed
explanation. <em>not</em> 
</p>
<p>
Commands sent to an instrument are intrepreted by a software routine called a
&quot;parser&quot;.  When decoding SCPI subsystem commands, the parser has to keep
track of the &quot;current path&quot; of the command, which is something like the
&quot;current directory&quot; in a hierarchical file system:  it specifies the
subsystem block the DMM is decoding commands for.
</p>
<p>
The parser navigates through the tree as directed by subsystem command
strings according to the following rules:
</p>
<ul>
<li> After power-on or the *RST common command is sent, the current path is set
   to the root.
</li>
<li> A message terminator, usually a &lt;newline&gt; (line-feed) character, also sets
   the current path to the root.
</li>
<li> A colon (&quot;:&quot;) is, as shown above, a path separator.  Each time the parser
   finds a colon in the subsystem command string it moves down through the
   command tree one level.  If the colon is the first character in the
   string, however, it specifies the root.  (The extensive use of colons in
   SCPI subsystem command strings has led to a slightly disrespectful
   description of the language as &quot;colon cancer&quot;.)
</li>
<li> A semicolon (&quot;;&quot;) separates two commands in the same subsystem command
   string without changing the current path.
</li>
<li> Whitespace characters, such as &lt;tab&gt; and &lt;space&gt;, are generally ignored.
   However, whitespace inside a subsytem command keyword is forbidden.  For
   example, MEAS ure is not a legal keyword.  
<p>
   Whitespace is also required to separate a parameter from a command.  For
   example, :SOURce:VOLTage6.2 is incorrect, you must use :SOURce:VOLTage
   6.2.
</p>
</li>
<li> Commas (&quot;,&quot;) are used to separate multiple parameters for a single
   subsystem command.
</li>
<li> Common commands, such as *RST, are not subsystem commands and are not
   interpreted as part of a path.
</li>
 </ul>
<p>
For example:
</p>
<pre><strong>
   :SENSe:VOLTage ; RANGe:AUTO ; RESolution:AUTO
 </strong></pre>
<p>
-- is the same as executing:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe:AUTO
   :SENSe:VOLTage:RESolution:AUTO
 </strong></pre>
<p>
Note that the spaces around the &quot;;&quot; are strictly window-dressing.  The parser
ignores them, they're just there to make the string easier to read.
Similarly:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe:AUTO ; :SENSe:CURRent:RANGe:UPPer
 </strong></pre>
<p>
-- is the same as executing both commands separately, since the &quot;:&quot;
immediately following the separating &quot;;&quot; resets the current path to root.
</p>
<p>
* The command tree is specified concisely through a &quot;subsystem command table&quot;
that define the commands and their parameters.  For example, the SENSE
command tree illustrated previously evaluates to the following command table:
</p>
<pre><strong>
   _______________________________________

   Command                 Parameters
   _______________________________________

   [:SENSe]               

      :CURRent            
         :RANGe           
            :AUTO          Boolean or ONCE
           [:UPPer]        numeric
         :RESolution       numeric
            :AUTO          Boolean or ONCE

      :VOLTage            
         :RANGe           
            :AUTO          Boolean or ONCE
           [:UPPer]        numeric
         :RESolution       numeric
            :AUTO          Boolean or ONCE
   _______________________________________
 </strong></pre>
<p>
The hierarchy of the command paths is given by the level of indenting in the
&quot;Command&quot; column of the table.  Following the indenting yields subsystem
command strings of the form:
</p>
<pre><strong>
   :SENSe:CURRent:RANGe:AUTO ON
 </strong></pre>
<p>
As you should have noticed by now, most of the keywords are listed as strings
of uppercase letters, followed by lowercase letters.  This mixing of cases is not part of the SCPI definition as such.  SCPI isn't case-sensitive, and
so you can send subsystem commands all upppercase, all lowercase, or any
mixture of the two.
<em>not</em> 
</p>
<p>
What the lowercase letters in the definitions specify is that those
characters are optional, and may be discarded if desired.  To illustrate:
</p>
<pre><strong>
   :SENS:CURR:RANG:AUTO ON
 </strong></pre>
<p>
-- is the same as:
</p>
<pre><strong>
   :SENSe:CURRent:RANGe:AUTO ON
 </strong></pre>
<p>
The keywords in square brackets are &quot;implied&quot; keywords, meaning that if a
subsystem command at that path level is not specified, it is assumed.  For
example:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe:UPPer 6.5
 </strong></pre>
<p>
-- is the same as:
</p>
<pre><strong>
   :VOLTage:RANGe 6.5
 </strong></pre>
<p>
An implied keyword should not be used in a command string unless it is
necessary to do so.  Implied keywords often are defined to define
enhancements of SCPI.  They are left implied to keep from &quot;breaking&quot; programs
that use commands that conform to earlier revs.  Avoiding the use of implied
keywords makes it more likely a program will work with an earlier type of
SCPI instrument.
</p>
<p>
For almost all commands that can set a value, there is a matching query that
can read one back.  This is similar to 488.2 common command queries in that
the query string is the same as the comparable command string, but with a &quot;?&quot;
tacked on.  For example, the command:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe
 </strong></pre>
<p>
-- has the matching query:
</p>
<pre><strong>
   :SENSe:VOLTage:RANGe?
 </strong></pre>
<p>
If a table contains a keyword that ends in a &quot;?&quot;, that means that the
subsystem command string only exists as a query, and there is no command
form.  Other subsystem commands may not have matching queries, as they
initiate events, such as device triggers, and do not set values that can be
queried.
</p>
<p>
The parameters for each command, if any, are listed in the right column of
the table.  If any parameters are optional, they are listed in square
brackets, just like the implied keywords.  The ranges of optional values are
defined in the documentation for a specific instrument.
</p>
<p>
Commands are sent to the instrument followed by their parameters, if any are
required.  Note that parameters must be separated from the command by a
space, and multiple parameters are separated by commas (&quot;,&quot;).  The full
command sequence is terminated by a newline, an EOI, or both.
</p>
<h2><a name="ib5_m3">[5.3] EXAMPLE SCPI COMMAND SETS</a></h2>
<p>
* For examples of SCPI syntax, consider simplified command sets for a
hypothetical signal generator, DVM, and relay scanner.  
</p>
<p>
These devices are examples of the three classes of programmable instruments:
source, sense, and switch devices:  
</p>
<ul>
<li> Source instruments output some kind of signal, such as power supplies and
   pulse generators.  
</li>
<li> Sense instruments are those which measure signals, such as power meters 
   and counters.  
</li>
<li> Switch instruments use relays or solid-state switches to route signals 
   between an instrument and devices under test.  
</li>
 </ul>
<p>
More sophisticated instruments may combine multiple instrument functions in a
single package.
</p>
<p>
Our hypothetical signal generator can produce sine, triangle, or square wave
outputs.  The output is programmable from 1 Hz to 100 kHz at levels of 0 to
500 mV RMS.  The output impedance can be switched between 50 and 75 ohms.
</p>
<p>
At power-on, or after *RST, the signal generator is set to output a 1
millivolt RMS, 1 kHz sine wave with an output impedance of 75 ohms, although
the actual output is disabled.  The signal generator is programmed in fixed
units of Hz, volts RMS, and ohms.  The command table is illustrated below:
</p>
<pre><strong>
   __________________________________________

   Command                  Parameters 
   __________________________________________

    :OUTPut
      [:STATe]              Boolean
       :IMPedance           50 or 75

   [:SOURce]
       :FREQuency
         [:FIXed]           1 to 1e5
       :VOLTage
         [:LEVel]
            [:IMMediate]
               [AMPlitude]  0 to 0.5
       :FUNCtion
         [:SHApe]           SINe or SQUare or
                            TRIangle
   __________________________________________
 </strong></pre>
<p>
This device incorporates two subsystems, an OUTPut subsystem and a SOURce
subsystem.  Note how the command set incorporates a large number of implied
keywords -- a common feature of practical SCPI implementations that greatly
reduces the number of commands you actually need to remember -- and
simplifies to only five distinct command forms:
</p>
<pre><strong>
   :FREQ 100        Set output frequency (to 100 Hz).
   :VOLT 0.1        Set output voltage (to 100 mV RMS).
   :FUNC TRI        Set output function (to triangle wave).
   :OUTPut:IMP 50   Set output impedance (to 50 ohms).
   :OUTPut ON       Turn on outputs.
 </strong></pre>
<p>
The matchinq queries consist of:
</p>
<pre><strong>
   :FREQ?         Query output frequency.
   :VOLT?         Query output voltage.
   :FUNC?         Query output function.
   :OUTPut:IMP?   Query output impedance.
   :OUTPut?       Query output state.
 </strong></pre>
<p>
Note that the :OUTPut:IMP command only has two values, 50 or 75.  Other
values will be rounded to the allowed value.
</p>
<p>
Note also the :OUTPut ON command, which can cause problems for novices, since
the output terminals of a SCPI instrument are disabled after power-on or
*RST.  The programmer has to use :OUTPut ON to specifically enable the
outputs.
</p>
<p>
* The hypothetical DVM is capable of making either AC or DC voltage
measurements.  It measures input voltages from 0 to 100 volts DC or AC RMS.
The DVM has two rear panel BNC ports, for the &quot;measurement complete&quot; output
and an &quot;external trigger&quot; input.  For better noise rejection, the DVM
provides a low-pass input filter that is programmable to frequencies of 100,
200, or 1000 Hz.
</p>
<p>
After power-on or *RST, the DVM is configured to read DC voltages using
autoranging and the best possible resolution.  The input impedance is set to
10 megohms, and the input filter is set to 1000 Hz.  The trigger source is
set to IMMediate.  Its command table is shown below:
</p>
<pre><strong>
   _______________________________________________

   Command                   Parameters
   _______________________________________________

    :CONFigure              
      [:SCALar]             
          :VOLTage          
             :AC             numeric,numeric (*)
            [:DC]            numeric,numeric (*)

    :FETCh                  
      [:SCALar]             
          :VOLTage          
             :AC?            numeric,numeric (*)
            [:DC]?           numeric,numeric (*)

    :INITiate               
      [:IMMediate]          

    :INPut                  
       :IMPedance            50 or 1e6
       :FILTer              
         [:LPASs]            100 or 200 or 1000

    :MEASure                
      [:SCALar]             
          :VOLTage          
             :AC             numeric,numeric (*)
            [:DC]            numeric,numeric (*)

    :READ                   
      [:SCALar]             
          :VOLTage          
             :AC?            numeric,numeric (*)
            [:DC]?           numeric,numeric (*)

   [:SENSe]                 
       :FUNCtion             AC or DC

    :TRIGger                
      [:IMMediate]          
       :SOURce               IMMediate or EXTernal
       :COUNt                numeric
   _______________________________________________

   (*):  The first numeric parameter specifies the 
   input voltage range from 0.001 to 100 volts by 
   powers of 10; the second specifies the voltage 
   resolution, which is rounded to 0.001, 0.01, 
   or 0.1 volts.  
   _______________________________________________
 </strong></pre>
<p>
This device has 8 command subsystems that provide somewhat overlapping
functionality.  The commands :MEASure, :CONFigure &amp; :READ, and :INITiate &amp;
:FETCh demonstrate how SCPI allows you to take measurements at differing
levels of detail.  :MEASure, for example, is very easy to use; all you need
to know is what quantity you want to measure.  :CONFigure &amp; :READ are not
quite as easy to use, but they are very flexible; and :INITiate &amp; :FETCh are
hard to use, but offer maximum flexibility.
</p>
<p>
The high-level commands are actually equivalent to sequences of low-level
commands, so it makes sense to study the low-level commands first and then
work our way up.  However, in practice, a smart programmer will never use a
low-level command when a higher-level one will do the job, since the
higher-level commands make the job easier to implement and understand, as
well as easier to port to other systems.
</p>
<p>
Most measurements can be modeled as a three-step process:
</p>
<ul>
<li> Set up the instrument.
</li>
<li> Trigger the measurement.
</li>
<li> Retrieve the reading.
</li>
 </ul>
<p>
When you use low-level commands, you must do each of these steps explicitly.
Typically, you begin setup by sending *RST to place the instrument into a
known state, and then you change each setting, one by one, until you have the
instrument configured.  Then you trigger the measurement.  The trigger may be
generated automatically by your setup commands, or you can send an explicit
trigger command.  For example, an :INITiate:IMMediate command, forces the
measurement to occur as soon as the command is interpreted.  Finally, you can
read the measurement using a :FETCh query.
</p>
<p>
For the DVM, a low-level sequence of commands to read an AC voltage looks
like this:
</p>
<pre><strong>
   10 OUTPUT @Dvm;&quot;*RST&quot;              ! Reset into a known state.
   20 OUTPUT @Dvm;&quot;:FUNC AC&quot;          ! Change function to AC volts.
   30 OUTPUT @Dvm;&quot;:INP:IMP 50&quot;       ! Change input impedance to 50 ohms.
   40 OUTPUT @Dvm;&quot;:INIT:IMM&quot;         ! Trigger a reading.
   50 OUTPUT @Dvm;&quot;:FETCH:VOLT:AC?&quot;   ! Query for the reading.
   60 ENTER @Dvm;Vac                  ! Get the reading.
 </strong></pre>
<p>
Let's compare this to programming the instrument with high-level commands.
:MEASure is the simplest (and generally most useful) way to make and read a
measurement.  A single :MEASure command is equivalent to programming an
instrument setting, sending an :INITiate:IMMediate, followed by a :FETCh
query.  The same AC volts measurement shown above can be simplified using
:MEASure to:
</p>
<pre><strong>
   10 OUTPUT @Dvm;&quot;:MEAS:VOLT:AC?&quot;    ! Measure AC volts.
   20 ENTER @Dvm;Vac                  ! Get the reading.
 </strong></pre>
<p>
Using :MEASure does have its disadvantages.  When you use :MEASure, the
instrument chooses the &quot;best&quot; default settings to accomplish the measurement
you want.  Usually instrument documentation lists the settings associated
with :MEASure.  However, sometimes the instrument's idea of a &quot;best&quot; setting
conflicts with your needs.  For example, suppose you want to use the DVM to
read an AC voltage through a 1 megohm input impedance.  :MEASure won't work,
because it always sets the input impedance to 50 ohms for an AC measurement.
</p>
<p>
:CONFigure and :READ offer a reasonable compromise between :MEASure and
low-level commands.  :CONFigure performs an instrument setup, while :READ
triggers a measurement and reads back the voltage, and so :CONFigure followed
by :READ is equivalent to a :MEASure.  This is how you could read an AC
voltage through a 1 megohm input impedance:
</p>
<pre><strong>
   10 OUTPUT @Dvm;&quot;*RST&quot;              ! Reset to a known state.
   20 OUTPUT @Dvm;&quot;:CONF:VOLT:AC&quot;     ! Set up to read AC volts.
   30 OUTPUT @Dvm;&quot;:INP:IMP 1e6&quot;      ! Set input impedance.
   40 OUTPUT @Dvm;&quot;:READ:VOLT:AC?&quot;    ! Trigger and query for reading.
   50 ENTER @Dvm;Vac                  ! Read back the voltage.
 </strong></pre>
<p>
* Our hypothetical scanner is a simple, 8-channel multiplexer switch.  It
includes two rear panel BNC ports:  &quot;channel closed&quot; and &quot;external trigger&quot;.
At power on or after *RST, all channels are open and the trigger source is
set to immediate.  The command table follows:
</p>
<pre><strong>
   _______________________________________________ 

   Command                   Parameters
   _______________________________________________

   [:ROUTe]
       :CLOSe                (@0:7)
       :OPEN                 (@0:7)
       :SCAN                 (@0:7)

    :TRIGger
      [:IMMediate]
       :SOURce               IMMediate or EXTernal
   _______________________________________________
 </strong></pre>
<p>
This is, like the source, a simple device, with only two command subsystems.
Note how the Scanner uses a &quot;channel list&quot; as a parameter.  This is a special
parameter used in some :ROUTe subcommands.  Typical examples of channel lists
include:
</p>
<pre><strong>
   (@1)       Channel 1.
   (@1:4)     Channels 1 through 4.
   (@1,3)     Channels 1 and 3 only.
   (@1:4,7)   Channels 1 through 4, and 7.
 </strong></pre>
<p>
The :OPEN and :CLOSe commands simply open and close switches in the channel
list.  The :SCAN command places a channel list into the internal memory of
the switch box.  Once a :SCAN has been programmed, the scanner closes channels
in sequence using break-before-make as it receives each trigger, and begins
again at the first channel in the list when it completes the last.
</p>
<p>
The following statements configure the scanner to scan channels 1 through 3
using the rear panel BNC external trigger:
</p>
<pre><strong>
   40 OUTPUT @Scan;&quot;*RST;*CLS&quot;
   50 OUTPUT @Scan;&quot;:SCAN (@1:3)&quot;
   60 OUTPUT @Scan;&quot;:TRIG:SOUR EXT&quot;
 </strong></pre>
<p>
You can query the condition of any individual channel or channel list.  SCPI
instruments always return a 1 or a 0 in the same order that the channel list
in the query was specified.  The meaning of 1 or 0 depends on whether you
query using the :OPEN or :CLOSe command.  If you query using :OPEN, a 1 means
open and a 0 means closed, while if you query using :CLOSe, a 1 means closed
and a 0 means open.  
</p>
<p>
The following statements perform some simple queries:
</p>
<pre><strong>
   10 OUTPUT @Scan;&quot;OPEN? (@1)&quot;     ! Is channel 1 open?
   20 ENTER @Scan;Ch1               ! Read back state (1=TRUE=OPEN).
   30 OUTPUT @Scan;&quot;CLOSE? (@1)&quot;    ! Is channel 1 closed?
   40 ENTER @Scan;Ch1               ! Read back state (1=TRUE=CLOSED).
   50 OUTPUT @Scan;&quot;OPEN? (@1:4)&quot;   ! Are any of channels 1 through 4 open?
   60 ENTER @Scan;Ch1,Ch2,Ch3,Ch4   ! Read back states of four channels.
 </strong></pre>
<p>
* As an example consider programming the three instruments to test the gain
of a three-stage amplifier.  The signal generator drives a sine wave into the
input stage of the amplifier, the scanner routes signals from the output of
each stage into the DVM, and gains are computed using simple voltage ratios,
not DB.
</p>
<p>
Measurement speed is optimized in this application by setting the DVM to a
fixed range and performing &quot;hardwired handshaking&quot; between the DVM and the
switch box.  This is done by linking the DVM's &quot;measurement complete&quot; output
to the switch box's &quot;external trigger&quot; input, and linking the switch box's
&quot;channel closed&quot; output back to the DVM's &quot;external trigger&quot; input.
</p>
<p>
Each time the DVM completes a measurement, it pulses the &quot;measurement
complete&quot; output, which is turn causes the switch box to move to the next
channel in its scan list.  When the switch box closes this channel, the box
pulses its &quot;channel closed&quot; output, which feeds back to the DVM to trigger
the next measurement.
</p>
<p>
The program to perform these measurements follows below:
</p>
<pre><strong>
   10   CLS
   15   INTEGER Dummy
   20   REAL Readings(0:3)
   30   !
   40   ASSIGN @Dvm TO 722                  ! Set up paths to devices.
   50   ASSIGN @Switch TO 711
   60   ASSIGN @Siggen TO 719
   70   !
   80   CLEAR @Dvm                          ! Clear device interfaces.
   90   CLEAR @Switch
   100  CLEAR @Siggen
   110  !
   120  OUTPUT @Dvm;&quot;*CLS;*RST&quot;             ! Reset the devices.
   130  OUTPUT @Switch;&quot;*CLS;*RST&quot;
   140  OUTPUT @Siggen;&quot;*CLS;*RST&quot;
   150  !
   160  ! Configure the DVM to measure a 500 mV RMS signal with 5 mv
   170  ! resolution.
   180  !
   190  OUTPUT @Dvm;&quot;:CONF:VOLT:AC 0.5,0.005&quot;
   200  !
   210  ! Once armed, accept four triggers from the external trigger.
   220  !
   230  OUTPUT @Dvm;&quot;:INIT ; :TRIG:COUNT 4; SOUR EXT&quot;
   240  !
   250  ! Set the signal generator's output frequency to 100 kHz at 500 mV
   260  ! RMS.  The output function is SINE (default at *RST).
   270  !
   280  OUTPUT @Siggen;&quot;:FREQ 1e5 ; :VOLT 0.5&quot;
   290  !
   300  ! Change the source output frequency to 50 ohms.
   310  !
   320  OUTPUT @Switch;&quot;:SCAN (@1:4) ; :TRIG:SOUR EXT&quot;
   330  !
   340  ! Begin measurement -- turn on the source output signal; the *OPC?
   350  ! query returns a 1 only after the output has settled.
   360  !
   370  OUTPUT @Siggen;&quot;:OUTPUT ON ; *OPC?&quot;
   380  ENTER @Siggen;Dummy
   390  !
   400  ! Close the first channel in the switch, the hardwired triggering  
   410  ! does the rest.
   420  !
   430  OUTPUT @Switch;&quot;:INIT ; :TRIG:IMM&quot;
   440  !
   450  ! Put readings in the output queue.
   460  !
   470  OUTPUT @Dvm;&quot;:READ:VOLT:AC?&quot;
   480  DISP &quot;Waiting for the measurement to complete.&quot;
   490  !
   500  ! Get readings into array as they become available.
   510  !
   520  ENTER @Dvm;Readings(*)
   530  DISP &quot;Measurement complete.&quot;
   540  !
   550  ! Turn off signal generator output.
   560  !
   570  OUTPUT @Siggen;&quot;:OUTPUT OFF&quot;
   580  !
   590  ! Calculate and print gains.
   595  !
   600  PRINT &quot;Stage 1 gain = &quot;;Readings(1)/Readings(0)
   610  PRINT &quot;Stage 2 gain = &quot;;Readings(2)/Readings(1)
   620  PRINT &quot;Stage 3 gain = &quot;;Readings(3)/Readings(2)
   630  !
   640  END
 </strong></pre>
<h2><a name="ib5_m4">[5.4] SCPI DATA FORMATS</a></h2>
<p>
* SCPI data types are essentially derived (with some small additions) from
the program data types defined in 488.2.  The formats are flexible (&quot;forgiving
listening&quot;) and a quick survey should be easily understood.
</p>
<p>
Simple numeric parameters encompass familiar integer and floating-point
formats:
</p>
<pre><strong>
   100
   100.
    -1.23
     4.5e3
    -7.89E-01
      .5
 </strong></pre>
<p>
Numeric parameters are a superset of simple numeric parameters, and add
certain constant values to that definition.  All instruments will recognize
the constants:
</p>
<pre><strong>
   MAXimum
   MINimum
 </strong></pre>
<p>
-- though the exact value of these constants is device-dependent.  Other
special values, such as:
</p>
<pre><strong>
   UP
   INFinity
   DEFault
 </strong></pre>
<p>
-- may be defined for specific instruments.  For example:
</p>
<pre><strong>
   100 OUTPUT @Dvm;&quot;:VOLT:DC MAX&quot;
   110 OUTPUT @Dvm;&quot;:CONF:VOLT:DC 10.0,Min&quot;
 </strong></pre>
<p>
Discrete parameters are keywords associated with a list of discrete settings
in a device.  Like subsystem commands, they have a long and a short form.
Upper- and lower-case letters may be mixed, but the value returned for a
discrete parameter by a subsystem query will always be uppercase.  Samples of
discrete parameters include:
</p>
<pre><strong>
   INTernal:         Specify internal trigger source.
   EXTernal:         Specify external trigger source.
   POSitive:         Specify trigger arm on positive transition.
   NEGative:         Specify trigger arm on negative transition.
   BOTH:             Specify trigger arm on either transition.
 </strong></pre>
<p>
For some practical examples:
</p>
<pre><strong>
   100 OUTPUT @Dvm;&quot;:TRIGGER:SOURCE INT&quot;
   110 OUTPUT @Dvm;&quot;:ARM:SLOPE NEGATIVE&quot;
 </strong></pre>
<p>
Boolean parameters should be familiar:
</p>
<pre><strong>
   ON
   OFF
   TRUE
   FALSE
   1
   0
 </strong></pre>
<p>
When you query a Boolean setting, you will always get back a &quot;1&quot; or &quot;0&quot;.
For example:
</p>
<pre><strong>
   100 OUTPUT @Dvm;&quot;:OUTPUT ON&quot;
   110 OUTPUT @Dvm;&quot;:OUTPUT 0&quot;
 </strong></pre>
<p>
String parameters allow ASCII strings to be sent as parameters.  For
example:
</p>
<pre><strong>
   'this is a STRING'
   &quot;this is also a string&quot;
   &quot;one double quote inside brackets: [&quot;&quot;]&quot;
   'one single quote inside brackets: ['']'
 </strong></pre>
<p>
Single quotes are the most convenient format for HP BASIC:
</p>
<pre><strong>
   110 OUTPUT @Dvm;&quot;:DISPLAY:TEXT 'STOP!'&quot;
 </strong></pre>
<p>
Block parameters are sent using the indefinite-length and definite-length
block formats defined by 488.2, where the formats for indefinite-length and
definite-length blocks are respectively:
</p>
<pre><strong>
   #0&lt;DAB&gt;&lt;DAB&gt; ... &lt;DAB&gt;NL&amp;EOI
   #&lt;num_digits_in_byte_count&gt;&lt;byte_count&gt;&lt;DAB1&gt;&lt;DAB2&gt; ... &lt;DABn&gt;
 </strong></pre>
<p>
For example, the following HP BASIC commands send the same 7 bytes of ASCII
text as indefinite- and definite-length blocks respectively:
</p>
<pre><strong>
   120 OUTPUT @Dvm;&quot;#0ABC_XYZ&quot;,END  ! END asserts EOI.
   OUTPUT @Dvm;&quot;#17ABC_XYZ&quot;         ! &lt;num_digits&gt;=1, &lt;byte_count&gt;=7
 </strong></pre>
<p>
Non-decimal numeric parameters allow numeric information to be sent as
binary, octal, or hexadecimal:
</p>
<pre><strong>
   #b010110100
   #Q773662
   #h3FA1
 </strong></pre>
<p>
The header may be upper- or lower-case characters.
</p>
<p>
* As mentioned earlier, data returned to a host in response to a SCPI query
is known as &quot;response data&quot;.  The response data types, which are also derived
from 488.2 response data types, match the data types defined for parameters
but with more concise and restricted syntax (&quot;precise talking&quot;).  
</p>
<p>
Note that multiple data elements returned in response to a query are
separated by commas (&quot;,&quot;).  Note also that, since multiple queries can be sent
as a single program message:
</p>
<pre><strong>
   :QUERY1?;:QUERY2?
 </strong></pre>
<p>
-- then multiple responses can also be sent as a single response message,
with the responses separated by semicolons (&quot;;&quot;).  (Sending multiple queries
in a single program message is bad form, though it is not illegal.)  Response
data is always terminated with a newline and EOI. <em>always</em> 
</p>
<p>
Real response data defines floating-point data types with a uniform format:
</p>
<pre><strong>
      1.23E+0
     -1.0E+2
     -1.23
   -100.0
     -7.89E-01
      0.5
 </strong></pre>
<p>
Integer response data defines an integer-only data format:
</p>
<pre><strong>
       0
    +100
    -100
     256
   65535
       4
 </strong></pre>
<p>
Discrete response data is defined exactly as is discrete parameter data, but
the response data, unlike the discrete parameter data, is always
uppercase: <em>always</em>
</p>
<pre><strong>
   INT
   EXT
   POS
   NEG
 </strong></pre>
<p>
String response data is defined like string parameter data, except that only
double-quotes are legal:
</p>
<pre><strong>
   &quot;this is a string&quot;
   &quot;one double quote inside brackets: [&quot;&quot;]&quot;
 </strong></pre>
<p>
Definite-length and indefinite-length block response data types are totally
identical to their parameter equivalents.
</p>
<p>
Binary, octal, and hexadecimal response data types are identical to their
parameter equivalents, except that lower-case headers are not allowed:
</p>
<pre><strong>
   #B00001111
   #Q0707
   #H0F1F
 </strong></pre>
<h2><a name="ib5_m5">[5.5] STATUS &amp; TRIGGERING</a></h2>
<p>
* SCPI specifies advanced features for status and triggering.  In fact, it
defines more features than anyone could ever want.
</p>
<p>
The status system is in particular extremely complicated.  As it turns out,
most of the features were simply due to different HP instrument divisions
promoting their own pet features when the spec was being defined, with the
end result being a system that can be extremely confusing.
</p>
<p>
As a way of getting a grasp of the SCPI status system, consider a simple
example:  the status system of the 34401 (ALF) DMM, which is illustrated
below:
</p>
<pre><strong>
         +-----+   +-----+
         | VOV +--&gt;| VOV +--&gt;-+
         |     |   |     |    |
         | COV +--&gt;| COV +--&gt;-+        VOV:  voltage overload
         |     |   |     |    |        COV:  current overload
         | 2   +--&gt;| 2   +--&gt;-+        OOV:  ohms overload
         |     |   |     |    |        TLO:  limit test fail lo
         | 3   +--&gt;| 3   +--&gt;-+        THI:  limit test fail hi
         |     |   |     |    |
         | 4   +--&gt;| 4   +--&gt;-+
         |     |   |     |    |
         | 5   +--&gt;| 5   +--&gt;-+
         |     |   |     |    |
         | 6   +--&gt;| 6   +--&gt;-+
         |     |   |     |    |
         | 7   +--&gt;| 7   +--&gt;-+
         |     |   |     |    +------------+
         | 8   +--&gt;| 8   +--&gt;-+            |
         |     |   |     |    |            |
         | OOV +--&gt;| OOV +--&gt;-+            |
         |     |   |     |    |            |
         | 10  +--&gt;| 10  +--&gt;-+            |
         |     |   |     |    |            |
         | TLO +--&gt;| TLO +--&gt;-+            |
         |     |   |     |    |            |
         | THI +--&gt;| THI +--&gt;-+            |
         |     |   |     |    |            |        Status Byte
         | 13  +--&gt;| 13  +--&gt;-+            |    +-----+   +-----+   
         |     |   |     |    |            |    | 0   +--&gt;| 0   +--&gt;-+
         | 14  +--&gt;| 14  +--&gt;-+            |    |     |   |     |    |
         |     |   |     |    |            |    | 1   +--&gt;| 1   +--&gt;-+
         | 15  +--&gt;| 15  +--&gt;-+            |    |     |   |     |    |
         +-----+   +-----+                 |    | 2   +--&gt;| 2   +--&gt;-+
 STAT:QUES:EVEN?   STAT:QUES:ENAB &lt;mask&gt;   |    |     |   |     |    |
                   STAT:QUES:ENAB?         +---&gt;| QUE +--&gt;| QUE +--&gt;-+
                                                |     |   |     |    +-[OR]-+
                         from output queue ----&gt;| MAV +--&gt;| MAV +--&gt;-+      |
                                                |     |   |     |    |      |
         +-----+   +-----+           +---------&gt;| ESB +--&gt;| ESB +--&gt;-+      |
         | OPC +--&gt;| OPC +--&gt;-+      |          |     |   |     |    |      |
         |     |   |     |    |      |    +----&gt;| RQS +--&gt;| --- +--&gt;-+      |
         | RQC +--&gt;| RQC +--&gt;-+      |    |     |     |   |     |    |      |
         |     |   |     |    |      |    |     | 7   +--&gt;| 7   +--&gt;-+      |
         | QYE +--&gt;| QYE +--&gt;-+      |    |     +-----+   +-----+           |
         |     |   |     |    |      |    |      *STB      *SRE &lt;mask&gt;      |
         | DDE +--&gt;| DDE +--&gt;-+      |    |                *SRE?            |
         |     |   |     |    +-[OR]-+    +---------------------------------+
         | EXE +--&gt;| EXE +--&gt;-+
         |     |   |     |    |
         | CME +--&gt;| CME +--&gt;-+
         |     |   |     |    |
         | URQ +--&gt;| URQ +--&gt;-+
         |     |   |     |    |
         | PON +--&gt;| PON +--&gt;-+
         +-----+   +-----+
          *ESR?     *ESE &lt;mask&gt;
                    *ESE?
 </strong></pre>
<p>
This is a consistent extension of the 488.2 status system.  In this case, an
additional status bit, QUE (Questionable Data), is used to reflect the status
of an additional status register, the Questionable Data register, which
contains a subset of SCPI bit definitions required by the ALF.  (Note that
the bit acronyms specified are not defined by SCPI, I just made them up
to make the diagram simpler.) <em>not</em> 
</p>
<p>
The Questionable Data Register can be queried with:  STAT:QUES:EVEN?.  Its
event enable register can be set with STAT:QUES:ENAB &lt;mask&gt;, and the event
masks can be read with STAT:QUES:ENAB?.
</p>
<p>
While only 5 bits are defined in the Questionable Data Register on the ALF,
the SCPI standard provides definitions for most of the other bits as well.
Note that SCPI also defines bit 7 of the Status Byte as OPR, which reflects
the status of a another 16-bit status register, the Standard Operation Status
Register, that is not implemented on the ALF.
</p>
<p>
* The SCPI trigger system is also very sophisticated, but more useful.  An
instrument trigger system synchronizes an instrument's actions -- such as
making a measurement or generating an output signal -- with specific events
-- such as a software command or an external trigger input.
</p>
<p>
The SCPI triggering system can become quite complicated but a simple subset
of it incoporates three levels:
</p>
<ul>
<li> An INIT level that simply tells the device to trigger.
</li>
<li> A TRIG level that adds triggering conditions.
</li>
<li> An ARM level that adds pretriggering setup conditions.
</li>
 </ul>
<p>
This is more than enough for most purposes, and in fact many instruments
don't implement even this level of triggering capabilities.
</p>
<p>
* Example commands using INIT include:
</p>
<pre><strong>
   :ABORt           Abort operations, go to idle.
   :INIT:IMM        Execute programmed operation.
   :INIT:CONT ON    Execute programmed operations continuously.
   :INIT:CONT OFF   Stop programmed operations after current one is done.
 </strong></pre>
<p>
On their own, the INIT commands simply tell the device to do something
immediately, either once, using :INIT:IMM, or continuously, using :INIT:CONT
ON (with the sequence broken by :INIT:CONT OFF or ABORT).
</p>
<p>
* The TRIG commands add a layer of qualification to the triggering.  The TRIG
commands are very complicated, so a list of typical commands will have to do:
</p>
<pre><strong>
   :TRIG:SOURCE IMM    Trigger on INIT:IMM (default action).
   :TRIG:SOURCE INT    Trigger on internal signal (input signal).
   :TRIG:SOURCE EXT    Trigger on external trigger input.
   :TRIG:SOURCE MAN    Trigger on front-panel button or the like.
   :TRIG:SOURCE BUS    Trigger on HPIB GET or *TRG command.

   :TRIG:LEVEL 3       Specify level at which trigger occurs (5 volts).

   :TRIG:SLOPE POS     Trigger on rising edge of signal.
   :TRIG:SLOPE NEG     Trigger on falling edge of signal.
   :TRIG:SLOPE BOTH    Trigger on both edges of signal.

   :TRIG:COUPL AC      Specify AC coupling to trigger input.
   :TRIG:COUPL DC      Specify DC coupling to trigger input.
   :TRIG:DELAY 5       Specify delay of action after triggering (5 seconds).
   :TRIG:ECOUNT 4      Specify number of trigger events to cause trigger (4).
   :TRIG:HYST 0.05     Specify noise margin in trigger signal.

   :TRIG:TTL           Specify trigger on TTL signal levels.
 </strong></pre>
<p>
This should be self-explanatory, except for the :TRIG:HYST command.  It is
necessary to specify a noise margin with a trigger because the input signal
that causes the trigger may be noisy, and if the noise jumps around the
trigger level during a signal transition, the trigger may occur multiple
times when it's only supposed to happen once.  
</p>
<p>
For example, suppose we trigger off an input signal hitting 3 volts on a
positive slope.  The hysteresis spec tells the triggering system not to
trigger again until the input signal travels downward again by at least the
noise margin.
</p>
<p>
To demonstrate a TRIG configuration, assume that you want to make a
measurement when the input signal passes through 5 volts, with either a
positive or negative slope.  The signal contains noise that averages about 2
millivolts peak to peak.  This could be done with the following sequence of
trigger commands:
</p>
<pre><strong>
   10  OUTPUT @Dev;&quot;*RST;*CLS&quot;           ! Clear the device.
   20  CALL Config_dev(@Dev)             ! Set up device configuration.
   25  !
   30  OUTPUT @Dev;&quot;:TRIG:SOURCE EXT&quot;    ! Trigger on external trigger input.
   40  OUTPUT @Dev;&quot;:TRIG:LEVEL 5&quot;       ! Trigger at 5 V level.
   50  OUTPUT @Dev;&quot;:TRIG:SLOPE BOTH&quot;    ! Trigger at any crossing.
   60  OUTPUT @Dev;&quot;:TRIG:HYST 0.002&quot;    ! Compensate for noise.
   65  !
   70  OUTPUT @Dev;&quot;:INIT:IMM&quot;           ! Wait for it.
   75  !
   80  CALL Get_trace(@Dev,Data(*))      ! Get trace from device.
 </strong></pre>
<p>
Note how :INIT:IMM is used to tell the device to wait for a trigger.  The
TRIG statements merely qualify what the trigger will be.  Note also the CALL
statements in this listing.  These invoke user-defined subprograms to perform
the indicated actions.
</p>
<p>
* The ARM commands offer a second level of triggering to provide
pretriggering conditions.  Their syntax is effectively the same as the TRIG
commands, with the keyword &quot;ARM&quot; substituted for &quot;TRIG&quot;.
</p>
<p>
For example, assume that you want to measure a TTL signal input.  Before
triggering the measurement, you want to first capture two negative TTL edges
on an input fed to the external trigger input, and then capture three
negative TTL edges on the input signal itself.
</p>
<pre><strong>
   10   OUTPUT @Dev;&quot;*RST;*CLS&quot;         ! Clear the device.
   20   CALL Config_dev(@Dev)           ! Set up device configuration.
   25   !
   30   OUTPUT @Dev;&quot;:ARM:SOURCE EXT&quot;   ! Arm on external trigger input.
   40   OUTPUT @Dev;&quot;:ARM:TTL&quot;          ! Arm signal is TTL.
   50   OUTPUT @Dev;&quot;:ARM:EDGE NEG&quot;     ! Arm on negative edges.
   60   OUTPUT @Dev;&quot;:ARM:ECOUNT 2&quot;     ! Count two edges to arm.
   65   !
   70   OUTPUT @Dev;&quot;:TRIG:SOURCE INT&quot;  ! Trigger on input signal.
   80   OUTPUT @Dev;&quot;:TRIG:TTL&quot;         ! Trigger is TTL.
   90   OUTPUT @Dev;&quot;:TRIG:EDGE NEG&quot;    ! Trigger on negative edges.
   100  OUTPUT @Dev;&quot;:TRIG:ECOUNT 3&quot;    ! Count three edges to trigger.
   105  !
   110  OUTPUT @Dev;&quot;:INIT:IMM&quot;         ! Wait for trigger.
   115  !
   120  CALL Get_trace(@Dev,Data(*))    ! Get trace from device.
 </strong></pre>
<p>
The illustration below shows the operation of this trigger sequence:
</p>
<pre><strong>
          A             B
      +-------------------------------------------------------------+
      |       1         2                                           |
      |........    ......    ...................................... |
  EXT |       :    :    :    :                                      |
      |       :....:    :....:                                      |
      |                                                             |
      |     ......    ......    ......    ......    ......    ..... |
  INT |     :    :    :    :    :    :    :    :    :    :    :     |
      | ....:    :....:    :....:    :....:    :....:    :....:     |
      |                                                             |
      |                    1         2         3                    |
      +-------------------------------------------------------------+
                                               C          

    A: The :INITiate:IMMediate command begins the arming sequence.
    B: The arming conditions are satisfied (2 negative edges on D01).
    C: The trigger conditions are satisfied (3 negative edges after arm).
 </strong></pre>
<p>
Even more complicated triggering actions could be defined as needed.
</p>
<hr />
<h1><a name="ib6_m0">[6.0] HPIB Tutor (6):  A SCPI-Based HPIB Instrument -- The 34401 DMM</a></h1>
<p>
* This chapter illustrates the implementation of SCPI by showing how it is
implemented in a practical instrument, the popular 34401 digital multimeter
(DMM), known informally as the &quot;Alf&quot;.
</p>
<p>
Due to its relative simplicity and wide range of functionality, the Alf is an
excellent demonstration of a SCPI-based instrument.  This chapter will
outline the functionality of the DMM, describe its SCPI command set, and
provide short programming examples of its use.
</p>
<hr />
<ul>
<li>
<a href="#ib6_m1">[6.1] 34401 OVERVIEW</a>
</li>
<li>
<a href="#ib6_m2">[6.2] PROGRAMMING THE 34401</a>
</li>
<li>
<a href="#ib6_m3">[6.3] A SIMPLE 34401 EXAMPLE PROGRAM</a>
</li>
</ul>
<hr />
<p>
<a href="#top">BACK TO INDEX</a>
</p>
<h2><a name="ib6_m1">[6.1] 34401 OVERVIEW</a></h2>
<p>
* The 34401 DMM has the following measurement capabilities:
</p>
<ul>
<li> AC and DC volts, with a range from 0.1 to 1000 volts (750 volts AC).
</li>
<li> Resistance, with a range from 100 ohms to 100 megohms.
</li>
<li> AC and DC current, with a range from 10 milliamps (DC only) to 3 amps.
</li>
<li> Frequency and period, with ranges from 3 hertz to 300 kilohertz.
</li>
<li> Continuity and diode checking.
</li>
<li> Display resolution from 4.5 to 6.5 digits.
</li>
<li> Several math functions, and a capability to store 512 readings in memory.
</li>
<li> A menu-driven front-panel interface and a vacuum-fluorescent display.
</li>
 </ul>
<p>
Both HPIB and RS-232 interfaces are standard for remote programming and for
direct printer output.  The RS-232 output can be modified to provide a digital
pass-fail output.
</p>
<p>
The Alf features a SCPI-based command set (with some extensions for features
not included in the SCPI standard at the time the DMM was designed), plus the
ability to emulate the HP 3478A DMM or the Fluke 8840A/8842A DMM.
</p>
<p>
Note that the 34401 was described as having &quot;relative&quot; simplicity.  Due to
its wide range of capabilities, there is still a lot of detail to consider.
These capabilities are broken down into the following categories:
</p>
<ul>
<li> Measurement configuration.
</li>
<li> Math operations.
</li>
<li> Triggering.
</li>
<li> System-related operations.
</li>
<li> Remote interface configuration.
</li>
<li> Calibration.
</li>
<li> Power-on and reset state.
</li>
 </ul>
<p>
* The DMM's measurement configuration features include the following:
</p>
<ul>
<li> AC signal filter:  You can select one of three different AC input filters
   to optimize reading speed or low-frequency accuracy.  The slow filter
   takes 7 seconds to take a reading, the medium filter takes 1 second, and
   the fast filter takes a tenth of a second.
<p>
   The AC filter selection is stored in volatile memory.  The DMM defaults to
   the medium filter on power-on or *RST.  (Unless otherwise specified, all
   other settings and values are stored in volatile memory, and &quot;go away&quot; if
   you turn off the DMM.)
</p>
</li>
<li> Continuity threshold resistance:  When measuring continuity, the DMM emits
   a continuous tone if the measured resistance is less than a &quot;threshold
   resistance&quot;.  You can set the threshold to any value from 1 to 1000 ohms.
   The threshold resistance can only be set from the front panel.  It cannot
   be set programmatically.
</li>
<li> DC input resistance:  By default, the DMM's input resistance is fixed at
   10 megohms for all DC voltage ranges to minimize noise pickup.  To reduce
   the effects of measurement loading errors, you can set the input
   resistance to greater than 10 gigohms for the 100 millivolts DC, 1 volt
   DC, and 10 volts DC ranges.
</li>
<li> Resolution:  Resolution is expressed in terms of the number of digits the
   DMM can measure or display.  You can set the resolution to 4.5, 5.5, or
   6.5 digits.  Setting the DMM to 6.5 digits provides the greatest accuracy,
   while setting it to 4.5 digits provides the greatest measurement speed.
   The DMM defaults to 5.5 digits on power-on or *RST.
<p>
   The resolution is fixed at 4.5 digits for continuity and diode tests.  For
   AC measurements, the resolution is actually fixed at 6.5 digits, but it
   will be masked to the appropriate resolution setting.
</p>
<p>
   For DC and resistance measurements, changing the number of digits also
   changes the &quot;integration time&quot;, or the length of time the DMM takes to
   make a measurement.  The more digits, the more power-line cycles (PLCs)
   needed to establish the measurement.  The integration time can be set
   programmably.
</p>
</li>
<li> Front-rear input terminal switching:  The DMM has input terminals on both
   the front and the back, and you can make any measurement from either set of
   terminals.  Terminal switching can <em>only</em> be performed from the front
   panel buttons.  There is no way to do it programmatically.
</li>
<li> Autozero:  When autozero is enabled (the default), the DMM internally
   disconnects the input signal following each measurement, and takes a &quot;zero
   reading&quot;.  It then subtracts the zero reading from the preceding reading.
   This nulls out the effect of input offset voltages.
<p>
   If autozero is disabled, the DMM takes one zero reading and subtracts it
   from all following measurements.  It takes a new zero reading each time
   you change the function, range, or integration time.
</p>
</li>
<li> Ranging:  You can let the DMM select the range using autoranging or you
   can select a fixed range using manual ranging.  The range is fixed for
   continuity tests and diode tests.  For ratio measurements, the specified
   range applies to the signal connect to the INPUT terminals, and
   autoranging is automatically selected for reference voltage measurements
   on the SENSE terminals.  The DMM defaults to autoranging on power-on or
   *RST.
</li>
 </ul>
<p>
* There are five math operations, only one of which can be enabled at a time.
Each performs a mathematical operation on each reading, or stores data on a
series of readings.  The math operations use one or more internal registers,
while others hold the results of the math operation.
</p>
<p>
The table below shows the allowed math / measurement function combinations:
</p>
<pre><strong>
   ___________________________________________________

             Null    Min-Max    dB       dBm     Limit  
   ___________________________________________________

   DC V        X        X        X        X        X    
   AC V        X        X        X        X        X    
   DC I        X        X                          X    
   AC I        X        X                          X    
   OHMS 2W     X        X                          X    
   OHMS 4W     X        X                          X    
   FREQ        X        X                          X    
   PER         X        X                          X    
   CONT                                                 
   DIODE                                                
   RATIO                X                          X    
   ___________________________________________________
 </strong></pre>
<p>
Note that only one math operation can be set at a time; setting a new math
operation clears the previous one.  The operations are as follows:
</p>
<ul>
<li> The min-max operation stores the minimum and maximum readings during a
   series of measurements.  The DMM then calculates the average of all
   readings and records the number of readings taken since min-max was
   enabled.
</li>
<li> In null or relative measurements, each reading is the difference between a
   stored null value and the input signal.  The null value can be set to any
   value between 0 and +/-120% of the highest range for the present function.
   The null value can be set directly as a number from the front-panel or
   SCPI command, or it can be directly read in from a measurement.
</li>
<li> The DMM AC measurements can be made in dB as referenced to some stored
   reference value.  The reference value is defined in dBm, and can be set
   from any value between 0 dBm and +/-200 dBm.  The value can be set
   directly from the front panel or SCPI command -- or it can be directly
   entered from a measurement.
<p>
   The dBm operation calculates the power delivered by an AC signal to a
   resistance, referenced to 1 milliwatt.  You can choose from 17 different
   resistance values, from 50 to 8000 ohms, with the default being 600 ohms.
</p>
</li>
<li> The limit test operation allows you to perform pass/fail testing on upper
   and lower that you specify.  You can set the upper and lower limits to any
   value between 0 and +/-120% of the highest range for the present function.
   The upper limit should be a more positive number than the lower limit.
   The default limits are both 0.
<p>
   The DMM can be programmed to generate a service request on a failed
   reading.  There are also jumpers inside the DMM that allow you to use the
   DMM's serial port to output pass-fail indication signals; pin 1 will
   provide a low-going pulse (from 5 VDC to 0, for 2 milliseconds minimum) on
   a passed test, while pin 9 will provide a similar low-going pulse on a
   failed test.  (Note that setting this configuration means that the RS-232
   port can no longer be used for serial communications.)
</p>
<p>   
   You can set limits from the front panel either programmatically, or by
   making a measurement.
</p>
</li>
 </ul>
<p>
* The DMM's triggering system allows you to generate triggers manually or
automatically, take multiple readings per trigger, and insert a delay before
each reading.  Normally, the DMM takes one reading per trigger, but you can
specify multiple readings -- up to 50,000 -- per trigger.
</p>
<p>
You can trigger the DMM from the front panel using a single trigger, an
external trigger, or auto triggering.  Single triggering takes one reading
each time you press the &quot;Single&quot; button.  External triggering is like single
triggering, but the DMM waits for a pulse on the rear-panel EXTERNAL TRIGGER
BNC input before taking a reading.  Auto triggering takes continuous readings
at the fastest possible rate for the current configuration.
</p>
<p>
Setting up a trigger requires the following steps:
</p>
<ul>
<li> The DMM must be configured for a measurement by selecting the function,
   range, resolution, and so on.
</li>
<li> The trigger source must be selected:  either a software (HPIB) trigger, a
   hardware trigger from the EXTERNAL TRIGGER terminal, or an immediate
   internal trigger.
</li>
<li> Finally, the DMM must be placed into the &quot;wait for trigger&quot; state and wait
   for the trigger to come along.
</li>
 </ul>
<p>
The actions required to perform these steps are outlined below.
</p>
<ul>
<li> Trigger source choices:  The DMM can be configured from the front panel to
   accept a single pushbutton trigger, a hardware trigger from the EXTERNAL
   TRIGGER input, or continuously take readings using auto trigger.  Auto
   triggering is the default.  The DMM can be configured programmatically to
   accept a software trigger over the HPIB, a hardware trigger from the
   EXTERNAL TRIGGER, or an immediate internal trigger.
<p>
   Note that the EXTERNAL TRIGGER queues up one trigger input.  If a
   measurement is in progress and a trigger pulse comes in, that trigger
   pulse will initiate the next measurement immediately after the current one
   is completed.
</p>
<p>
   Software triggering is accomplished with the *TRG common command or the
   GET byte command.  The DMM must be configured to the wait-for-trigger
   state for these trigger commands to operate.
</p>
</li>
<li> Number of Samples:  By default, the DMM takes one reading each time it
   receives a trigger from the selected trigger source (if the DMM is in the
   wait-for-trigger state).  You can, however, instruct the DMM to take
   multiple readings for each trigger received.  The number of samples can
   range from 1 to 50,000, and can be set either from the front panel or
   programmatically.
</li>
<li> Number of Triggers:  By default, the DMM accepts only one trigger before
   taking a measurement and then returning to idle mode.  You can, however,
   instruct the DMM to accept multiple triggers before taking a reading.  The
   number of triggers can range from 1 to 50,000.  Note that it can only be
   set programmatically, there is no front-panel capability.
</li>
<li> Trigger Delay:  You can insert a delay between the trigger signal and each
   sample that follows.  This may be useful in a system where an output has a
   certain settling time.  The delay time can be set from 0 to 3600 seconds,
   and can be set either programmatically or from the front panel.  If you
   specify multiple readings on a trigger, the delay time applies to each
   measurement.
<p>
   The default delay time depends on the function, range, integration time,
   and AC filter setting of the DMM; refer to DMM documentation for details.
</p>
</li>
<li> Reading Hold:  This feature allows you to &quot;latch&quot; a reading and leave it
   on the display.  This is useful for troubleshooting systems where you
   cannot place the probes and see the DMM display at the same time.  This
   feature can only be set from the front panel.
</li>
<li> EXTERNAL TRIGGER &amp; VOLTMETER COMPLETE:  The triggering system interfaces
   to the outside world through two BNC connectors on the back panel.  The
   EXTERNAL TRIGGER connector triggers a reading (if configured to do so)
   when a low-true (5 VDC to 0) pulse occurs on that input.  The VOLTMETER
   COMPLETE terminal generates a similar low-true pulse when the reading is
   complete.
</li>
 </ul>
<p>
* System-related operations include such topics as reading memory, errors,
self-test, and display control:
</p>
<ul>
<li> Reading Memory:  The DMM can store up to 512 readings in an internal
   memory queue.  You can recall the readings to the display, or read buffered
   readings back programmatically.
</li>
<li> Error Conditions:  The DMM can queue up to 20 error codes in internal
   memory.  The error codes can be read back from the front panel or
   programmatically, and are read out as oldest-first.  If more than 20
   errors have occurred, the most recent is replaced with &quot;too many errors&quot;
   (error 350) error message, and no more errors will be stored until you
   remove some from the queue.
<p>
   If no errors have occurred when you read the error queue, the DMM responds
   with a &quot;no error&quot; (error 0) error message.
</p>
<p>
   The display error flag will not be cleared until all the errors have been
   read.  The error queue is cleared at power-on or *RST.
</p>
</li>
<li> Self-Test:  The DMM performs a power-on self-test that checks a minimum
   amount of the DMM's functionality.  A longer, more complete self-test
   (taking 15 seconds) can be initiated from the front panel or
   programmatically.  The self-test will clear readings memory, but otherwise
   the settings will not be disturbed.
</li>
<li> Display Control:  You can turn the front-panel display or off, either from
   the front panel or programmatically.  You can also programmatically
   display a message on the front panel.
</li>
<li> Beeper Control:  The DMM contains a speaker that will beep under certain
   conditions.  You can turn it off (for a subset of those conditions) and
   back on again, either from the front panel or programmatically.
</li>
<li> Comma separators:  You can set the DMM to display comma separators in long
   numbers.  This feature can only be set from the front panel.
</li>
<li> Firmware revision query:  The DMM has three microprocessors.  You can query
   the DMM, either from the front panel or programmatically, for the revision
   levels of their firmware.
</li>
<li> SCPI Language Version:  You can query the DMM programmatically to
   determine its SCPI revision level.
</li>
 </ul>
<p>
* You can set configuration operations for the DMM's remote programming
interface (HPIB or RS-232) from the front panel.  Of course it is impossible
to do it programmatically.  You can also select the DMM's command set.  (If
you are having troubles communicating with the DMM, you might check to see
what interface or language option is set.)
</p>
<p>
All these configuration settings are stored in non-volatile memory.  It will
be retained even if the DMM is switched off.
</p>
<ul>
<li> Remote interface selection:  You can select remote operation over either
   the HPIB or RS-232 port from the front panel.
</li>
<li> HPIB configuration:  You can set the DMM's address anywhere from 0 to 31.
   The factory-set default is 22.  If you set the address to 31, the DMM will
   be in talk-only mode, which will allow it to talk directly to a printer.
</li>
<li> RS-232 configuration:  You can select standard baud rates from 300 to 9600
   baud.  You can also set parity as &quot;None&quot; (8 data bits), &quot;Even&quot; (7 data
   bits), or &quot;Odd&quot; (7 data bits).  The factory preset is 9600 baud and even
   parity.
</li>
<li> Programming language selection:  You can select one of three command sets
   for the DMM:  SCPI (default), HP3478A, or Fluke 8840A.  Note that you can
   only perform remote interface programming over RS-232 with the SCPI
   language, since the other selections only support HPIB.
</li>
 </ul>
<p>
* The DMM allows you to lock out unauthorized calibrations, as well as obtain
a count of the number of times it has been calibrated or a message stored
during calibration.  Of course, this information is stored in nonvolatile
memory.
</p>
<ul>
<li> Calibration security:  This allows you to enter a security code to prevent
   accidental or unauthorized calibrations of the DMM.  It is set to secured
   at the factory, with the calibration code &quot;HP033401&quot;.
<p>
   You can set the security code programmatically or from the front panel.
   If you set it programmatically, it may consists of up to 12 alphanumeric
   characters, the first of which must be a letter.  If you set it from the
   front panel, the code consists of the characters &quot;HP&quot; plus 6 digits (all 8
   characters are required).
</p>
</li>
<li> Calibration count:  The number of times the DMM has been calibrated can be
   read from the front panel or over the remote programming interface.
</li>
<li> Calibration message:  You can store a string of up to 40 characters in the
   DMM to identify calibration information, such as the date of last
   calibration, due date of next calibration, and so on. 
</li>
 </ul>
<h2><a name="ib6_m2">[6.2] PROGRAMMING THE 34401</a></h2>
<p>
* The simplest way to obtain a reading from the DMM is via the MEASure?
command.  However, this command does not offer much flexibility, since the DMM
gives you the settings it thinks best for you and then makes the measurement.
Optional features, such as setting NULL operation, won't work.  
</p>
<p>
The only settings you can set are function, range, and resolution.  You can
set these as parameters to the MEASure?  command itself:
</p>
<pre><strong>
   MEASure:&lt;function&gt; &lt;range&gt;, &lt;resolution&gt;
 </strong></pre>
<p>
The relevant functions include:
</p>
<pre><strong>
   VOLTage:DC?               DC voltage.
   VOLTage:DC:RATio?         DC voltage ratio.
   VOLTage:AC?               AC voltage.
   CURRent:DC?               DC current.
   CURRent:AC?               AC current.
   RESistance?               Ohms.
   FRESistance?              4-wire ohms.
   FREQuency?                Frequency count.
   PERiod?                   Period.
   CONTinuity?               Continuity.
   DIODe?                    Diode test.
 </strong></pre>
<p>
For example:
</p>
<pre><strong>
   100 OUTPUT @Dmm;&quot;MEAS:VOLT:DC? 10,0.003&quot; ! DC, 10 V range, 3 mV resolution.
   110 ENTER @Dmm;Volts
 </strong></pre>
<p>
For more programming flexibility, use the CONFigure command.  This will also
preset the DMM to the settings it thinks best, but it won't take a reading;
if you want to change some of the settings you may do so, and then take a
reading with the READ? command.  
</p>
<p>
READ?  will arm the DMM into the wait-for-trigger state.  On triggering, the
DMM will obtain the reading and place it in the output buffer.
</p>
<p>
Note that if READ? is used, the output data will <em>not</em> be buffered in
internal memory.  You have to enter the readings as they arrive in the output
buffer or they are lost.  Note also that you can provide the same function,
range, and resolution parameters for CONFigure that you can with MEASure?
</p>
<p>
For example:
</p>
<pre><strong>
   100 OUTPUT @Dmm;&quot;CONF:VOLT:DC 10,0.003&quot; ! DC, 10 V range, 3 mV resolution.
   110 OUTPUT @Dmm;&quot;TRIG:SOUR EXT&quot;         ! Trigger on external source.
   120 OUTPUT @Dmm;&quot;READ?&quot;                 ! Wait for trigger and get value.
   130 ENTER @Dmm;Volts
 </strong></pre>
<p>
The INITiate and FETCh? commands provide the lowest level of control.  To
read the DMM, you configure it using other commands, and then put it in the
wait-for-trigger state with INITiate.  Once the DMM has triggered and taken
measurements, you can retrieve them with FETCh?; the readings are buffered in
internal memory, and FETCh? retrieves them one at a time.  
</p>
<p>
For example:
</p>
<pre><strong>

   100 OUTPUT @Dmm;&quot;CONF:VOLT:DC 10,0.003&quot; ! DC, 10 V range, 3 mV resolution.
   110 OUTPUT @Dmm;&quot;TRIG:SOUR EXT&quot;         ! Trigger on external source.
   120 OUTPUT @Dmm;&quot;INIT&quot;                  ! Wait for trigger.
   130 OUTPUT @Dmm;&quot;FETC?&quot;                 ! Get value.
   140 ENTER @Dmm;Volts
 </strong></pre>
<p>
This example uses the CONF command to set up the DMM.  You can also use the
FUNCtion, RANGe, and RESolution low-level configuration commands to perform
the precise setup you need:
</p>
<pre><strong>
   100 OUTPUT @Dmm;&quot;FUNC:VOLT:DC&quot;          ! DC volts.
   110 OUTPUT @Dmm;&quot;RANG 10&quot;               ! 10 V range.
   120 OUTPUT @Dmm;&quot;RES 0.003&quot;             ! 3 mV resolution.
   130 OUTPUT @Dmm;&quot;TRIG:SOUR EXT&quot;         ! Trigger on external source.
   140 OUTPUT @Dmm;&quot;INIT&quot;                  ! Wait for trigger.
   150 OUTPUT @Dmm;&quot;FETC?&quot;                 ! Get value.
   160 ENTER @Dmm;Volts
 </strong></pre>
<p>
There are a wide range of such low-level configuration commands, besides
FUNCtion, RANGe, and RESolution:
</p>
<pre><strong>
   NPLCycles              Set number of power-line cycles for a measurement.
   FREQuency:APERture     Set aperture gate time for period measurements.
   PERiod:APERture        Set aperture gate time for period measurements.
   DETector:BANDwidth     Set filter frequency for input signal.
   ZERO:AUTO              Enable or disable autozero mode.
   INPut:IMPedance:AUTO   Enable or disable auto input resistance mode.
 </strong></pre>
<p>
Each of these commands has a matching query.  There is also a query,
ROUTe:TERMinals?, to determine if the front or back input terminals are
enabled.
</p>
<p>
* The five math operations are set as follows:
</p>
<pre><strong>
   CALCulate:FUNCtion NULL (default)
   CALCulate:FUNCtion DB
   CALCulate:FUNCtion DBM
   CALCulate:FUNCtion AVERage
   CALCulate:FUNCtion LIMit
 </strong></pre>
<p>
You can query the function setting with the CALCulate;FUNCtion? query.  Once
the function has been set, you then have to enable it to get it to operate:
</p>
<pre><strong>
   CALCulate:STATe ON
 </strong></pre>
<p>
You can disable the math using the OFF parameter instead of the ON parameter.
You can interrogate the state with a CALCulate:STATe? query.
</p>
<p>
You set the parameters for the math operations with the commands listed
below.  Note that the appropriate operation must be set before setting the
parameters:
</p>
<pre><strong>
   CALCulate:NULL:OFFSet
   CALCulate:DB:REFerence
   CALCulate:DBM:REFerence
   CALCulate:LIMit:LOWer
   CALCulate:LIMit:UPPer
 </strong></pre>
<p>
You can interrogate one of these values from the DMM with the matching query.
Finally, you can determine the results for those math operations that return
them with:
</p>
<pre><strong>
   CALCulate:AVERage:MINimum?   Gives minimum of min-max operation.
   CALCulate:AVERage:MAXimum?   Gives maximum of min-max operation.
   CALCulate:AVERage:AVERage?   Gives average of min-max operation.
   CALCulate:AVERage:COUNt?     Gives number of values in min-max operation.
 </strong></pre>
<p>
The following sample program shows how to use the CONFigure command with a
dBm math operation:
</p>
<pre><strong>
   10  DIM Ohms(1:5)
   20  ASSIGN @Dmm TO 722
   30  CLEAR 7                            ! Clear HPIB and DMM.
   40  OUTPUT @Dmm;&quot;*RST;*CLS&quot;            ! Reset DMM.
   60  OUTPUT @Dmm;&quot;CALC:DBM:REF 5.0&quot;     ! 50 ohm reference resistance.
   70  OUTPUT @Dmm;&quot;CONF:VOLT:AC 1,0.001&quot; ! Set DMM to 1 amp AC range.
   80  OUTPUT @Dmm;&quot;DET:BAND 200&quot;         ! Select 200 Hz (fast) AC filter.
   90  OUTPUT @Dmm;&quot;TRIG:COUN 5&quot;          ! DMM will accept 5 triggers.
   100 OUTPUT @Dmm;&quot;TRIG:SOUR IMM&quot;        ! Trigger source is IMMediate.
   110 OUTPUT @Dmm;&quot;CALC:FUNC DBM&quot;        ! Select dBm function.
   120 OUTPUT @Dmm;&quot;CALC:STAT ON&quot;         ! Enable math.
   130 OUTPUT @Dmm;&quot;READ?&quot;                ! Get readings, put in output buffer.
   140 ENTER @Dmm; Ohms(*)
   150 PRINT USING &quot;K,1&quot;; Ohms(*)
   160 END
 </strong></pre>
<p>
* The DMM's triggering capabilities were outlined in the last section.  You
can generate triggers either manually or automatically, take multiple
readings per trigger (up to 50,000), and insert a delay before each reading.
To trigger the DMM, you must perform the following steps:
</p>
<ul>
<li> You must configure the DMM for the measurement by selecting the function,
   range, resolution, and so on.
</li>
<li> Then you must select the trigger source:  command trigger (GET or *TRG),
   EXTERNAL TRIGGER input, or an immediate internal trigger.
</li>
<li> Then you must make sure that the DMM is ready to accept a trigger by being
   placed in the wait-for-trigger state.  A trigger will not be accepted until
   the DMM is in this state.
</li>
 </ul>
<p>
The triggering system is controlled by the following commands:
</p>
<pre><strong>
   INITiate              Set DMM to wait-for-trigger state.
   FETCh?                Get reading from DMM.
   READ?                 Set DMM to wait-for-trigger state, get readings.
   TRIGger:SOURce        Set trigger source.
   TRIGger:DELay         Set trigger delay.
   TRIGger:DELay:AUTO    Enable or disable automatic trigger delay.
   SAMPLe:COUNt          Set number of readings per trigger.
   TRIGger:COUNt         Set number of triggers per reading.
 </strong></pre>
<p>
Note that all these commands except INITiate and READ? have matching
queries.  Note also that FETCh?, unlike READ, actually doesn't perform any
triggering action, but it is closely related to INITiate, and so is included
with the triggering commands.
</p>
<p>
* The DMM's system-related commands cover a grab-bag of functions, such as
display control, beeper control, queries for DMM errors and status, and reset
and self-test commands.  They include:
</p>
<pre><strong>
   DISPlay               Turn the DMM display on or off.
   DISPlay?              Query the display state.
   DISPlay:TEXT          Display up to 12 characters on the DMM display.
   DISPlay:TEXT?         Query the display text.
   DISPlay:TEXT:CLEar    Clear the message displayed on the front panel.
   SYSTem:BEEPer         Issue a single beep immediately.
   SYSTem:BEEPer:STATe   Disable or enable a front-panel beeper.
   SYSTem:BEEPer:STATe?  Query beeper state.
   SYSTem:ERRor?         Query the DMM's error queue.
   SYSTem:VERsion?       Query the DMM for SCPI version.
   DATA:POINts?          Query the number of readings in the DMM.
   *RST                  Reset the DMM.
   *TST?                 Self-test the DMM.
   *IDN?                 Get DMM ID.
 </strong></pre>
<p>
* The DMM's status subsystem was discussed in the last chapter.  It includes
the 488.2 Status Byte and Standard Event register, plus the SCPI questionable
data register.
</p>
<p>
The Status Byte implements four status bits, as listed below.  Note that the
lowest bit is BIT 0, and that each bit is accompanied by its decimal weight:
</p>
<ul>
<li> BIT 3 (8) -- Questionable Data:  Indicates a bit set in the Questionable
   Data register.
</li>
<li> BIT 4 (16) -- Message Available:  Indicates data available in the output
   queue.
</li>
<li> BIT 5 (32) -- Standard Event:  Indicates a bit set in the Standard Event
   register.
</li>
<li> BIT 6 (64) -- Request Service:  Indicates that the DMM has requested
   service.
</li>
 </ul>
<p>
The Status Byte is read during a controller serial poll.  If the DMM has
asserted SRQ, this clears the SRQ and BIT 6.  It can also be read with the
STB?  query.  In this case BIT 6 will remain set until it is cleared with a
*CLS command.
</p>
<p>
The Status Byte enable register can be set with the *SRE command and read
with the *SRE?  query; a set bit will cause an SRQ.  The enable register can
only be cleared by sending *SRE 0 or by power-cycling, and even with
power-cycling, the DMM must have been configured to clear that enable
register with the *PSC 1 command before power-down.  If *PSC 0 has been sent
instead, the enable settings will be retained.
</p>
<p>
* The Standard Event register implements six status bits:
</p>
<ul>
<li> BIT 0 (1) -- Operation Complete:  Indicates that all commands prior to and
   including a *OPC command have been executed.
</li>
<li> BIT 2 (4) -- Query Error:  Indicates that the DMM tried to read an empty
   output buffer; that a new command line has been sent before a previous
   query has been sent; or that both the input and output buffers are full.
</li>
<li> BIT 3 (8) -- Device Error:  Indicates that a self-test, calibration, or
   reading overload error occurred.
</li>
<li> BIT 4 (16) -- Execution Error:  Indicates that a command execution error
   has occurred.
</li>
<li> BIT 5 (32) -- Command Error:  Indicates a syntax error in a command string
   sent to the DMM.
</li>
<li> BIT 7 (128) -- Power On:  Indicates that power has been turn on and the
   event register has not yet been read or cleared.
</li>
 </ul>
<p>
The Standard Event register can be read with the *ESR?  query.  Note that
this register cannot be written to.  The Standard Event enable register is
written to with the *ESE command and read with the *ESE?  query, and bits set
will cause an SRQ, as long as BIT 5 in the Status Byte Enable register is
set.
</p>
<p>
Sending an *ESR? clears the Standard Event register.  It is also cleared by
the *CLS command.  Similarly to the Status Byte enable register, the Standard
Event enable register can only be cleared with *ESE 0 or by power-cycling (as
long as *PSC 1 has been sent before power-down).
</p>
<p>
The Operation Complete flag in this register is particularly handy.  Using
this flag, the controller can initiate a long DMM operation, and then go do
something else until the operation completes.  When the DMM is done, it will
assert an SRQ and interrupt the controller.  The controller has to go through
the following sequence of steps to implement this scheme:
</p>
<pre><strong>
   100 CLEAR @Dmm                      ! Clear DMM interface.
   110 OUTPUT @Dmm;&quot;*CLS&quot;              ! Clear DMM status registers.
   120 OUTPUT @Dmm;&quot;*ESE 1&quot;            ! Enable OPC event.
   130 OUTPUT @Dmm;&quot;*SRE 32&quot;           ! Enable SRQ on OPC event.
   140 OUTPUT @Dmm;&quot;*OPC?&quot;             ! Send dummy *OPC? to ensure synch.
   150 ENTER @Dmm;Dummy                ! Read back dummy value.
   160 ON INTR 7 GOSUB Handler         ! Set jump to handler routine on SRQ.
   170 ENABLE INTR 7;1                 ! Enable SRQ interrupt for controller.
   180 OUTPUT @DMM;&quot;&lt;command&gt;; *OPC?&quot;  ! Send command, followed by *OPC?.
 </strong></pre>
<p>
The controller will go on and do other things; when the operation is
complete, the DMM will assert an SRQ and cause a jump to the interrupt
handler.
</p>
<p>
* The Questionable Data register implements five status bits:
</p>
<ul>
<li> BIT 0 (1) -- Voltage Overload:  Indicates overrange on DC volts, AC volts,
   frequency, period, diode, or ratio function.
</li>
<li> BIT 1 (2) -- Current Overload:  Indicates overrange on DC or AC current
   function.
</li>
<li> BIT 9 (512) -- Ohms Overload:  Indicates overrange on 2-wire or 4-wire
   ohms test.
</li>
<li> BIT 11 (2048) -- Limit Test Fail LO:  Indicates that reading has gone
   below the lower limit in the limit test.
</li>
<li> BIT 12 (4096) -- Limit Test Fail HI:  Indicates that reading has gone
   above the upper limit in the limit test.
</li>
 </ul>
<p>
You can read the Questionable Data register with the STATus:QUEStionable:
EVENT? query.  This action clears the register.  *CLS also clears this
register.
</p>
<p>
The Questionable Data enable register is set with the STATus:QUEStionable:
ENABle command.  It can be read with the STATus:QUESTionable:ENABle? query.
Bits set will cause an SRQ, as long as BIT 5 in the Status Byte Enable
register is set.  This enable register is <em>always</em> cleared by power-up. 
It can also be cleared by the STATus:PREset command or by setting it to 0 with
STATus:QUEStionable:  ENABle 0.
</p>
<p>
* The calibration commands allow you to perform a calibration of the DMM,
determine how many times the DMM has been calibrated, set and query
calibration codes, and set and query calibration information.  The
calibration commands include:
</p>
<pre><strong>
   CALibration?                Perform a calibration.
   CALibration:COUNt?          Get number of calibrations.
   CALibration:SECure:CODE     Set calibration security code.
   CALibration:SECure:STATe    Unsecure or secure for calibration.
   CALibration:SECure:STATe?   Query security state.
   CALibration:STRing          Store calibration data.
   CALibration:STRing?         Read calibration data.
   CALibration:VALue           Set value of calibration reference.
   CALibration:VALue?          Read value of calibration reference.
 </strong></pre>
<p>
* Finally, to complete the command set, there are three RS-232-only
(non-SCPI) commands that perform functions that are inherent to HPIB but not
to RS-232:
</p>
<pre><strong>
   SYSTem:LOCal                Put DMM into local state.
   SYSTem:REMote               Put DMM into remote operation.
   SYSTem:RWLock               Put DMM into local lockout.
 </strong></pre>
<p>
Note that you will not get RS-232 communications to work properly unless
you send a SYSTem:REMote command after reset. <em>not</em> 
</p>
<p>
* Error codes are not explained in this document, since a description of the
error accompanies the error code returned by the instrument.
</p>
<h2><a name="ib6_m3">[6.3] A SIMPLE 34401 EXAMPLE PROGRAM</a></h2>
<p>
* The following HP BASIC example program demonstrates elementary programming
techniques for the 34401.  It uses a simple text-input menu system to allow
you to read AC or DC volts or current, resistance, and frequency, perform
test and status operations on the DMM, and clear the display and exit the
program.  A practical program would be more sophisticated, but this is, after
all, an example.
</p>
<pre><strong>
   10    DIM S$[100],P$[100],M$[5],R$[5] ! String, prompt, mode, reply vars.
   20    REAL T                          ! Used for timeout tracking.
   30    INTEGER Sts                     ! Stores serial poll result.
   40    CLEAR SCREEN
   50    !
   60    ON TIMEOUT 7,3 GOSUB Timetrap   ! Set up timeout trap.
   70    ASSIGN @Dmm TO 722              ! Open path to DMM.
   80    ON ERROR GOSUB Errtrap          ! Set up error trap.
   90    !
   100   M$=&quot;DC&quot;                         ! Define DC or AC operations.
   110   LOOP
   120     P$=&quot;COMMAND:  (M)ode=&quot;&amp;M$&amp; / (V)olts / (A)mps&quot;
   130     DISP P$&amp;&quot; / (O)hms / (F)req / (C)ls / (S)ystem / (Q)uit&quot;;
   140     INPUT R$                      ! Get reply to prompt.
   150     IF R$=&quot;&quot; THEN R$=&quot;Z&quot;          ! Check for empty input.
   160     R$=UPC$(R$[1,1])              ! Get first character as uppercase.
   170   ! 
   180     SELECT R$                     ! Test character:
   190   ! 
   200     CASE &quot;M&quot;                      ! Mode:  Toggle mode between DC &amp; AC.
   210       IF M$=&quot;DC&quot; THEN
   220         M$=&quot;AC&quot;
   230       ELSE
   240         M$=&quot;DC&quot;
   250       END IF
   260   !   
   270     CASE &quot;V&quot;                      ! Volts:  Get AC or DC volts.
   280       DISP &quot;Getting volts ... &quot;
   290       IF M$=&quot;DC&quot; THEN
   300         OUTPUT @Dmm;&quot;MEAS:VOLT:DC?&quot;
   310       ELSE
   320         OUTPUT @Dmm;&quot;MEAS:VOLT:AC?&quot;
   330       END IF
   340       ENTER @Dmm;S$
   350       PRINT &quot;Voltage value:    &quot;;S$
   360   !   
   370     CASE &quot;A&quot;                      ! Amps:  Get AC or DC amps.
   380       DISP &quot;Getting amps ... &quot;
   390       IF M$=&quot;DC&quot; THEN
   400         OUTPUT @Dmm;&quot;MEAS:CURR:DC?&quot;
   410       ELSE
   420         OUTPUT @Dmm;&quot;MEAS:CURR:AC?&quot;
   430       END IF
   440       ENTER @Dmm;S$
   450       PRINT &quot;Current value:    &quot;;S$
   460   !   
   470     CASE &quot;O&quot;                      ! Ohms:  Get 2-wire resistance.
   480       DISP &quot;Getting resistance ... &quot;
   490       OUTPUT @Dmm;&quot;MEAS:RES?&quot;
   500       ENTER @Dmm;S$
   510       PRINT &quot;Ohms value:       &quot;;S$
   520   !   
   530     CASE &quot;F&quot;                      ! Freq:  Get frequency.
   540       DISP &quot;Getting frequency ... &quot;
   550       OUTPUT @Dmm;&quot;MEAS:FREQ?&quot;
   560       ENTER @Dmm;S$
   570       PRINT &quot;Frequency value:  &quot;;S$
   580   !
   590     CASE &quot;C&quot;                      ! Cls:  Clear display.
   600       CLEAR SCREEN
   610   !
   620     CASE &quot;S&quot;                      ! System:  Do system functions.
   630       GOSUB System
   640   !
   650     CASE &quot;Q&quot;                      ! Quit program.
   660       DISP &quot;Done!&quot;
   670       STOP
   680   !
   690     CASE ELSE                     ! Bogus input.
   700       INPUT &quot;ERROR:  Bad command.  Press enter to continue.&quot;,R$
   710   !
   720     END SELECT
   730   END LOOP
   740   !
   750 System: !                           Perform system commands.
   760   LOOP
   770     INPUT &quot;COMMAND:  (C)lear / (I)d / (T)est / (E)rror / (R)eturn&quot;,R$
   780     IF R$=&quot;&quot; THEN R$=&quot;Z&quot;          ! Test for empty input.
   790     R$=UPC$(R$[1,1])              ! Get first character as uppercase.
   800   !
   810     SELECT R$                     ! Test character:
   820   !
   830     CASE &quot;C&quot;                      ! Clear DMM.
   840       DISP &quot;Clearing DMM ... &quot;
   850       CLEAR @Dmm
   860       OUTPUT @Dmm;&quot;*RST;*CLS&quot;
   870       PRINT &quot;Reset complete!&quot;
   880   !  
   890     CASE &quot;I&quot;                      ! Get ID string.
   900       DISP &quot;Getting ID ... &quot;
   910       OUTPUT @Dmm;&quot;*IDN?&quot;
   920       ENTER @Dmm;S$
   930       PRINT &quot;Dmm ID string: &quot;;S$
   940   !  
   950     CASE &quot;T&quot;                      ! Self-test DMM.
   960       DISP &quot;Testing ... &quot;
   970       OUTPUT @Dmm;&quot;*CLS;*ESE 1;*OPC?&quot; ! Flag OPC when test over.
   980       ENTER @Dmm;S$
   990       OUTPUT @Dmm;&quot;*TST?;*OPC&quot;    ! Test, flag OPC.
   1000      T=TIMEDATE                  ! Get initial time.
   1010      LOOP
   1020        Sts=SPOLL(@Dmm)           ! Spoll for ESB (=OPC) bit.
   1030      EXIT IF BIT(Sts,5)=1
   1040      EXIT IF TIMEDATE-T&gt;30       ! Keep checking for 30 seconds.
   1050      END LOOP
   1060      IF BIT(Sts,5)=1 THEN     
   1070        ENTER @Dmm;S$
   1080        PRINT &quot;Test status: &quot;;S$
   1090      ELSE
   1100        PRINT &quot;Test timed out!&quot;
   1110      END IF
   1120  !  
   1130    CASE &quot;E&quot;                      ! Get error status.
   1140      DISP &quot;Getting error status ... &quot;
   1150      OUTPUT @Dmm;&quot;SYST:ERR?&quot;
   1160      ENTER @Dmm;S$
   1170      PRINT &quot;Error status: &quot;;S$
   1180  !
   1190    CASE &quot;R&quot;                      ! Return to main.
   1200      RETURN
   1210  !  
   1220    CASE ELSE                     ! Bogus input.
   1230      INPUT &quot;ERROR:  Bad command.  Press enter to continue.&quot;,R$
   1240  !  
   1250    END SELECT
   1260  !
   1270  END LOOP
   1280  RETURN
   1290  !
   1300 Timetrap: !                        Trap timeout error.
   1310  INPUT &quot;ERROR:  Timeout -- press Enter to continue.&quot;,R$
   1320  ERROR RETURN
   1330  !
   1340 Errtrap: !                         Trap error.
   1350  PRINT ERRM$                     ! Print error string.
   1360  INPUT &quot;ERROR:  Press Enter to continue.&quot;,R$
   1370  ERROR RETURN
   1380  !
   1390  END
 </strong></pre>
<hr />
<h1><a name="ib7_m0">[7.0] HPIB Tutor (7):  Notes &amp; Comments</a></h1>
<p>
* This last chapter covers a few interesting topics in HPIB not easily
discussed elsewhere.
</p>
<hr />
<ul>
<li>
<a href="#ib7_m1">[7.1] BENCHMARKS</a>
</li>
<li>
<a href="#ib7_m2">[7.2] PASS CONTROL &amp; NON-CONTROLLER OPERATION</a>
</li>
</ul>
<hr />
<p>
<a href="#top">BACK TO INDEX</a>
</p>
<h2><a name="ib7_m1">[7.1] BENCHMARKS</a></h2>
<p>
* There is an old saying that there are lies, damn lies, and statistics, to
which a modern wit added &quot;damn statistics&quot; (&quot;four out of five doctors
recommend&quot;), then &quot;benchmarks&quot;.  To this I add:  &quot;damn benchmarks&quot;.
</p>
<p>
Benchmarking is a confusing topic where one is given a very specific value
whose <em>real</em> relationship to what he or she actually wants to know is no
more than an approximation, subject to a number of conditions.
</p>
<p>
This is, as shall be explained, inevitable, so the important question is one
of what constitutes &quot;benchmarks&quot; (honestly-stated information) and what
constitutes &quot;damn benchmarks&quot; (meaningless hype), and how one can tell the
difference.
</p>
<p>
* In the case of HPIB, there are a lot of benchmarks and damn benchmarks out
there.  Customers often want to get estimates for the performance (in
kilobytes per second) they can expect to obtain for an HPIB application with
a specific HPIB card.  There are two types of benchmarks that need to be
provided in response:  &quot;typical&quot; performance figures, and &quot;maximum&quot;
performance figures.
</p>
<p>
Typical performance figures are usually obtained by setting up the PC and a
low-cost instrument (the HP 34401 &quot;Alf&quot; DMM is currently popular for this
task) and then simulating a typical customer application.
</p>
<p>
This sounds simple enough, and it is, but the complexity comes in considering
what information you're getting out of it.  The performance of the system
will depend on four factors:
</p>
<ul>
<li> The speed of the PC running the test.  The simplest way of judging a PC's
   speed is the clock speed of the processor, but this can be highly
   misleading, since it doesn't take into consideration the fact that the
   processor may have a 16-bit or 32-bit data path width, different speeds of
   RAM, different amounts and speeds of cache -- and, more importantly, such
   overall system considerations as display graphics speed, hard disk speed,
   and whether DOS or Windows is running the test.  (There are utilities
   available to give a figure of merit of overall PC performance, but their
   results are highly dependent on the assumptions used in their design.)
</li>
<li> The assumptions used in writing the program to make the test, as well as
   the language used -- C or BASIC or whatever -- used to write the program.
   An unrealistic example program would simply send a command and read a
   value over and over again.  A realistic example program would update a
   graphics display, store the data returned in a file, and do error and
   status checking, emulating a simple data-logging application.
</li>
<li> The type of HPIB card used in the PC.  As will be discussed momentarily,
   this is the least important consideration in this type of benchmark.
</li>
<li> The speed at which the instrument can communicate.  This is a <em>very</em>
   important consideration.  HPIB is designed so that one device cannot talk
   faster than another device can listen (which is not true for, say,
   people), and of course one device cannot listen faster than the other
   talks (which is true for people and everything else, as imposed by simple
   logic).
<p>
   Note that many benchmark requests are for performance of HPIB with a
   specific instrument.  However, in this document the issue is deriving
   general performance figures for the PC's HPIB card, and instrument
   performance, though important in itself, will not be considered further
   here.
</p>
</li>
 </ul>
<p>
In practice, such a typical benchmark says almost nothing about the
performance of an HPIB card, since almost any HPIB card you could buy would
be able to keep up with the actions of the system.  The speed will be far more
determined by the PC and the design of the program, since the data
transactions over HPIB are a small part of the total.  The typical benchmark
is useful in that it provides a minimum value that the user can expect to
obtain.
</p>
<p>
* The maximum performance benchmark is where things get more interesting.  In
this case, the benchmark is optimized for the maximum possible performance to
provide an upper limit on HPIB card operation.
</p>
<p>
The four constraints outlined for the typical benchmark above apply in the
maximum performance benchmark case as well, but with added subtleties:
</p>
<ul>
<li> PC operation speed is optimized.  This means going into the PC's
   configuration files and eliminating anything that might hinder the
   benchmark's performance, and tweaking anything left that could be tweaked
   that could enhance it by, say, freeing up as much memory as possible.
   Hard disk drives will be defragmented, disk cache sizes will be increased,
   and compressed drives will not be used for the test (since the data
   compression algorithm will slow down data storage as compared to an
   uncompressed disk).
<p>
   PC configurations can vary enough so that even the same model of PC with
   the same options can give surprisingly different results.
</p>
</li>
<li> The program itself will be optimized for raw speed.  To this end, the
   program will be written strictly to obtain data from the instrument using
   the fastest possible instrument operation mode -- and in <em>as large blocks
   of data as possible</em>.  It will do <em>absolutely nothing else</em>.
<p>
   This is not deceptive, since this particular benchmark is intended to
   determined maximum sustained performance, an important specification for
   many practical applications.  For typical HPIB operation involving many
   small transfers of commands and data, this spec says very little.  A
   Lamborghini is a fast car, but if it's caught in city traffic it can't go
   any faster than any other car.
</p>
<p>
   HPIB communications tend to increase greatly in speed as the block size of
   a single transfer operation increases in length.  This is because telling
   an instrument to do something requires sending a few commands, providing a
   certain overhead for the transaction, and each individual HPIB operation
   invoked by the program has a certain overhead as well.  If you have one
   very long transfer of data in a single HPIB operation, then as the
   transaction gets longer, the overhead time becomes more negligible in
   comparison.
</p>
<p>
   The assumptions of the program's design are important again, though what
   constitutes &quot;realistic&quot; and &quot;unrealistic&quot; in this case are a little more
   evasive.
</p>
<p>
   First, there is the question of whether the instrument is being instructed
   to perform a realistic operation, or is simply being told to return data
   even though it cannot realistically obtain data at that rate.  This is
   usually not much of a worry if the person making the benchmark has a good
   grasp of the instrument.
</p>
<p>
   Second, and more important, are the issues of what is done with the data
   when it is returned, and how much is returned.  The fastest benchmarks
   will throw away the data returned from the instrument, which is entirely
   unrealistic.  More realistic benchmarks will store it in memory, and a
   better benchmark will store it to hard disk.  (It is not practical in most
   cases to manipulate data as it is coming in if speed is desired, so data
   has to be stored and manipulated later.)
</p>
<p>
   The amount of data affects the benchmark as well, since simply getting
   back a one-second burst of data will give, in general, faster rates than
   getting back the data over a period of several minutes.  If the data is
   stored to disk, the amount is important as well, because once disk cache
   is filled up the speed of disk access changes abruptly.  If you don't get
   close to that limit, you won't have a realistic assessment of the impact
   of hard disk speed since the data is <em>really</em> being stored in RAM.
</p>
<p>
   Note that in some applications a customer may simply want to get a short
   burst of data and put it in memory, rather than store data on disk for
   several minutes, and the short-burst-to-memory benchmark -- usually about
   twice as fast as a sustained transfer to disk -- may be precisely what is
   desired.
</p>
</li>
<li> The HPIB card's speed is important in a maximum-performance benchmark

   since it now becomes the bottleneck, and the card itself isn't all there
   is to it any more.  The configuration of the HPIB connections made in the
   benchmark system also becomes important, since HPIB transfers slow down
   perceptibly when more and longer cables are added to the system, analogous
   to the fact that filling up pipes from a pump becomes slower when you have
   more and longer pipes to fill.
<p>
   For maximum performance, it is a reasonable assumption to insist on a
   single short cable to the instrument, since if the user wants to obtain
   maximum speed in practice that will be required.
</p>
<p>
   The use of short connections also allows further optimizations, since many
   HPIB cards can be reprogrammed to use faster bus timing that isn't
   realistic in other circumstances.  Again, this isn't deceptive if a
   maximum performance figure is desired, but such optimizations are
   inapplicable for typical operation.
</p>
</li>
<li> The speed of the instrument also becomes a major factor for maximum

   performance benchmarks; there are relatively few instruments that can
   operate above, say, 250 kilobytes per second, and most are below 100
   kilobytes per second -- the PC's HPIB card is often faster and so is just
   waiting on the instrument.
<p>
   Some benchmarks are performed using dummy devices.  I often use a second
   computer with an HPIB card as a dummy device, which is in practice pretty
   realistic, but sometimes specialized hardware is used to determine maximum
   HPIB card transfer rates.  This is unrealistic, except for determining the
   absolute theoretical limit of the card's operation.  The card will never
   come close to that rate in practical operation.
</p>
</li>
 </ul>
<p>
The maximum-performance benchmark actually does reveal true facts about the
HPIB card, but it is made under constrained and specific circumstances, and
except in providing an upper limit, only gives specific information when the
test conditions are fully known.
</p>
<p>
Note that some vendors are promoting HPIB card with supposed
enhanced-performance features.  The catch is that such enhanced performance
is only available under specialized circumstances (as above) and with
instruments that also support the same enhanced-performance spec, and which
are few in number these days.  There is a need for a faster instrument
interface than HPIB, but it will probably be derived from new high-speed
serial buses and the like currently being implemented on PCs.
</p>
<p>
* In summary, when you ask for benchmark figures, you will need to know what
you are asking for and what you can expect.  What most users want to know is:
&quot;How fast can my application run?&quot;  Without implementing the application,
nobody can say.  All that can be done is give an estimate of limits and
constraints.
</p>
<p>
Realistic benchmarks will provide both typical and maximum performance
figures, with an outline of what the benchmark programs do and the necessary
details, such as the type and configuration of PC, the programming language
used, the instrument used in the test, and so on.  Any reasonable benchmark
will also clearly state that there is no guarantee that a specific
application will obtain the same figures, since the specific performance only
relates to the benchmark test itself.
</p>
<p>
In marketing copy, it is hard to point out these details, so you should
assume that if you are given a performance figure without comment it is a
maximum figure and obtained under optimum circumstances.  Really impressive
performance figures (some vendors quote a &quot;megabyte per second&quot;, which is the
theoretical limit to HPIB transfer rates) should be regarded with suspicion
as &quot;damn benchmarks&quot; since they were probably put together using unrealistic
assumptions.
</p>
<p>
In practice, actual performance is a system issue, and will be determined by
the user's knowledge of all system elements -- PC configuration, program
design, HPIB optimization, and instrument operation.  A fast HPIB card counts
for very little if the application is dumping data to a bottleneck like a
tape drive.  But having realistic benchmarks for any one element will tell
you what is, and what is not, possible.
</p>
<h2><a name="ib7_m2">[7.2] PASS CONTROL &amp; NON-CONTROLLER OPERATION</a></h2>
<p>
* Some HPIB programmers attempt to write programs that assume non-controller
operation.  They want to either temporarily pass control to another
controller, or operate as a pure slave (talk-listen-but-not-control) device
They find they run into difficulties.
</p>
<p>
While passing control is straightforward, it does require a good
understanding of how the HPIB protocols (and the interface library that
implements them) work.  However, operation as a slave is much trickier and
very difficult to implement in a reliable fashion.
</p>
<p>
This problem is compounded by the fact that many interface libraries
implement pass-control or slave-operation features in a slipshod fashion, and
often have not tested what they have implemented in any methodical way.  For
these reasons, it is strongly recommended that passing control not be done
unless there is no other way to do the required task, and that slave
operation be avoided if at all possible.
</p>
<p>
Nonetheless, if you are forced to deal with these matters, hear are some
clues and hints.  Since HP BASIC for stand-alone workstations has the most
robust HPIB implmentation I know of, the discussion is purely based on HP
BASIC commands.  You will need to find analogous commands on your target
system, though it is likely the implementation will not be anywhere near as
good.
</p>
<p>
The following discussion necessarily repeats information provided in a more
terse fashion in earlier chapters for the sake of coherence.
</p>
<p>
* If you have multiple controllers on the same HPIB, one will be the system
controller and all the others will be non-system controllers.  On traditional
HP BASIC workstations, this is set with a DIP switch.  
</p>
<p>
The first visible distinction between the two is this:  when you power up the
controllers, the system controller will come up by default operating as a
controller -- that is, you will be able to communicate with instruments --
while the non-system controllers will be operating by default as slaves --
that is, they will not be able to address any devices on the HPIB.
</p>
<p>
This means that if you perform:
</p>
<pre><strong>
   OUTPUT 705;&quot;*IDN?&quot;
 </strong></pre>
<p>
-- on the system controller, it will work fine (assuming that there is a
device with address 705 out there on the HPIB), but if you do it with a
non-system controller, you'll get an error message:
</p>
<pre><strong>
   ERROR 173  Active/system controller req'd
 </strong></pre>
<p>
Some users set up a non-system controller, get this error message, and think
it's a bug.  No, it's doing what it's supposed to be doing.
</p>
<p>
Now suppose you put these two controllers on the same HPIB and wish to pass
control between them.  The first issue is one which is often forgotten by
HPIB users:  that a controller has an HPIB address, just like an instrument
(the default controller address for an RMB workstation is 21), and you
can't have two devices on the bus with the exact same address.
</p>
<p>
Fortunately, you can set a controller to another HPIB address by writing to
HPIB status register 3:
</p>
<pre><strong>
   CONTROL 7,3;1   ! Set interface 7 to HPIB address 1.
 </strong></pre>
<p>
I assume the HPIB is at interface select code 7, a convention that I will
stick with in the rest of the discussion.  I usually prefer to set the
non-system controller to address 1 and leave the system controller to address
21.
</p>
<p>
Given this knowledge, it is perfectly easy to pass control from the system 
controller to the non-system controller with:
</p>
<pre><strong>
   PASS CONTROL 701    ! Sends TCT (Take ConTrol) byte.
 </strong></pre>
<p>
The non-system controller can then pass it back with:
</p>
<pre><strong>
   PASS CONTROL 721
 </strong></pre>
<p>
* Seems pretty simple, right?  Well, it is simple, but not quite that
simple.  There's a few other details to consider. <em>that</em>
</p>
<p>
The first detail can be phrased as a question:  how does an RMB program know
if it's running on a system controller or nonsystem controller, or if it is
the current active controller?  Without this knowledge, the ability to pass
control will lead quickly to mutual confusion within the programs on the two
systems.
</p>
<p>
This is pretty straightforward, with that information provided by status
register 3.  Bit 7 says if the controller is a system controller (1) or
non-system controller (0) and bit 6 says if the controller is the active
controller (1) or inactive controller (0):
</p>
<pre><strong>
   STATUS 7,2;Sts
   IF BIT(Sts,7)=1 THEN
     PRINT &quot;System controller.&quot;
   ELSE
     PRINT &quot;Non-system controller.&quot;
   END IF
   IF BIT(Sts,6)=1 THEN
     PRINT &quot;Active controller.&quot;
   ELSE
     PRINT &quot;Inactive controller.&quot;
   END IF
 </strong></pre>
<p>
Note that the five lowest bits of status register 3 also give the HPIB
address of the controller:
</p>
<pre><strong>
   PRINT &quot;HPIB Address =&quot;;BINAND(Sts,31)  ! Print lowest five bits.
 </strong></pre>
<p>
Anyway, this status is essential for avoiding confusion in
controller-noncontroller operation.
</p>
<p>
* The second detail concerns the actual protocol for passing control.  To be
sure, if one controller passes control to a second controller, the second
controller becomes active controller without any further trouble, but 
usually the inactive controller is the one driving the process, since it
wants to do something and the active controller is in the way.
</p>
<p>
So the inactive controller can assert an SRQ -- service request -- using
the REQUEST statement to ask the active controller to pass control:
</p>
<pre><strong>
   REQUEST 7,64
 </strong></pre>
<p>
Note that only the interface select code is specified.  Naturally, since all
this does is assert the SRQ line and make a serial poll response byte (here
given as 64) available.  A value of 64 sets bit 6, which indicates a service
request.  Setting any other bits is optional.
</p>
<p>
The active controller will then perform serial polls to see who asserted the
SRQ.  If it's the inactive controller, it then passes control:
</p>
<pre><strong>
   STATUS 7,7;Sts                
   IF BIT(Sts,10)=1 THEN    ! SRQ bit is bit 10 of HPIB status 7.
     Sts=SPOLL(701)         ! Serial poll inactive controller.
     IF BIT(Sts,6)=1 THEN   ! If SRQ bit set, then pass control.
       PASS CONTROL 701
     END IF
   END IF
 </strong></pre>
<p>
This code sample assumes operation on the system controller.  Note that this
sample actually checks the SRQ bit in status register 7 to see if an SRQ
has happened.  In reality, it may be easier to do it using an interrupt:
</p>
<pre><strong>
   ON INTR 7 GOSUB Srqtrap    ! Set up jump.
   ENABLE INTR 7,2            ! Specify SRQ interrupt.
   ...
 Srqtrap: !
   Sts=SPOLL(701)
   IF BIT(Sts,6)=1 THEN
     PASS CONTROL 701
   END IF
   RETURN
 </strong></pre>
<p>
* The third detail is that the system controller can, unlike all the other
controllers on the same HPIB, get control back any time it wants it, by
executing the command ABORT, which asserts IFC (interface clear) and restores
all the interfaces to their default state.
</p>
<p>
* The distinction between the concepts of system controller and active
controller should be clearly described by the discussion so far, but since
this is a confusing issue let me summarize it.
</p>
<p>
There can be multiple controllers on a single HPIB connection.  Any of them
can be active controller if control is passed to them.  There is, however,
only one system controller.  It comes up as active controller on boot-up
(the non-system controllers are inactive on boot-up), and it can take control
back from any other controller by executing ABORT.
</p>
<p>
The system controller is not necessarily the active controller.  The active
controller can jump from controller to controller as control is passed over
the bus.  But it is <em>always</em> the system controller, and it is the <em>only</em>
system controller.
</p>
<p>
* This explains about all there is to know about passing control in itself,
with the exception of one final detail:  why do it?
</p>
<p>
The only good reason that I know for passing control is that instruments
often have the capability to dump a plot to a plotter or printer on the same
HPIB.  Some of the older instruments will demand to be made system controller
for this operation.  The program sends it a command to print, passes
control to it, then wait for it to pass control back.
</p>
<p>
However, it is a common misconception that this is the <em>only</em> way to
perform this task.  The logic is that the instrument is talking to the
printer or plotter, and of course it has to be a controller to do that,
right?
</p>
<p>
No, not really.  A controller can set up one device as a talker and another
as a listener, and then the two can talk to each other without controller
intervention.  Assuming an instrument at address 713 and a printer at address
705, most instruments that have the capability to dump directly to a printer
could be instructed to do so with something like this:
</p>
<pre><strong>
   OUTPUT 713;&quot;PRINT?&quot;
   SEND 7;UNT UNL TALK 713 LISTEN 705 DATA &quot;&quot;
 </strong></pre>
<p>
The SEND command sends HPIB command bytes, setting up the talker-listener
transaction (the DATA &quot;&quot; at the end releases the ATN line, allowing the
transaction to proceed).  
</p>
<p>
Of course, if the instrument understands the 488.2 OPC? (operation complete)
query, the program can also instruct it to assert an SRQ when it is done with
the print operation.  However, that is a little beyond the scope of this
discussion.
</p>
<p>
* So passing control can be done easily, but in general it's not all that
useful.  What is not so easy to do is try to write an RMB program that
operates completely in noncontroller mode -- that is, just like an instrument
on the HPIB, its operations directed by the controller.
</p>
<p>
Using an HPIB controller is easy.  It tells the other devices what to do
whenever it pleases, and they have to respond accordingly.  For this reason,
being an HPIB slave is hard.  It has to respond whenever required, with the
information the controller expects to get back.
</p>
<p>
This normally means that you have to set up an interrupt in the noncontroller
so it can respond when needed.  The most useful interrupt for this purpose is
the &quot;talker-listener address change&quot; (TLAC) flag associated with the
interface, which is asserted any time the slave is addressed.  An interrupt
on TLAC can be set up as follows:
</p>
<pre><strong>
   ON INTR 7 GOSUB Tlacintr
   ENABLE INTR 7;256
 </strong></pre>
<p>
When the slave gets the TLAC interrupt, it can then check to see if it is
addresses to talk or listen and respond accordingly:
</p>
<pre><strong>
 Tlacintr: !
   STATUS 7,6;Sts
   IF BIT(Sts,10)=1 THEN       ! Addressed to listen (LADS).
     ENTER 7;S$                ! Get a command (I/O is from interface).
     ELSE
     IF BIT(Sts,9)=1 THEN      ! Addressed to talk (TADS)
       SELECT S$
       CASE &quot;*IDN?&quot;
	 OUTPUT 7;Addrstr$     
         ...
       END SELECT
     END IF
   END IF
 </strong></pre>
<p>
Note that status register 6 contains the listen-addressed (LADS) bit (bit 10)
and the talk-addressed (TADS) bit (bit 9), and that the ENTERs and OUTPUTs
have to be from the interface (remember, only a controller has addressing
privileges).
</p>
<p>
This is a pretty rough outline of what needs to be done, however.  The slave
must actually be able to respond precisely to whatever the controller asks of
it using the list of CASE statments above.  The protocol for doing this has to
be agreed-on by the controller and slave.
</p>
<p>
This is not too hard if the controller just sends a command and the slave
makes a response.  The slave's operation would look something like this:
</p>
<pre><strong>
   get TLAC interrupt
   slave is listen addressed
   get and check command
   go back to wait on TLAC interrupt

   get TLAC interrupt
   slave is talk addressed
   provide proper output for command
   go back and wait on TLAC interrupt
 </strong></pre>
<p>
The slave has to do a lot of error checking, however.  If anything goes
wrong, it needs to issue an error and then go back and wait for the
controller to issue a new command it understands.
</p>
<p>
Where this gets really tricky is when you want to transfer, say, a file of
indeterminate length between the controller and slave.  Once the slave has
been given the command to send a file and is then addressed to talk, it then
must sit in a loop and send the file line by line and assume the controller
is reading it, since the slave remains in talk mode until otherwise
instructed.  On the last line, the slave needs to assert EOI with the last
byte to tell the controller that the transmission is over.  Similar comments
apply to transferring a file from the controller to the slave.
</p>
<p>
This may sound straightforward, but in practice it can be a real nuisance to
get to work.  RS-232, which is a peer-to-peer system, for once works better
than HPIB.  
</p>
<p>
In summary, once more:  you don't want to try to do things like this if you
have any choice in the matter.  Under RMB it is tricky.  Under other
applications and interface libraries, it may be completely impossible.
</p>
<hr />
 
</body>
</html>