Text preview for : HP 8711C_252C 12C_252C 13C_252C 14C Programmer 1998.pdf part of Agilent HP 8711C 252C 12C 252C 13C 252C 14C Programmer 1998 Agilent HP 8711C_252C 12C_252C 13C_252C 14C Programmer 1998.pdf
Back to : HP 8711C_252C 12C_252C 13 | Home
Programmer's Guide
HP 8711C/12C/13C/14C
RF Network Analyzers
HP part number: 08712-90057
Printed in USA August 1998 Supersedes April 1998
Notice The information contained in this document is subject to change without
notice.
Hewlett-Packard makes no warranty of any kind with regard to this material,
including but not limited to, the implied warranties of merchantability and
fitness for a particular purpose. Hewlett-Packard shall not be liable for errors
contained herein or for incidental or consequential damages in connection
with the furnishing, performance, or use of this material.
Firmware Revision This manual documents analyzers with firmware revisions C. 04.52 or later.
Some features will not be available or will require different keystrokes
in analyzers with earlier firmware revisions. For full compatibility, you
can upgrade your firmware to the latest version. Contact your nearest
Hewlett-Packard sales or service office for information.
@Copyright 1996, 1997, 1998 Hewlett-Packard Company
HP-IB Programming
This document is an introduction to programming your analyzer over the
Hewlett-Packard Interface Bus (HP-IB). Its purpose is to provide concise
information about the operation of the instrument under HP-II3 control.
It provides some background information on the HP-IB and a tutorial
introduction using programming examples to demonstrate the remote
operation of the analyzer. The examples are provided on two disks that are
included with the analyzer. Both disks contain the same examples written
mainly in HP BASIC; only the disk format is different. These programs can
run on the analyzer's internal controller (Option lC2) or on an external
controller.
l Example Programs Disk - DOSFbvmat : part number 08712-10019
l ExammpLe Programs Disk - LIFRrrmat : part number 08712-10021
You should become familiar with the operation of your network analyzer
before controlling it over HP-IB. This document is not intended to teach
programming or to discuss HP-IB theory except at an introductory level.
Related information can be found in the following references. Contact the
nearest HP sales office for ordering information. A list of HP sales and service
offices can be found in the "Specifications and Characteristics" chapter of the
User's Guide.
l Information on making measurements with the analyzer is available in the
analyzer's User's Guide.
l Information on HP Instrument BASIC is available in the HP Instrument
BASIC User's Handbook.
0 Information on HP BASIC programming is available in the manual set for
the BASIC revision being used. For example: BASIC 7.0 Programming
Rchniques and BASIC 7.0 Language Reference.
l Information on using the HP-IB is available in the Tutorial Description of
the Hewlett-Packard Interface Bus (HP literature no. 5021-1927).
...
111
Contents
1. Introduction to BP-IB Programming
Bus Structure .................... l-4
Data Bus ..................... l-4
Handshake Lines ................. l-4
Sending Commands ................. l-6
HP-IB Requirements ................. l-7
Interface Capabilities ................ 1-8
Programming Fundamentals ............. l-9
Controller Capabilities ............... l-9
Response to Bus Management Commands ...... l-10
Message Exchange ................. 1-13
2. Synchronizing the Analyzer and a Controller
Overlapped Commands ............... 2-3
The NPO Flag ................... 2-5
Usage of *WA1 and *OPC? ............. 2-7
3. Passing Control
4. Data Types and Encoding
Data Types ..................... 4-3
Numeric Data ................... 4-3
Character Data .................. 4-4
String Data .................... 4-4
Expression Data .................. 4-4
Block Data .................... 4-5
Data Encoding for Large Data Transfers ........ 4-7
ASCII Encoding .................. 4-8
Binary Encoding ................. 4-8
Byte Swapping .................. 4-9
Contents-l
Query Errors
5. Using Status Registers
General Status Register Model ............ 5-3
Condition Register ................ 5-4
Transition Registers ................ 5-4
Event Register .................. 5-4
Enable Register .................. 5-5
How to Use Registers .................. 5-6
The Service Request Process ............. 5-7
Generating a Service Request ............ 5-8
The Analyzer's Status Register Sets .......... 5-10
Status Byte .................... 5-12
Device Status Register Set ............. 5-15
Limit Fail Register Set ............... 5-16
Questionable Status Register Set .......... 5-19
Standard Event Status Register Set ......... 5-20
Measuring Status Register Set ........... 5-23
Averaging Status Register Set ............ 5-23
Operational Status Register Set ........... 5-24
STATus:PRESet Settings .............. 5-25
Analyzer Register Set Summary ........... 5-26
6. Trace Data Transfers
Querying the Measurement Trace Using BASIC ..... 6-3
@Smith Chart and Polar Formats .......... 6-4
Querying the Measurement Trace Using SICL ...... 6-5
Using Binary Data Encoding ............. 6-7
Trace Data Transfer Sizes 6-9
Transferring Data with IBASIC : : : : : : : : : : : : 6-10
Taking Sweeps ................... 6-11
CALC:DATA? versus TRACE:DATA? . . . . . . . . . . . . 6-12
Querying Single Data Points Using Markers ....... 6-13
Accessing Other Measurement Arrays ......... 6-14
Applying Gain Correction Using the Memory Trace ... 6-16
Performing Your Own Data Processing ......... 6-18
Downloading Trace Data Using Binary Encoding .... 6-20
Internal Measurement Arrays ............. 6-21
Raw Data Arrays ................. 6-22
Ratio Calculations ................. 6-23
Error Correction ................. 6-23
Contents-2
Query Errors
Error Coefficient Arrays .............. 6-23
Averaging ...................... 6-25
Corrected Data Arrays ............... 6-25
Corrected Memory Arrays ............. 6-25
Trace Math Operation ............... 6-26
@ Electrical Delay ................. 6-26
Transform (Option 100 only) ............ 6-26
Formatting .................... 6-27
Formatted Arrays ................. 6-27
Offset and Scale .................. 6-27
7. Using Graphics
Window Geometry . . . . . . . . . . . . . . . . . 7-4
The Graphics Buffer . . . . . . . . . . . . . . . . . 7-6
8. Example Programs
Configuring Measurements .............. 8-7
SETUP Example Program ............. 8-8
LIMITEST Example Program ............ 8-11
POWERSWP Example Program .......... 8-16
Transfer of Data to/from the Analyzer ......... 8-19
MARKERS Example Program ........... S-20
@SMITHMKR Example Program .......... 8-24
ASCDATA Example Program ............ 8-31
REALDATA Example Program ........... 8-34
INTDATA Example Program ............ 8-38
FAST-C W Example Program ............ 8-42
Calibration ..................... 8-45
TRANCAL Example Program ........... 8-46
REFLCAL Example Program ............ 8-48
LOADCALS Example Program ........... 8-53
CALKIT Example Program . . S-60
Instrument State and Save/Recall : : : : : : : : : . . 8-62
LEARNSTR Example Program ........... 8-63
SAVERCL Example Program ............ 8-66
Hardcopy Control .................. 8-69
PRINTPLT Example Program ........... 8-70
PASSCTRL Example Program ........... 8-73
Contents-3
Query Errors
FAST-PRT Example Program ........... 8-77
Service Request .................... S-80
SRQ Example Program .............. 8-81
SRQ-INT Example Program ............ 8-85
File Transfer Over HP-IB ............... S-102
GETFILE Example Program ............ S-103
PUTFILE Example Program ............ S-105
Customized Display ................. S-108
GRAPHICS Example Program ........... S-109
GRAPH2 Example Program ............ 8-116
GETPLOT Example Program ........... 8-122
Annot ation ..................... 8-125
USERANOT Example Program ........... 8-126
FREQBLNK Example Program ........... 8-129
KEYCODES Example Program ........... 8-131
Marker Functions .................. 8-134
MKR-MATH Example Program .......... 8-135
Marker Limit Testing ................ 8-139
LIM-FLAT Example Program ........... S-140
LIM-PEAK Example Program ........... 8-143
LIM-MEAN Example Program ........... 8-147
SRL Measurements (Option 100 only) ......... 8-151
MEAS-SRL Example Program ........... 8-152
SRL-SRQ Example Program ............ 8-156
Fault Location Measurements (Option 100 only) ..... S-160
FAULT Example Program ............. 8-161
USR-FLOC Example Program ........... 8-165
Multiport Test Set Measurements ........... 8-168
PORT-SELection Example Program ......... 8-169
TSET-CAL Example Program ........... 8-182
TTL Output .................... 8-186
TTL-IO Example Program ............. 8-186
AM Delay ..................... 8-189
AMDELAY Example Program ........... 8-189
Contents-4
Query Errors
9. Front Panel Keycodes
10. Introduction to SCPI
The Command Tree . . . . . . ........... 10-3
Sending Multiple Commands . . ........... 10-7
Command Abbreviation . . . . ........... 10-S
Implied Mnemonics . . . . . . ........... 10-9
Parameter Types . . . . . . . . ........... 10-10
Numeric Parameters . . . . . ........... 10-10
Character Parameters . . . . ........... 10-11
Boolean Parameters . . . . . ........... 10-12
String Parameters . . . . . . ........... 10-13
Block Parameters . . . . . . ........... 10-14
Syntax Summary . . . . . . . ........... 10-15
IEEE 488.2 Common Commands ........... 10-17
11. Menu Map with SCPI Commands
12. SCPI Command Summary
13. SCPI Conformance Information
SCPI Standard Commands . . . 13-3
Instrument Specific Commands . 13-9
14. SCPI Error Messages
Command Errors . . . . . . . ........... 14-3
Execution Errors . . . . . . . ........... 14-7
Device-Specific Errors . . . . . ........... 14-12
Query Errors . . . . . . . . . ........... 14-14
Index
Contents-5
Figures
5-1. General Status Register Model . . . . . . . . . . . 5-3
5-2. Flow of information within a register set . . . . . . 5-5
5-3. Generating a Service Request . . . . . . . . . . . . . . . 5-8
5-4. Analyzer Register Sets . . . . . . . . . . . . 5-11
5-5. The Status Byte Register Set . . . . _ . . . . 5-12
5-6. The Limit Fail Register Set . . . . . . . . . . . . . . . 5-17
5-7. The Standard Event Status Register Set . . . . . . . . . 5-20
5-8. Analyzer Register Set Summary . . . . . . . . . . . . . . 5-26
6-1. Numeric Data Flow Through the Network Analyzer . . . 6-2
6-2. Numeric Data Flow Through the Network Analyzer . . . . . 6-14
6-3. Numeric Data Flow Through the Network Analyzer . . . 6-21
7-l. Pixel Dimensions with Available Display Partitions . . . . . 7-4
10-l. Measurement and Data Flow of the Analyzer . . . . . 10-3
10-2. Partial Diagram of the CALCulate Subsystem Command Tree . 10-6
10-3. SCPI Command Syntax . . . . . . . . . . . . lo-15
Contents-6
lhbles
6-l. Typical Trace Transfer Times (ms) . . . . . . . . . . . . 6-7
6-2. Size of Trace Data Transfers (in Bytes) Using the TRACE:DATA
SCPI Command . . . . . . . . . . . . . . . . . . . 6-9
6-3. Typical Trace Transfer Times (ms) . . . . . . . . . . . . 6-10
6-4. Raw Data Arrays . . . . . . . . . . . . . . . . . . . . 6-22
6-5. Error Coefficient Arrays . . . . . . . . . . . . . . . . . 6-24
12-1. Writeable Ports . . . . . . . . . . . . . . . . . . . . . 12-13
12-2. Readable Ports . . . . . . . . . . . . . . . . . . . . . 12-14
14-1. SCPI Command Errors . . . . . . . . . . . . . . . . . . 14-4
14-2. SCPI Execution Errors . . . . . . . . . . . . . . . . . . 14-8
14-3. SCPI Device-Specilic Errors . . . . . . . . . . . . . . . . 14-13
14-4. SCPI Query Errors . . . . . . . . . . . . . . . . . . . . 14-14
Contents-7
Contents
1
Introduction to HP-IB
Programming
Introduction to HP-IB Programming
HP-IB - the Hewlett-Packard Interface Bus - is a high-performance bus
that allows individual instruments and computers to be combined into
integrated test systems. The bus and its associated interface operations are
defined by the IEEE 488.1 standard. The IEEE 488.2 standard defines the
interface capabilities of instruments and controllers in a measurement system,
including some frequently used commands.
HP-IB cables provide the physical link between devices on the bus. There are
eight data lines on each cable that are used to send data from one device to
another. Devices that send data over these lines are called Talkers. Listeners
are devices that receive data over the same lines. There are also five control
lines on each cable that are used to manage trafhc on the data lines and to
control other interface operations. Controllers are devices that use these
control lines to specify the talker and listener in a data exchange. When an
HP-IB system contains more that one device with controller capabilities,
only one of the devices is allowed to control data exchanges at any given
time. The device currently controlling data exchanges is called the Active
Controller. Also, only one of the controller-capable devices can be designated
as the System Controller, the one device that can take control of the bus
even if it is not the active controller. The network analyzer can act as a
talker, listener, active controller or system controller at different times.
HP-IB addresses provide a way to identify devices on the bus. The active
controller uses HP-IB addresses to specify which device talks and which
device listens during a data exchange. This means that each device's address
must be unique. A device's address is set on the device itself, using either a
front-panel key sequence or a rear-panel switch.
To set the HP-IB address on the analyzer use the softkeys located in the
[SYSTEM OPTIONS) HP-IB menu. The factory default address for the analyzer
is 16.
l-2
Introduction to HP-IB Programming
NOTE
Throughout this manual, the following conventions are used:
Square brackets Cc II are used to enclose a keyword that is optional or implied when
programming the command; that is, the instrument will process the command to have the same
effect whether the option node is omitted or not.
Parameter types (C >I are distinguished by enclosing the type name in angle brackets.
A vertical bar (I ) can be read as "or" and is used to separate alternative parameter options.
I I
l-3
Bus Structure
Data Bus
The data bus consists of eight lines that are used to transfer data from one
device to another. Programming commands and data sent on these lines is
typically encoded in the ASCII format, although binary encoding is often used
to speed up the transfer of large arrays. Both ASCII and binary data formats
are available to the analyzer. In addition, every byte transferred over HP-IB
undergoes a handshake to ensure valid data.
Handshake Lines
A three-line handshake scheme coordinates the transfer of data between
talkers and listeners. This technique forces data transfers to occur at the
speed of the slowest device, and ensures data integrity in multiple listener
transfers. With most computing controllers and instruments, the handshake is
performed automatically, which makes it transparent to the programmer.
Control lines The data bus also has five control lines that the controller uses both to send
bus commands and to address devices:
IFC Interface Clear. Only the system controller uses this line.
When this line is true (low) all devices (addressed or not)
unaddress and go to an idle state.
ATN Attention. The active controller uses this line to define
whether the information on the data bus is a command or is
data. When this line is true (low) the bus is in the command
mode and the data lines carry bus commands. When this
line is false (high) the bus is in the data mode and the data
lines carry device-dependent instructions or data.
l-4
Introduction to HP-IB Programming
Bus Structure
SRQ Service Request. This line is set true (low) when a
device requests service: the active controller services the
requesting device. The analyzer can be enabled to pull the
SRQ line for a variety of reasons.
REN Remote Enable. Only the system controller uses this line.
When this line is set true (low) the bus is in the remote
mode and devices are addressed either to listen or talk.
When the bus is in remote and a device is addressed, the
device receives instructions from HP-IS rather than from its
front panel (pressing the Beturn to Local softkey returns
the device to front panel operation). When this line is set
false (high) the bus and all devices return to local operation.
EOI End or Identify. This line is used by a talker to indicate the
last data byte in a multiple byte transmission, or by an
active controller to initiate a parallel poll sequence. The
analyzer recognizes the EOI line as a terminator and it pulls
the EOI line with the last byte of a message output (data,
markers, plots, prints, error messages). The analyzer does
not respond to parallel poll.
l-5
Sending Commands
Commands are sent over the HP-IB via a controller's language system,
such as IBASIC, QuickBASIC or C. The keywords used by a controller to
send HP-IB commands vary among systems. When determining the correct
keywords to use, keep in mind that there are two different kinds of HP-IB
commands:
l Bus management commands, which control the HP-IB interface.
l Device commands, which control analyzer functions.
Language systems usually deal differently with these two kinds of HP-IB
commands. For example, HP BASIC uses a unique keyword to send each bus
management command, but always uses the keyword OUTPUT to send device
commands.
The following example shows how to send a typical device command:
OUTPUT 7 16 ; "CALCULATE : MARKER : MAXIMUM"
This sends the command within the quotes (CALCULATE : MARKER : MAXIMUM)
to the HP-II3 device at address 716. If the device is an analyzer, the command
instructs the analyzer to set a marker to the maximum point on the data
trace.
l-6
HP-IB Requirements
Number of Interconnected 15 maximum
Devices:
Interconnection 20 meters maximum or 2 meters per device,
Path/Maximum Cable Length: whichever is less.
Message Transfer Scheme: Byte serial/ bit parallel asynchronous data
transfer using a 3-line handshake system.
Data Rate: Maximum of 1 megabyte per second over
limited distances with tri-state drivers.
Actual data rate depends on the transfer rate
of the slowest device involved.
Address Capability: Primary addresses: 31 talk, 31 listen. A
maximum of 1 talker and 14 listeners at one
time.
Multiple Controller Capability: In systems with more than one controller
(like the analyzer system), only one can
be active at a time. The active controller
can pass control to another controller, but
only the system controller can assume
unconditional control. Only one system
controller is allowed. The system controller
is hard-wired to assume bus control after a
power failure.
l-7
Interface Capabilities
The analyzer has the following interface capabilities, as defined by the
IEEE 488.1 standard:
SHl full Source handshake capability
AH1 full Acceptor handshake capability
T6 basic Talker, Serial Poll, no Talk Only, unaddress if MLA
TEO no Extended Talker capability
L4 basic Listener, no Listen Only, unaddress if MTA
I LEO I no Extended Listener capability I
SRl full Service Request capability
I
1 RLl 1 full Remote/local capability
I OCI I full Device Clear caoabilitv I
Cl I System Controller capability I
c2 send IFC and take charge Controller capability
I c3 send REN Controller capability I
c4l respond to SRC
CB1 send IFC, receive control, pass control, pass control to self
c122 send IF messages, receive control, pass control
E2 tri-state drivers
LIT1 full device trigger capability
PPO no parallel poll capability
1 only when an HP Instrument BASIC program is running
2 only when an HP Instrument BASIC program is not running
1-8
Programming Fundamentals
This section includes specific information for programming your network
analyzer. It includes how the analyzer interacts with a controller, how data
is transferred between the analyzer and a controller, and how to use the
analyzer's status register structure to generate service requests.
Controller Capabilities
The analyzer can be conEgured as an HP-IIl system controller or as
a talker/listener on the bus. `Ib configure the analyzer, select either
the System Controller or the TalkerlListeaer softkey in the
@YSTEM 0PrloNs) HP-IB menu.
The analyzer is not usually conEgured as the system controller unless it is the
only controller on the bus. This setup would be used if the analyzer only
needed to control printers or plotters. It would also be used if HP Instrument
BASIC was being used to control other test equipment.
When the analyzer is used with another controller on the bus, it is usually
conEgured as a talker/listener. In this conEguration, when the analyzer is
passed control it can function as the active controller.
l-9
Introduction to HP-IR Programming
Programming Fundamentals
Response to Bus Management Commands
The HP-IB contains an attention (ATN) line that determines whether
the interface is in command mode or data mode. When the interface is
in command mode (ATN TRUE) a controller can send bus management
commands over the bus. Bus management commands specify which devices
on the interface can talk (send data) and which can listen (receive data).
They also instruct devices on the bus, either individually or collectively, to
perform a particular interface operation.
This section describes how the analyzer responds to the HP-IB bus
management commands. The commands themselves are defined by the
IEEE 488.1 standard. Refer to the documentation for your controller's
language system to determine how to send these commands.
Device Clear (DC11 When the analyzer receives this command, it:
l Clears its input and output queues.
l Resets its command parser (so it is ready to receive a new program
message).
l Cancels any pending *OPC command or query.
The command does not affect:
l Front panel operation.
l Any analyzer operations in progress (other than those already mentioned).
l Any instrument settings or registers (although clearing the output queue
may indirectly affect the Status Byte's Message Available (MAV) bit).
Go To local (GTLI This command returns the analyzer to local (front-panel) control. All keys on
the analyzer's front-panel are enabled.
Interface Clear (IFC) This command causes the analyzer to halt all bus activity. It discontinues
any input or output, although the input and output queues are not cleared.
If the analyzer is designated as the active controller when this command is
received, it relinquishes control of the bus to the system controller. If the
analyzer is enabled to respond to a Serial Poll it becomes Serial Poll disabled.
l-10
Introduction to HP-16 Programming
Programming Fundamentals
local lockout (1101 This command causes the analyzer to enter the local lockout mode, regardless
of whether it is in the local or remote mode. The analyzer only leaves the
local lockout mode when the HP-IB's Remote Enable (REN) line is set FALSE.
Local Lockout ensures that the analyzer's remote softkey menu (including the
Rstunr ta LOCAL softkey) is disabled when the analyzer is in the remote
mode. When the key is enabled, it allows a front-panel operator to return the
analyzer to local mode, enabling all other front-panel keys. When the key is
disabled, it does not allow the front-panel operator to return the analyzer to
local mode.
Parallel Poll The analyzer ignores all of the following parallel poll commands:
l Parallel Poll ConEgure (PPC).
l Parallel Poll UnconEgure (PPU).
l Parallel Poll Enable (PPE).
l Parallel Poll Disable (PPD).
Remote Enable (RENI REN is a single line on the HP-IR. When it is set TRUE, the analyzer will
enter the remote mode when addressed to listen. It will remain in remote
mode until it receives the Go to Local (GTL) command or until the REN line is
set FALSE.
When the analyzer is in remote mode and local lockout mode, all front panel
keys are disabled. When the analyzer is in remote mode but not in local
lockout mode, all front panel keys are disabled except for the softkeys. The
remote softkey menu includes seven keys that are available for use by a
program. The eighth softkey is the Bet- to LOCAL key which allows a
front-panel operator to return the analyzer to local mode, enabling all other
front-panel keys.
l-11
Introduction to HP-18 Programming
Programming Fundamentals
Selected Device Clear The analyzer responds to this command in the same way that it responds to
(SDC) the Device Clear (DCL) command.
When the analyzer receives this command it:
l Clears its input and output queues.
l Resets its command parser (so it is ready to receive a new program
message).
l Cancels any pending *OPC command or query.
The command does not affect:
l Front-panel operation.
l Any analyzer operations in progress (other than those already mentioned).
l Any analyzer settings or registers (although clearing the output queue may
indirectly affect the Status Byte's MAV bit).
Serial Poll The analyzer responds to both of the serial poll commands. The Serial Poll
Enable (SPE) command causes the analyzer to enter the serial poll mode.
While the analyzer is in this mode, it sends the contents of its Status Byte
register to the controller when addressed to talk.
When the Status Byte is returned in response to a serial poll, bit 6 acts as the
Request Service (RQS) bit. If the bit is set, it will be cleared after the Status
Byte is returned.
The Serial Poll Disable (SPD) command causes the analyzer to leave the serial
poll mode.
Take Control Talker If the analyzer is addressed to talk, this command causes it to take control
ITCTI of the HP-IB. It becomes the active controller on the bus. The analyzer
automatically passes control back when it completes the operation that
required it to take control. Control is passed back to the address speciEed by
the *PCB command (which should be sent prior to passing control).
If the analyzer does not require control when this command is received, it
immediately passes control back.
1-12
Introduction to HP-IB Programming
Programming Fundamentals
Message Exchange
The analyzer communicates with the controller and other devices on the
HP-IB using program messages and response messages. Program messages are
used to send commands, queries, and data to the analyzer.
Response messages are used to return data from the analyzer. The syntax for
both kinds of messages is discussed in Chapter 10.
There are two important things to remember about the message exchanges
between the analyzer and other devices on the bus:
l The analyzer only talks after it receives a terminated query (see "Query
Response Generation" later in this section).
l Once it receives a terminated query, the analyzer expects to talk before it is
told to do something else.
HP-IB Queues Queues enhance the exchange of messages between the analyzer and other
devices on the bus. The analyzer contains:
l An input queue.
l An error queue.
l An output queue.
Input Queue.
The input queue temporarily stores the following until they are read by the
analyzer's command parser:
l Device commands and queries.
l The HP-IB END message (EOI asserted while the last data byte is on the
bus).
The input queue also makes it possible for a controller to send multiple
program messages to the analyzer without regard to the amount of time
required to parse and execute those messages. The queue holds up to
128 bytes. It is cleared when:
l The analyzer is turned on.
l The Device Clear (DCL) or Selected Device Clear (SDC) command is
received.
1-13
Introduction to HP-M Programming
Programming Fundamentals
Error Queue.
The error queue temporarily stores up to 20 error messages. Each time
the analyzer detects an error, it places a message in the queue. When you
send the SYST:ERR? query, one message is moved from the error queue to
the output queue so it can be read by the controller. Error messages are
delivered to the output queue in the order they were received.
The error queue is cleared when:
l All the error messages are read using the SYST : ERR? query.
l The analyzer is turned on.
l The *CLS command is received.
Output Queue.
The output queue temporarily stores a single response message until it is read
by a controller. It is cleared when:
l The message is read by a controller.
l The analyzer is turned on.
l The Device Clear (DCL) or Selected Device Clear (SDC) command is
received.
Command Parser The command parser reads program messages from the input queue in the
order they were received from the bus. It analyzes the messages to determine
what actions the analyzer should take.
One of the parser's most important functions is to determine the position of a
program message in the analyzer's command tree (described in Chapter 10).
When the command parser is reset, the next command it receives is expected
to arise from the base of the analyzer's command tree.
The parser is reset when:
l The analyzer is turned on.
l The Device Clear (DCL) or Selected Device Clear (SDC) command is
received.
l A colon immediately follows a semicolon in a program message. (For more
information see "Sending Multiple Commands" in Chapter 10.)
l A program message terminator is received. A program message terminator
can be an ASCII carriage return (`n) or newline character or the HP-IS
END message (EOI set true).
1-14
Introduction to HP-IB Programming
Query Response When the analyzer parses a query, the response to that query is placed in
Generation the analyzer's output queue. The response should be read immediately after
the query is sent. This ensures that the response is not cleared before it is
read. The response is cleared when one of the following message exchange
conditions occurs:
l Unterminated condition - the query is not properly terminated with an
ASCII carriage return character or the HP-IB END message (EOI set true)
before the response is read.
l Interrupted condition - a second program message is sent before the
response to the first is read.
l Buffer deadlock - a program message is sent that exceeds the length of the
input queue or that generates more response data than Ets in the output
queue.
1-15
Introduction to HP-IB Programming
2
Synchronizing the
Analyzer
and a Controller
Synchronizing the Analyzer
and a Controller
The IEEE 488.2 standard provides tools that can be used to synchronize the
analyzer and a controller. Proper use of these tools ensures that the analyzer
is in a known state when you send a particular command or query.
Device commands can be divided into two broad classes:
l Sequential commands.
l Overlapped commands.
Most of the analyzer's commands are processed sequentially. A sequential
command holds off the processing of subsequent commands until it has been
completely processed.
Some commands do not hold off the processing of subsequent commands;
they are called overlapped commands.
2-2
Overlapped Commands
Typically, overlapped commands takelongerto process than sequential
commands. Forexample,the :INITIATE:IMMEDIATEcommandrestarts a
measurement. The command is not considered to have been completely
processed until the measurement is complete. This can take alongtime with
a narrow or fine system bandwidth or when averaging is enabled.
The analyzer has the following overlapped commands:
ABORt
CALibration:ZERO:AUTO
CONFigure[ll21
DIAGnostic:CCONstants:LOAD
DIAGnostic:CCONstants:STORe:DISK
DIAGnostic:CCONstants:STORe:EEPRom
DIAGnostic:DITHer
DIAGnostic:SPUR:AVOid
HCOPy[:IMMediate]
INITiate[ll2]:CONTinuous
INITiate[lI2][:IMMediate]
MMEMory:LOAD:STATe
OUTPut[:STATe]
POWer[112l:MODE
PROGram[:SELected]:EXECute
ROUTE[ll2]:PATH:DEFine:PORT(foruse withmultiporttest sets)
SENSeCll2l:AVERage:CLEar
SENSeC112l:AVERage:COUNt
SENSe[l I2l:AVERageC:STATel
SENSe[ll2]:BWIDth[:RESolutionl
SENSe[112]:CORRection:COLLect[:ACQuirel
SENSe[1l2]:CORRection:COLLect:ISTate[:AUTOl
SENSe[112]:CORRection:COLLect:METHod
SENSe[ll2]:CORRection:COLLect:SAVE
SENSe[ll2]:CORRection:CSET[:SELect]
SENSe[ll2]:CORRection[:STATel
SENSe:COUPle
SENSe[ll21:DETector[:FUNCtionl
SENSe[ll2]:DISTance:STARt(Option 100 only)
SENSe[ll2]:DISTance:STOP(Option lOOonly)
2-3
Synchronizing the Analyzer
and a Controller
Overlapped Commands
SENSeCl I2l:FREQuency:CENTer
SENSe[ll2]:FREQuency:MODE(Option 100 only)
SENSeCll21:FREQuency:SPAN
SENSeCll21:FREQuency:SPAN:MAXimum
SENSeCll21:FREQuency:STARt
SENSeCll21:FREQuency:STOP
SENSeCl I2l:FUNCtion
SENSe[1121:FUNCtion:SRL:SCANC:IMMediate](Option lOOonly)
SENSe:ROSCillator:SOURce
SENSeCll2l:STATe
SENSe[ll21:SWEep:POINts
SENSe[ll2]:SWEep:TIME
SENSe[112]:SWEep:TIME:AUTO
SENSe:SWEep:TRIGger:SOURce
SOURce[1l21:POWerC:LEVel] [:IMMediate] [:AMPLitude]
SYSTem:PRESet
TRACe[:DATA]
TRIGger[:SEQuence]:SOURce
2-4
The NPO Flag
The analyzer uses a No Pending Operation (NPO) flag to keep track of
overlapped commands. The NPO flag is reset to 0 when an overlapped
command has not completed (still pending). It is set to 1 when no overlapped
commands are pending. The NPO flag cannot be read directly but all of the
following common commands take some action based on the setting of the
flag.
*WA1 Holds off the processing of subsequent commands until the NPO
flag is set to 1. This ensures that commands in the analyzer's input
queue are processed in the order received.
The program continues to run, and additional commands are
received and parsed by the analyzer (but not executed), while
waiting for the NPO flag to be set. Use of the *WA1 command is
explained later in this section and is demonstrated in the SETUP
example program.
*0PC? Places a 1 in the analyzer's output queue when the NPO flag is set
to 1. lf the program is designed to read the output queue before it
continues, this effectively pauses the controller until all pending
overlapped commands are completed. Use of the *OPC? command is
explained later in this chapter and is demonstrated in the TRANCAL
and REFLCAL example programs.
*0PC Sets bit 0 of the Standard Event Status event register to 1 when the
NPO flag is set to 1. The analyzer's status registers can then be
used to generate a service request when all pending overlapped
commands are completed. This synchronizes the controller to the
completion of an overlapped command, but also leaves the controller
free to perform other tasks while the command is executing.
NOTE
*OPC only informs you when the NPO flag is set to 1. It does not hold off the processing of
subsequent commands. No commands should be sent to the analyzer between sending the *OPC
command and receiving the service request. Any command sent will be executed and may affect how
the instrument responds to the previously sent *OPC.
2-5
Synchronizing the Analyzer
and a Controller
The NPO Flag
The *CLS and *RST commands cancel any preceding *OPC command
or query. Pending overlapped commands are still completed, but their
completion is not reported in either the status register or the output queue.
Two HP-H3 bus management commands - Device Clear (DCL) and Selected
Device Clear (SDC) - also cancel any preceding *OPC command or query.
NOTE
Use *WAI, *OPC? or *OPC whenever overlapped commands are used. A recommended technique
is to send
*OPC? at the end of each group of commands.
ALWAYS trigger an individual sweep (using *OPC? and waiting for the
CAUTION
reply) before reading data over the bus or executing a marker function. The
analyzer has the ability to process the commands it. receives faster than it can
make a measurement,. lf the measurement is not complete when the data is
read or a marker search function is executed the results are invalid.
The command to use (in an IBASIC OUTPUT statement) is:
OUTPUT QHp87ll;"ABOR;:INIT:CONT OFF;:INIT;*OPC?"
ENTEROHp87ll;Opc-done
or another form of the : INITiate Cl I21 C: IMMediateI command combined
with the *OPC? query.
Refer to "%king Sweeps" in Chapter 6 for more information.
2-6
Synchronizing the Analyzer
and a Controller
The NPO Flag
Usage of *WA1 and *OPC?
l WAl The following example describes the use of the *WA1 command. For this
discussion, remember that a sequential command holds off the processing of
subsequent commands until it has been completely processed. An overlapped
command does not.
10 OUTPUT QRfna; "commandi"
20 OUTPUT (PRf na; "command2 ; *WAI"
30 OUTPUT QRfna;"command3;"
40 OUTPUT QRf na; "command4"
50 END
In the example above:
l Commands 1 through 4 are sent to the analyzer as fast as the HP-IB bus
traffic will allow, and the program may very well end before any command
has been completed.
l Command 1 begins execution first.
l The order in which commands 1 and 2 are completed depends on the
command types. If both commands are overlapped commands (versus
sequentid commands), the order of completion is unknown.
l Commands 3 and 4 will not be parsed until commands 1 and 2 are
completed.
l Command 3 will begin execution before command 4.
l The order in which commands 3 and 4 are ccnnpktm depends on the
command types. If both commands are overlapped commands (versus
sequential commands), the order of completion is unknown.
2-7
Synchronizing the Analyzer
and a Controller
*oPc? The following example describes the use of the *OPC? query and command.
For this discussion, remember that a sequential command holds off the
processing of subsequent commands until it has been completely processed.
An overlapped command does not.
10 OUTPUT ORfna; "commandi"
20 OUTPUT QRfna; "command2; *OPC?"
30 ENTER ORfna;Opc-done
40 OUTPUT (QRf na; "command3 ; I'
50 OUTPUT QRfna; "command4; *OPC?"
60 ENTER ORfna;Opc-done
70 END
In the example above:
l Commands 1 and 2 are sent to the analyzer as fast as the HP-IB bus traffic
will allow.
l Command 1 will begin execution before command 2.
l The order in which commands 1 and 2 are cowzpktm! depends on the
command types. If both commands are overlapped commands (versus
sequential commands), the order of completion is unknown.
l When commands 1 and 2 are completed, commands 3 and 4 will be sent to
the analyzer as fast as the HP-IB bus traffic will allow.
l Command 3 will begin execution before command 4.
l The order in which commands 3 and 4 are completed depends on the
command types. If both commands are overlapped commands (versus
sequential commands), the order of completion is unknown.
l This program will not end until the OPC in line 60 is returned.
2-8
3
Passing Control
Passing Control
When an external controller is connected to the analyzer with an HP-IB
cable, passing control may be needed to control devices such as printers and
plotters that are also connected on the HP-IB. For some operations the active
controller must pass control to the analyzer. When the analyzer completes
the operation, it automatically passes control of the bus back to the external
controller.
An example program, PASSCTRL, demonstrates passing control to the
analyzer. In this example program control is passed so the analyzer can
control a printer for hardcopy output. See Chapter 8, "Example Programs."
NOTE
Pass Control is not needed to control peripherals connected to the serial, parallel, or LAN ports.
I I
For smooth passing of control, take steps that ensure the following conditions
are met:
l The analyzer must know the controller's address so it can pass control
back.
l The controller must be informed when the analyzer passes control back.
3-2
Passing Control
The following is a procedure for passing control:
1. Send the controller's HP-IB address to the analyzer with the *PCB
command.
2. Clear the analyzer's status registers with the *CLS command.
3. Enable the analyzer's status registers to generate a service request when
the Operation Complete bit is set. (Send *ESE with a value of 1 and *SRE
with a value of 32.)
4. Enable the controller to respond to the service request.
5. Send the command that requires control of the bus followed by the *OPC
command.
6. Pass control to the analyzer and wait for the service request. The service
request indicates that the command has been completed and control has
been passed back to the controller.
NOTE
For this procedure to work properly, only the command that requires control of the bus should be
pending. Other overlapped commands should not. For more information on overlapped commands, see
Chapter 2, "Synchronizing the Analyzer and a Controller."
3-3
Passing Control
4
Data Types and Encoding
Data Types and Encoding
Data is transferred between the analyzer and a controller via the HP-IB data
lines, DIOl through DIOS. Such transfers occur in a byte-serial (one byte
at a time), bit-parallel (8 bits at a time) manner. This section discusses the
following aspects of data transfer:
l The different data types used during data transfers.
l Data encoding used during transfers of numeric block data.
4-2
Data Types
The analyzer uses a number of different data types during data transfers.
Data transfer occurs in response to a query. The data type used is determined
by the parameter being queried. The different parameter types are described
in the "Parameter Types" section of Chapter 10. Data types described in this
section are:
l Numeric Data.
l Character Data
l String Data
l Expression Data
l Block Data
Numeric Data
The analyzer returns three types of numeric data in response to queries:
NRl data Integers (such as + 1, 0, -1, 123, -12345). This is the
response type for boolean parameters as weII as some
numeric parameters.
NR2 data Floating point numbers with an explicit decimal point (such
as 12.3, +1.234, -0.12345).
NR3 data Floating point numbers in scientific notation (such as
+1.23E+5, +123.4E-3, -456.789E+6).
4-3
Data Types and Encoding
Data Types
Character Data
Character data consists of ASCII characters grouped together in mnemonics
that represent specific instrument settings (such as MAXimum , MINimum
or MLOGarithmic). The analyzer always returns the short form of the
mnemonic in upper-case alpha characters.
String Data
String data consists of ASCII characters. The string must be enclosed by a
delimiter, either single quotes (`This is string data. `) or double quotes
("This is also string data. `I). To include the delimiter as a character in
the string it must be typed twice without any characters in between. The
analyzer always uses double quotes when it returns string data.
Expression Data
Expression data consists of mathematical expressions that use character
parameters. When expression data is sent to the analyzer it is always
enclosed in parentheses (such as (IMPL/CHlSMEM) or (IMPL)). The analyzer
returns expression data enclosed in double quotes.
4-4
Data Types and Encoding
Data Types
Block Data
Block data are typically used to transfer large quantities of related data (like a
data trace). Blocks can be sent as deEnite length blocks or indefinite length
blocks - the instrument will accept either form. The analyzer always returns
definite length block data in response to queries.
Definite Block length The general form for a definite block length transfer is:
#Q-mm-digits>
ln the definite length block, two numbers must be specified. The single
decimal digit speciEes how many digits are contained in
. The decimal number bytes will follow in . An example IBASIC (or HP BASIC)
statement to send ABC+XYZ as a deEnite block length parameter is shown,
note that the data block contains seven bytes (7) and only one digit is needed
to describe the block length 1.
OUTPUT 716; "#17ABC+XYZ"
NOTE
This analyzer will send an additional cc~> with EOI asserted for definite block length transfers. The
definite length block form for your analyzer is:
#
is the number of without counting .
4-5
Data Types and Encoding
Data Types
indefinite Block length The general form for an indefinite block length transfer is:
After the last data byte is sent, the indehnite length block must be terminated
by sending a carriage return or newline with EOI asserted. This forces the
termination of the program message. An example IBASIC (or HP BASIC)
statement to send ABC+XYZ as an indeEnite block length parameter is shown,
note that ,END is used to properly terminate the message.
OUTPUT 716; "#OABC+XYZ" ,END
4-6
Data Encoding for Large Data Transfers
The FORMat :DATA command selects the type of data and the type of data
encoding that is used to transfer large blocks of numeric data between the
analyzer and a controller. There are two specifiers:
REAL specifies the block data type. Either the definite or indefinite
length syntax can be used. The block is transferred as
a series of binary-encoded floating-point numbers. Data
transfers of the REAL, 64 data type are demonstrated in the
REALDATA example program.
INTeger specifies the block data type. Either the detiite or indefinite
length syntax can be used. The block is transferred as an
array of binary-encoded data with each point represented
by a set of three 16-bit integers. This is the instrument's
internal format - it should only be used for data that will be
returned to the instrument for later use. Data transfers of
the INTeger, 16 data type are demonstrated in the INTDATA
and LOADCALS example programs.
ASCii specifies the numeric data type (NRl, NR2 or NR3 syntax).
The data is transferred as a series of ASCX-encoded numbers
separated by commas. ASCii formatted data transfers are
demonstrated in the ASCDATA example program.
Blocks that contain mixed data - both numbers and ASCII characters -
ignore the setting of FORMat :DATA. These blocks always transfer as either
definite length or indefinite length block data. The following commands
transfer blocks of mixed data:
PROGram[:SELectedl :DEFine
SYSTem:SET
4-7
Data Types and Encoding
Data Encoding for large Data Transfers
ASCII Encoding
The ANSI X3.4-1977 standard dehnes the ASCII 7-bit code. When an
ASCII-encoded byte is sent over the HP-IB, bits 0 through 6 of the byte
(bit 0 being the least signihcant bit) correspond to the HP-IB data lines DIOl
through D107. D108 is ignored.
When ASCII encoding is used for large blocks of data, the number of
significant digits to be returned for each number in the block can be specitied.
For example, the following command returns all numbers as NR3 data with 7
significant digits.
FORMat:DATAASCii,7
Binary Encoding
When binary encoding is used for large blocks of data, all numbers in the
block are transferred as 32-bit or 64-bit binary floating point numbers or as
an array of 16-bit integers. The binary floating-point formats are defined in
the IEEE 754-1985 standard.
FORMat:DATAREAL,32 selects the IEEE 32&t format (not sup-
ported by BASIC or HP BASIC).
FORMat:DATAREAL,64 selects the IEEE 64&t format.
FORMat : DATA INTeger ,16 selects the 16&t integer format.
4-8
Data Types and Encoding
Byte Swapping
PC compatibles frequently use a modification of the IEEE floating point
formats with the byte order reversed. To reverse the byte order for data
transfer into a PC, the FORMat :BORDer command should be used.
FORMat : BORDer SWAPped selects the byte-swapped format
FORMat : BORDer NORMal selects the standard format
4-9
Data Types and Encoding
Using Status Registers
Using Status Registers
The analyzer's status registers contain information about the condition of the
network analyzer and its measurements. This section describes the registers
and their use in HP-lB programming.
Example programs using the status registers are included in Chapter 8,
"Example Programs. ' These programs include SRQ and GRAPHICS which
use service request interrupt routines, PASSCTRL which uses the status byte
to request control of the HP-lB and LIMITEST which uses the Limit Fail
condition register.
5-2
General Status Register Model
The analyzer's status system is based on the general status register model
shown in Figure 5-l. Most of the analyzer's register sets include all of the
registers shown in the model, although commands are not always available
for reading or writing a particular register. The information flow within a
register set starts at the condition register and ends at the register summary
bit (see Figure 5-2). This flow is controlled by setting bits in the transition
and enable registers.
Two register sets - the Status Byte and the Standard Event Status
Register - are S-bits wide. All others are 16-bits wide, but the most
signihcant bit (bit 15) in the larger registers is always set to 0.
Condition Register ( STATus: Posltlve Transltlon Filter ( STATus:
r
N e g a t i v e Transltlon Filter ( STATus::NTRansltlon )
Event Register ( STATus:l:EVENtl? )
Bit Weights r E n a b l e Register 1 STATus:
Bit 0 condition
: Bit 1 condltton
4 Bit 2 condltlon
8
16
32
64
128 >-+ T o S u m m a r y B i t
256
512
1.024
2.048
4,096
8,192
16.384
32,768 B i t 15
Figure 5-l. General Status Register Model
5-3
Using Status Registers
General Status Register Model
Condition Register
Condition registers continuously monitor the instrument's hardware and
firmware status. Bits in a condition register are not latched or buffered, they
are updated in real time. When the condition monitored by a specific bit
becomes true, the bit is set to 1. When the condition becomes false the bit is
reset to 0. Condition registers are read-only.
Transition Registers
Transition registers control what type of change in a condition register will
set the corresponding bit in the event registe