This reference applies directly to software revision code 3.00 and later.
Copyright Agilent Technologies 2010
All Rights Reserved.
90000A/90000X Series Infiniium
Oscilloscopes
In This Book
This book is your guide to programming the Infiniium 90000A and 90000X Series
Oscilloscopes.
Chapters 1 through 5 give you an introduction to programming the oscilloscopes,
along with necessary conceptual information. These chapters describe basic program
communications, interface, syntax, data types, and status reporting.
Chapter 6 shows example BASIC and C programs, and describes chunks of one
program to show you some typical applications. The BASIC and C example programs
are also shipped on a disk with the oscilloscope.
The next chapters describe the commands used to program the oscilloscopes. Each
chapter describes the set of commands that belong to an individual subsystem, and
explains the function of each command.
The last chapter describes error messages.
ii
Contents
1 Introduction to Programming
Communicating with the Oscilloscope1-3
Output Command1-4
Device Address1-4
Instructions1-4
Instruction Header1-4
White Space (Separator)1-5
Braces1-5
Ellipsis1-5
Square Brackets1-5
Command and Query Sources1-5
Program Data1-6
Header Types1-7
Duplicate Mnemonics1-9
Query Headers1-10
Program Header Options1-11
Character Program Data1-11
Numeric Program Data1-12
Embedded Strings1-13
Program Message Terminator1-13
Common Commands within a Subsystem1-14
Selecting Multiple Subsystems1-14
Programming Getting Started1-14
Initialization1-15
Example Program using HP Basic1-16
Using the DIGITIZE Command1-17
Receiving Information from the Oscilloscope1-19
String Variable Example1-20
Numeric Variable Example1-20
Definite-Length Block Response Data1-21
Multiple Queries1-22
Oscilloscope Status1-22
2 Connectivity
LAN Interface Connector2-3
GPIB Interface Connector2-3
Default Startup Conditions2-4
Interface Capabilities2-5
GPIB Command and Data Concepts2-6
Communicating Over the GPIB Interface2-7
Communicating Over the LAN Interface2-8
Communicating via Telnet and Sockets2-10
Bus Commands2-12
3 Message Communication and System Functions
Contents-1
Contents
Protocols3-3
4 Status Reporting
Status Reporting Data Structures4-5
Status Byte Register4-8
Service Request Enable Register4-10
Message Event Register4-10
Trigger Event Register4-10
Standard Event Status Register4-11
Standard Event Status Enable Register4-12
Operation Status Register4-13
Operation Status Enable Register4-14
Mask Test Event Register4-15
Mask Test Event Enable Register4-16
Acquisition Done Event Register4-17
Process Done Event Register4-17
Trigger Armed Event Register4-17
Auto Trigger Event Register4-17
Error Queue4-18
Output Queue4-18
Message Queue4-19
Clearing Registers and Queues4-19
5 Remote Acquisition Synchronization
Introduction5-2
Programming Flow5-2
Setting Up the Oscilloscope5-2
Acquiring a Waveform5-2
Retrieving Results5-3
Acquisition Synchronization5-3
Single Shot Device Under Test (DUT)5-5
Averaging Acquisition Synchronization5-6
6 Programming Conventions
Truncation Rule6-3
The Command Tree6-4
Infinity Representation6-12
Sequential and Overlapped Commands6-12
Response Generation6-12
EOI6-12
7 Sample Programs
Sample Program Structure 7-3
Sample C Programs 7-4
Listings of the Sample Programs 7-14
gpibdecl.h Sample Header7-15
Contents-2
learnstr.c Sample Program 7-17
sicl_IO.c Sample Program 7-21
natl_IO.c Sample Program 7-2 6
init.bas Sample Program7-30
lrn_str.bas Sample Program7-38
Execution Error 31-6
Device- or Oscilloscope-Specific Error 31-7
Query Error 31-8
List of Error Messages 31-9
Contents
Contents-17
Contents
Contents-18
1
Introduction to Programming
Introduction to Programming
This chapter introduces the basics for remote programming of an oscilloscope.
The programming commands in this manual conform to the IEEE 488.2
Standard Digital Interface for Programmable Instrumentation. The
programming commands provide the means of remote control.
Basic operations that you can do with a computer and an oscilloscope include:
• Set up the oscilloscope.
• Make measurements.
• Get data (waveform, measurements, and configuration) from the
oscilloscope.
• Send information, such as waveforms and configurations, to the
oscilloscope.
You can accomplish other tasks by combining these functions.
Example Programs are Written in HP BASIC and C
The programming examples for individual commands in this manual are
written in HP BASIC and C.
1-2
Introduction to Programming
Communicating with the Oscilloscope
Communicating with the Oscilloscope
Computers communicate with the oscilloscope by sending and receiving messages
over a remote interface, such as a GPIB card or a Local Area Network (LAN) card.
Commands for programming normally appear as ASCII character strings embedded
inside the output statements of a “host” language available on your computer. The
input commands of the host language are used to read responses from the oscilloscope.
For example, HP BASIC uses the OUTPUT statement for sending commands and
queries. After a query is sent, the response is usually read using the HP BASIC
ENTER statement. The ENTER statement passes the value across the bus to the
computer and places it in the designated variable.
For the GPIB interface, messages are placed on the bus using an output command and
passing the device address, program message, and a terminator. Passing the device
address ensures that the program message is sent to the correct GPIB interface and
GPIB device.
The following HP BASIC OUTPUT statement sends a command that sets the channel
1 scale value to 500 mV:
The device address represents the address of the device being programmed. Each of
the other parts of the above statement are explained on the following pages.
Use the Suffix Multiplier Instead
Using "mV" or "V" following the numeric voltage value in some commands
will cause Error 138 - Suffix not allowed. Instead, use the convention for the
suffix multiplier as described in chapter 3, "Message Communication and
System Functions."
1-3
Introduction to Programming
Output Command
Output Command
The output command depends entirely on the programming language. Throughout
this book, HP BASIC and ANSI C are used in the examples of individual commands.
If you are using other languages, you will need to find the equivalents of HP BASIC
commands like OUTPUT, ENTER, and CLEAR, to convert the examples.
Device Address
The location where the device address must be specified depends on the programming
language you are using. In some languages, it may be specified outside the OUTPUT
command. In HP BASIC, it is always specified after the keyword, OUTPUT. The
examples in this manual assume that the oscilloscope and interface card are at GPIB
device address 707. When writing programs, the device address varies according to
how the bus is configured.
Instructions
Instructions, both commands and queries, normally appear as strings embedded in a
statement of your host language, such as BASIC, Pascal, or C. The only time a
parameter is not meant to be expressed as a string is when the instruction's syntax
definition specifies <block data>, such as HP BASIC’s "learnstring" command. There
are only a few instructions that use block data.
Instructions are composed of two main parts:
• The header, which specifies the command or query to be sent.
• The program data, which provides additional informatio n to clarify the meaning
of the instruction.
Instruction Header
The instruction header is one or more command mnemonics separated by colons (:).
They represent the operation to be performed by the oscilloscope. See the
“Programming Conventions” chapter for more information.
Queries are formed by adding a question mark (?) to the end of the header. Many
instructions can be used as either commands or queries, depending on whether or not
you include the question mark. The command and query forms of an instruction
usually have different program data. Many queries do not use any program data.
1-4
Introduction to Programming
White Space (Separator)
White Space (Separator)
White space is used to separate the instruction header from the program data. If the
instruction does not require any program data parameters, you do not need to include
any white space. In this manual, white space is defined as one or more spaces. ASCII
defines a space to be character 32 in decimal.
Braces
When several items are enclosed by braces, { }, only one of these elements may be
selected. Vertical line ( | ) indicates "or". For example, {ON | OFF} indicates that
only ON or OFF may be selected, not both.
Ellipsis
... An ellipsis (trailing dots) indicates that the preceding element may be repeated one
or more times.
Square Brackets
Items enclosed in square brackets, [ ], are optional.
Command and Query Sources
Many commands and queries require that a source be specified. Depending on the
command or query and the model number of Infiniium oscilloscope being used, some
of the sources are not available. The following is a list of sources:
Program data is used to clarify the meaning of the command or query. It provides
necessary information, such as whether a function should be on or off, or which
waveform is to be displayed. Each instruction's syntax definition shows the program
data and the values they accept.
When there is more than one data parameter, they are s eparated by commas (,). You
can add spaces around the commas to improve readability.
1-6
Introduction to Programming
Header Types
Header Types
There are three types of headers:
• Simple Command headers
• Compound Command headers
• Common Command headers
Simple Command Header
Simple command headers contain a single mnemonic. AUTOSCALE and DIGITIZE
are examples of simple command headers typically used in this oscilloscope. The
syntax is:
<program mnemonic><terminator>
or
OUTPUT 707;”:AUTOSCALE”
When program data must be included with the simple command header
(for example, :DIGITIZE CHAN1), white space is added to separate the data from
the header. The syntax is:
Compound command headers are a combination of two program mnemonics. The
first mnemonic selects the subsystem, and the second mnemonic selects the function
within that subsystem. The mnemonics within the compound message are separated
by colons. For example:
Common command headers, such as clear status, control the IEEE 488.2 functions
within the oscilloscope. The syntax is:
*<command header><terminator>
No space or separator is allowed between the asterisk (*) and the command header.
*CLS is an example of a common command header.
1-8
Introduction to Programming
Duplicate Mnemonics
Duplicate Mnemonics
Identical function mnemonics can be used for more than one subsystem. For example,
you can use the function mnemonic RANGE to change both the vertical range and
horizontal range:
To set the vertical range of channel 1 to 0.4 volts full scale:
:CHANNEL1:RANGE .4
To set the horizontal time base to 1 second full scale:
:TIMEBASE:RANGE 1
In these examples, CHANNEL1 and TIMEBASE are subsystem selectors, and
determine the range type being modified.
1-9
Introduction to Programming
Query Headers
Query Headers
A command header immediately followed by a question mark (?) is a query. After
receiving a query, the oscilloscope interrogates the requested subsystem and places
the answer in its output queue. The answer remains in the output queue until it is read
or until another command is issued. When read, the answer is transmitted across the
bus to the designated listener (typically a computer). For example, the query:
:TIMEBASE:RANGE?
places the current time base setting in the output queue.
In HP BASIC, the computer input statement:
ENTER < device address > ;Range
passes the value across the bus to the computer and places it in the variable Range.
You can use queries to find out how the oscilloscope is currently configured and to
get results of measurements made by the oscilloscope.
For example, the command:
:MEASURE:RISETIME?
tells the oscilloscope to measure the rise time of your waveform and place the result
in the output queue.
The output queue must be read before the next program message is sent. For example,
when you send the query :MEASURE:RISETIME?, you must follow it with an input
statement. In HP BASIC, this is usually done with an ENTER statement immediately
followed by a variable name. This statement reads the result of the query and places
the result in a specified variable.
Handle Queries Properly
If you send another command or query before reading the result of a query,
the output buffer is cleared and the current response is lost. This also generates
a query-interrupted error in the error queue. If you execute an input statement
before you send a query, it will cause the computer to wait indefinitely.
1-10
Introduction to Programming
Program Header Options
Program Header Options
You can send program headers using any combination of uppercase or lowercase
ASCII characters. Oscilloscope responses, however, are always returned in
uppercase.
You may send program command and qu ery headers in either long form (complete
spelling), short form (abbreviated spelling), or any combination of long form and short
form. For example:
:TIMEBASE:DELAY 1E-6 is the long form.
:TIM:DEL 1E-6 is the short form.
Using Long Form or Short Form
Programs written in long form are easily read and are almost self-documenting.
The short form syntax conserves the amount of computer memory needed for
program storage and reduces I/O activity.
The rules for the short form syntax are described in the chapter, “Programming
Conventions.”
Character Program Data
Character program data is used to convey parameter information as alpha or
alphanumeric strings. For example, the :TIMEBASE:REFERENCE command can
be set to left, center, or right. The character program data in this case may be LEFT,
CENTER, or RIGHT. The command :TIMEBASE:REFERENCE RIGHT sets the
time base reference to right.
The available mnemonics for character program data are always included with the
instruction's syntax definition. You may send either the long form of commands, or
the short form (if one exists). You may mix uppercase and lowercase letters freely.
When receiving responses, uppercase letters are used exclusively.
1-11
Introduction to Programming
Numeric Program Data
Numeric Program Data
Some command headers require program data to be expressed numerically. For
example, :TIMEBASE:RANGE requires the desired full-scale range to be expressed
numerically.
For numeric program data, you can use exponential notation or suffix multipliers to
indicate the numeric value. The following numbers are all equal:
28 = 0.28E2 = 280E-1 = 28000m = 0.028K = 28E-3K
When a syntax definition specifies that a number is an integer, it means that the number
should be whole. Any fractional part is ignored and truncated. Numeric data
parameters that accept fractional values are called real numbers. For more information
see the chapter, “Interface Functions.”
All numbers are expected to be strings of ASCII characters.
• When sending the number 9, you would send a byte representing the ASCII
code for the character “9” (which is 57).
• A three-digit number like 102 would take up three bytes (ASCII codes 49, 48,
and 50). The number of bytes is figured automatically when you include the
entire instruction in a string.
1-12
Introduction to Programming
Embedded Strings
Embedded Strings
Embedded strings contain groups of alphanumeric characters which are treated as a
unit of data by the oscilloscope. An example of this is the line of text written to the
advisory line of the oscilloscope with the :SYSTEM:DSP command:
:SYSTEM:DSP ""This is a message.""
Y ou may delimit embedded strings with either single (') or double (") quotation marks.
These strings are case-sensitive, and spaces are also legal characters.
Program Message Terminator
The program instructions within a data message are executed after the program
message terminator is received. The terminator may be either an NL (New Line)
character, an EOI (End-Or-Identify) asserted in the GPIB interface, or a combination
of the two. Asserting the EOI sets the EOI control line low on the last byte of the data
message. The NL character is an ASCII linefeed (decimal 10).
New Line Terminator Functions Like EOS and EOT
The NL (New Line) terminator has the same function as an EOS (End Of String)
and EOT (End Of Text) terminator.
1-13
Introduction to Programming
Common Commands within a Subsystem
Common Commands within a Subsystem
Common commands can be received and processed by the oscilloscope whether they
are sent over the bus as separate program messages or within other program messages.
If you have selected a subsystem, and a common command is received by the
oscilloscope, the oscilloscope remains in the selected subsystem. For example, if the
program message
":ACQUIRE:AVERAGE ON;*CLS;COUNT 1024"
is received by the oscilloscope, the oscilloscope turns averaging on, then clears the
status information without leaving the selected subsystem.
If some other type of command is received within a program message, you must reenter the original subsystem after the command. For example, the program message
turns averaging on, completes the autoscale operation, then sets the acquire average
count. Here, :ACQUIRE must be sent again after AUTOSCALE to re-enter the
ACQUIRE subsystem and set the count.
Selecting Multiple Subsystems
You can send multiple program commands and program queries for different
subsystems on the same line by separating each command with a semicolon. The
colon following the semicolon lets you enter a new subsystem. For example:
You can Combine Compound and Simple Commands
Multiple program commands may be any combination of compound and simple
commands.
Programming Getting Started
The remainder of this chapter explains how to set up the oscilloscope, how to retrieve
setup information and measurement results, how to digitize a waveform, and how to
pass data to the computer. The chapter, “Measure Commands” describes sending
measurement data to the oscilloscope.
1-14
Introduction to Programming
Initialization
Initialization
T o make sure the bus and all appropriate interfaces are in a known state, begin every
program with an initialization statement. For example, HP BASIC provides a CLEAR
command which clears the interface buffer:
CLEAR 707 ! initializes the interface of the oscilloscope
When you are using GPIB, CLEAR also resets the oscilloscope's parser . The parser
is the program that reads in the instructions you send.
After clearing the interface, initialize the oscilloscope to a preset state:
OUTPUT 707;"*RST" ! initializes the oscilloscope to a preset
state
Initializing the Oscilloscope
The commands and syntax for initializing the oscilloscope are discussed in the
chapter, “Common Commands.” Refer to your GPIB manual and
programming language reference manual for information on initializing the
interface.
Autoscale
The AUTOSCALE feature of Agilent T echnologies digitizing oscilloscopes performs
a very useful function on unknown waveforms by automatically setting up the vertical
channel, time base, and trigger level of the oscilloscope.
The syntax for the autoscale function is:
:AUTOSCALE<terminator>
Setting Up the Oscilloscope
A typical oscilloscope setup configures the vertical range and offset voltage, the
horizontal range, delay time, delay reference, trigger mode, trigger level, and slope.
A typical example of the commands sent to the oscilloscope are:
:CHANNEL1:PROBE 10; RANGE 16;OFFSET 1.00<terminator>
:SYSTEM:HEADER OFF<terminator>
:TIMEBASE:RANGE 1E-3;DELAY 100E-6<terminator>
This example sets the time base at 1 ms full-scale (100 s/div), with delay of 100 s.
Vertical is set to 16 V full-scale (2 V/div), with center of screen at 1 V, and probe
attenuation of 10.
1-15
Introduction to Programming
Example Program using HP Basic
Example Program using HP Basic
This program demonstrates the basic command structure used to program the
oscilloscope.
10 CLEAR 707! Initialize oscilloscope interface
20 OUTPUT 707;"*RST"!Initialize oscilloscope to preset state
30 OUTPUT 707;":TIMEBASE:RANGE 5E-4"! Time base to 500 us full scale
40 OUTPUT 707;":TIMEBASE:DELAY 0"! Delay to zero
50 OUTPUT 707;":TIMEBASE:REFERENCE CENTER"! Display reference at center
60 OUTPUT 707;":CHANNEL1:PROBE 10"! Probe attenuation to 10:1
70 OUTPUT 707;":CHANNEL1:RANGE 1.6"! Vertical range to 1.6 V full scale
80 OUTPUT 707;":CHANNEL1:OFFSET -.4"! Offset to -0.4
90 OUTPUT 707;":CHANNEL1:INPUT DC"! Coupling to DC
100 OUTPUT 707;":TRIGGER:MODE EDGE"! Edge triggering
110 OUTPUT 707;":TRIGGER:LEVEL CHAN1,-.4"! Trigger level to -0.4
120 OUTPUT 707;":TRIGGER:SLOPE POSITIVE"! Trigger on positive slope
125 OUTPUT 707;":SYSTEM:HEADER OFF<terminator>
130 OUTPUT 707;":ACQUIRE:MODE RTIME"! Normal acquisition
140 OUTPUT 707;":DISPLAY:GRATICULE FRAME"! Grid off
150 END
Overview of the Program
• Line 10 initializes the oscilloscope interface to a known state.
• Line 20 initializes the oscilloscope to a preset state.
• Lines 30 through 50 set the time base, the horizontal time at 500 s full scale, and
0 s of delay referenced at the center of the graticule.
• Lines 60 through 90 set 10:1 probe attenuation, set the vertical range to 1.6 volts
full scale, center screen at0.4 volts, and select DC 1 Mohm impedance coupling.
• Lines 100 through 120 configure the oscilloscope to trigger at 0.4 volts with
positive edge triggering.
• Line 125 turns system headers off.
• Line 130 configures the oscilloscope for real time acquisition.
• Line 140 turns the grid off.
1-16
Introduction to Programming
Using the DIGITIZE Command
Using the DIGITIZE Command
The DIGITIZE command is a macro that captures data using the acquisition
(ACQUIRE) subsystem. When the digitize process is complete, the acquisition is
stopped. You can measure the captured data by using the oscilloscope or by
transferring the data to a computer for further analysis. The captured data consists of
two parts: the preamble and the waveform data record.
After changing the oscilloscope configuration, the waveform buffers are cleared.
Before doing a measurement, you should send the DIGITIZE command to ensure new
data has been collected.
You can send the DIGITIZE command with no parameters for a higher throughput.
Refer to the DIGITIZE command in the chapter, “Root Level Commands” for details.
When the DIGITIZE command is sent to an oscilloscope, the specified channel’s
waveform is digitized using the current ACQUIRE parameters. Before sending the
:WAVEFO R M:DATA? query to download waveform data to your com puter, you
should specify the WAVEFORM parameters.
The number of data points comprising a waveform varies according to the number
requested in the ACQUIRE subsystem. The ACQUIRE subsystem determines the
number of data points, type of acquisition, and number of averages used by the
DIGITIZE command. This lets you specify exactly what the digitized information
contains. The following program example shows a typical setup:
This setup places the oscilloscope into the real time sampling mode using eight
averages. This means that when the DIGITIZE command is received, the command
will execute until the waveform has been averaged at least eight times.
After receiving the :WAVEFORM:DATA? query, the oscilloscope will start
downloading the waveform information.
Digitized waveforms are passed from the oscilloscope to the computer by sending a
numerical representation of each digitized point. The format of the numerical
representation is controlled by using the :W A VEFORM:FORMA T command and may
be selected as BYTE, WORD, or ASCII.
1-17
Introduction to Programming
Using the DIGITIZE Command
The easiest method of receiving a digitized waveform depends on data structures,
available formatting, and I/O capabilities. You must convert the data values to
determine the voltage value of each point. These data values are passed starting with
the left most point on the oscilloscope's display. For more information, refer to the
chapter, “Waveform Commands.”
When using GPIB, you may abort a digitize operation by sending a Device Clear over
the bus (for example, CLEAR 707).
1-18
Introduction to Programming
Receiving Information from the Oscilloscope
Receiving Information from the Oscilloscope
After receiving a query (a command header followed by a question mark), the
oscilloscope places the answer in its output queue. The answer remains in the output
queue until it is read or until another command is issued. When read, the answer is
transmitted across the interface to the computer. The input statement for receiving a
response message from an oscilloscope's output queue typically has two parameters;
the device address and a format specification for handling the response message. For
example, to read the result of the query command :CHANNEL1:INPUT? you would
execute the HP BASIC statement:
ENTER <device address> ;Setting$
This would enter the current setting for the channel 1 coupling in the string variable
Setting$. The device address parameter represents the address of the oscilloscope.
All results for queries sent in a program message must be read before another program
message is sent. For example, when you send the query :MEASURE:RISETIME?,
you must follow that query with an input statement. In HP BASIC, this is usually
done with an ENTER statement.
Handle Queries Properly
If you send another command or query before reading the result of a query,
the output buffer will be cleared and the current response will be lost. This will
also generate a query-interrupted error in the error queue. If you execute an
input statement before you send a query, it will cause the computer to wait
indefinitely.
The format specification for handling response messages depends on both the
computer and the programming language.
1-19
Introduction to Programming
String Variable Example
String Variable Example
The output of the oscilloscope may be numeric or character data depending on what
is queried. Refer to the specific commands for the formats and types of data returned
from queries.
For the example programs, assume that the device being programmed is at device
address 707. The actual address depends on how you have configured the bus for
your own application.
In HP BASIC 5.0, string variables are case-sensitive, and must be expressed exactly
the same each time they are used. This example shows the data being returned to a
string variable:
10 DIM Rang$[30]
20 OUTPUT 707;":CHANNEL1:RANGE?"
30 ENTER 707;Rang$
40 PRINT Rang$
50 END
After running this program, the computer displays:
+8.00000E-01
Numeric Variable Example
This example shows the data being returned to a numeric variable:
10 OUTPUT 707;":CHANNEL1:RANGE?"
20 ENTER 707;Rang
30 PRINT Rang
40 END
After running this program, the computer displays:
.8
1-20
Introduction to Programming
Definite-Length Block Response Data
Definite-Length Block Response Data
Definite-length block response data allows any type of device-dependent data to be
transmitted over the system interface as a series of 8-bit binary data bytes. This is
particularly useful for sending large quantities of data or 8-bit extended ASCII codes.
The syntax is a pound sign ( # ) followed by a non-zero digit representing the number
of digits in the decimal integer. After the non-zero digit is the decimal integer that
states the number of 8-bit data bytes being sent. This is followed by the actual data.
For example, for transmitting 4000 bytes of data, the syntax would be:
#44000 <4000 bytes of data> <terminator>
The “4” following the pound sign represents the number of digits in the number of
bytes, and “4000” represents the number of bytes to be transmitted.
1-21
Introduction to Programming
Multiple Queries
Multiple Queries
You can send multiple queries to the oscilloscope within a single program message,
but you must also read them back within a single program message. This can be
accomplished by either reading them back into a string variable or into multiple
numeric variables. For example, you could read the result of the query
:TIMEBASE:RANGE?;DELA Y? into the string variable Results$ with the command:
ENTER 707;Results$
When you read the result of multiple queries into string variables, each response is
separated by a semicolon. For example, the response of the query
:TIMEBASE:RANGE?;DELAY? would be:
<range_value>;<delay_value>
Use the following program message to read the query
:TIMEBASE:RANGE?;DELAY? into multiple numeric variables:
ENTER 707;Result1,Result2
Oscilloscope Status
Status registers track the current status of the oscilloscope. By checking the
oscilloscope status, you can find out whether an operation has completed and is
receiving triggers. The chapter, “Status Reporting” explains how to check the status
of the oscilloscope.
1-22
2
Connectivity
LAN, USB, and GPIB Interfaces
There are several types of interfaces that can be used to remotely program the
Infiniium oscilloscope including Local Area Network (LAN) interface and
GPIB interface. Telnet and sockets can also be used to connect to the
oscilloscope.
2-2
Connectivity
LAN Interface Connector
LAN Interface Connector
The oscilloscope is equipped with a LAN interface RJ-45 connector on the rear panel.
This allows direct connect to your network. However, before you can use the LAN
interface to program the oscilloscope, the network properties must be configured.
Unless you are a Network Administrator, you should contact your Network
Administrator to add the appropriate client, protocols, and configuration information
for your LAN. This information is different for every company.
GPIB Interface Connector
The oscilloscope is equipped with a GPIB interface connector on the rear panel. This
allows direct connection to a GPIB equipped computer . You can connect an external
GPIB compatible device to the oscilloscope by installing a GPIB cable between the
two units. Finger tighten the captive screws on both ends of the GPIB cable to avoid
accidentally disconnecting the cable during operation.
A maximum of fifteen GPIB compatible instruments (including a computer) can be
interconnected in a system by stacking connectors. This allows the oscilloscopes to
be connected in virtually any configuration, as long as there is a path from the
computer to every device operating on the bus.
CAUTIONAvoid stacking more than three or four cables on any one connector. Multiple
connectors produce leverage that can damage a connector mounting.
2-3
Connectivity
Default Startup Conditions
Default Startup Conditions
The following default conditions are established during power-up:
• The Request Service (RQS) bit in the status byte register is set to zero.
• All of the event registers are cleared.
• The Standard Event Status Enable Register is set to 0xFF hex.
• Service Request Enable Register is set to 0x80 hex.
• The Operation Status Enable Register is set to 0xFFFF hex.
• The Overload Event Enable Register is set to 0xFF hex.
• The Mask Test Event Enable Register is set to 0xFF hex.
Y ou can change the default conditions using the *PSC command with a parameter of
1 (one). When set to 1, the Standard Event Status Enable Register is set 0x00 hex and
the Service Request Enable Register is set to 0x00 hex. This prevents the Power On
(PON) event from setting the SRQ interrupt when the oscilloscope is ready to receive
commands.
2-4
Connectivity
Interface Capabilities
Interface Capabilities
The interface capabilities of this oscilloscope, as defined by IEEE 488.1 and IEEE
The GPIB interface has two modes of operation: command mode and data mode. The
interface is in the command mode when the Attention (ATN) control line is true. The
command mode is used to send talk and listen addresses and various interface
commands such as group execute trigger (GET).
The interface is in the data mode when the ATN line is false. The data mode is used
to convey device-dependent messages across the bus. The device-dependent
messages include all of the oscilloscope-specific commands, queries, and responses
found in this manual, including oscilloscope status information.
2-6
Connectivity
Communicating Over the GPIB Interface
Communicating Over the GPIB Interface
Device addresses are sent by the computer in the command mode to specify who talks
and who listens. Because GPIB can address multiple devices through the same
interface card, the device address passed with the program message must include the
correct interface select code and the correct oscilloscope address.
The Oscilloscope is at Address 707 for Programming Examples
The programming examples in this manual assume that the oscilloscope is at
device address 707.
Interface Select Code
Each interface card has a unique interface select code. This code is used by the
computer to direct commands and communications to the proper interface. The
default is typically “7” for the GPIB interface cards.
Oscilloscope Address
Each oscilloscope on the GPIB must have a unique oscilloscope address between
decimal 0 and 30. This oscilloscope address is used by the computer to direct
commands and communications to the proper oscilloscope on an interface. The
default is typically “7” for this oscilloscope. Y ou can change the oscilloscope address
in the Utilities, Remote Interface dialog box.
Do Not Use Address 21 for an Oscilloscope Address
Address 21 is usually reserved for the Computer interface Talk/Listen address,
and should not be used as an oscilloscope address.
2-7
Connectivity
LAN Address
Communicating Over the LAN Interface
Communicating Over the LAN Interface
The device address used to send commands and receive data using the LAN interface
is located in the GPIB Setup dialog box as shown below.
GPIB Setup Dialog Box
The following C example program shows how to communicate with the oscilloscope
using the LAN interface and the Agilent Standard Instrument Control Library (SICL).
#include <sicl.h>
#define BUFFER_SIZE 1024
main()
{
INST Bus;
int reason;
unsigned long actualcnt;
char buffer[ BUFFER_SIZE ];
/* Open the LAN interface */
Bus = iopen( “lan[130.29.71.143]:hpib7,7” );
if( Bus != 0 ) {
/* Bus timeout set to 20 seconds */
itimeout( Bus, 20000 );
/* Clear the interface */
iclear( Bus );
/* Query and print the oscilloscope’s Id */
iwrite( Bus, “*IDN?”, 5, 1, &actualcnt );
iread( Bus, buffer, BUFFER_SIZE, &reason, &actualcnt );
buffer[ actualcnt - 1 ] = 0;
2-8
printf( “%s\n”, buffer );
iclose( Bus );
}
}
Connectivity
Communicating Over the LAN Interface
2-9
Connectivity
Communicating via Telnet and Sockets
Communicating via Telnet and Sockets
Telnet
To open a connection to the oscilloscope via a telnet connection, use the following
syntax in a command prompt:
telnet Oscilloscope_IP_Address 5024
5024 is the port number and the name of the oscilloscope can be used in place of the
IP address if desired.
After typing the above command line, press enter and a SCPI command line interface
will open. You can then use this as you typically would use a command line.
Sockets
Sockets can be used to connect to your oscilloscope on either a Windows or Unix
machine.
The sockets are located on port 5025 on your oscilloscope. Between ports 5024 and
5025, only six socket ports can be opened simultaneously. It is, therefore, important
that you use a proper close routine to close the connection to the oscilloscope. If you
forget this, the connection will remain open and you may end up exceeding the limit
of six socket ports.
Some basic commands used in communicating to your oscilloscope include:
• The receive command is: recv
• The send command is: send
2-10
Connectivity
Communicating via Telnet and Sockets
Below is a programming example (for a Windows-based machine) for opening and
closing a connection to your oscilloscope via sockets.
#include <winsock2.h>
Void main ()
{
WSADATA wsaData;
SOCKET mysocket = NULL;
char* ipAddress = “130.29.70.70”;
const int ipPort = 5025;
//Initialize Winsock
int iResult = WSAStartup(MAKEWORD(2,2), &wsaData);
if(iResult != NO_ERROR)
{
printf(“Error at WSAStartup()\n”);
return NULL;
}
//Close socket when finished
closesocket(mySocket);
}
2-11
Connectivity
Bus Commands
Bus Commands
The following commands are IEEE 488.1 bus commands (ATN true). IEEE 488.2
defines many of the actions that are taken when these commands are received by the
oscilloscope.
Device Clear
The device clear (DCL) and selected device clear (SDC) commands clear the input
buffer and output queue, reset the parser, and clear any pending commands. If either
of these commands is sent during a digitize operation, the digitize operation is aborted.
Group Execute Trigger
The group execute trigger (GET) command arms the trigger. This is the same action
produced by sending the RUN command.
Interface Clear
The interface clear (IFC) command halts all bus activity . This includes unaddressing
all listeners and the talker, disabling serial poll on all devices, and returning control
to the system computer.
2-12
3
Message Communication and System
Functions
Message Communication and System
Functions
This chapter describes the operation of oscilloscopes that operate in
compliance with the IEEE 488.2 (syntax) standard. It is intended to give you
enough basic information about the IEEE 488.2 standard to successfully
program the oscilloscope. You can find additional detailed information about
the IEEE 488.2 standard in ANSI/IEEE Std 488.2-1987, “IEEE Standard
Codes, Formats, Protocols, and Common Commands.”
This oscilloscope series is designed to be compatible with other Agilent
Technologies IEEE 488.2 compatible instruments. Oscilloscopes that are
compatible with IEEE 488.2 must also be compatible with IEEE 488.1 (GPIB
bus standard); however, IEEE 488.1 compatible oscilloscopes may or may not
conform to the IEEE 488.2 standard. The IEEE 488.2 standard defines the
message exchange protocols by which the oscilloscope and the computer will
communicate. It also defines some common capabilities that are found in all
IEEE 488.2 oscilloscopes.
This chapter also contains some information about the message
communication and system functions not specifically defined by IEEE 488.2.
3-2
Message Communication and System Functions
Protocols
Protocols
The message exchange protocols of IEEE 488.2 define the overall scheme used by
the computer and the oscilloscope to communicate. This includes defining when it
is appropriate for devices to talk or listen, and what happens when the protocol is not
followed.
Functional Elements
Before proceeding with the description of the protocol, you should understand a few
system components, as described here.
Input Buffer The input buffer of the oscilloscope is the memory
area where commands and queries are stored prior
to being parsed and executed. It allows a computer
to send a string of commands, which could take
some time to execute, to the oscilloscope, then
proceed to talk to another oscilloscope while the first
oscilloscope is parsing and executing commands.
Output Queue The output queue of the oscilloscope is the
memory area where all output data or response
messages are stored until read by the computer.
Parser The oscilloscope's parser is the component that
interprets the commands sent to the oscilloscope and
decides what actions should be taken. “Parsing”
refers to the action taken by the parser to achieve
this goal. Parsing and execution of commands
begins when either the oscilloscope recognizes a
program message terminator, or the input buffer
becomes full. If you want to send a long sequence
of commands to be executed, then talk to another
oscilloscope while they are executing, you should
send all of the commands before sending the
program message terminator.
3-3
Message Communication and System Functions
Protocols
Protocol Overview
The oscilloscope and computer communicate using program messages and response
messages. These messages serve as the containers into which sets of program
commands or oscilloscope responses are placed.
A program message is sent by the computer to the oscilloscope, and a response
message is sent from the oscilloscope to the computer in response to a query message.
A query message is defined as being a program message that contains one or more
queries. The oscilloscope will only talk when it has received a valid query message,
and therefore has something to say. The computer should only attempt to read a
response after sending a complete query message, but before sending another program
message.
Remember this Rule of Oscilloscope Communication
The basic rule to remember is that the oscilloscope will only talk when
prompted to, and it then expects to talk before being told to do something else.
Protocol Operation
When you turn the oscilloscope on, the input buffer and output queue are cleared, and
the parser is reset to the root level of the command tree.
The oscilloscope and the computer communicate by exchanging complete program
messages and response messages. This means that the computer should always
terminate a program message before attempting to read a response. The oscilloscope
will terminate response messages except during a hard copy output.
After you send a query message, the next message should be the response message.
The computer should always read the complete response message associated with a
query message before sending another program message to the same oscilloscope.
The oscilloscope allows the computer to send multiple queries in one query message.
This is called sending a “compound query.” Multiple queries in a query message are
separated by semicolons. The responses to each of the queries in a compound query
will also be separated by semicolons.
Commands are executed in the order they are received.
Protocol Exceptions
If an error occurs during the information exchange, the exchange may not be
completed in a normal manner.
3-4
Message Communication and System Functions
Protocols
Suffix Multiplier
The suffix multipliers that the oscilloscope will accept are shown in Table 3-1.
The suffix units that the oscilloscope will accept are shown in Table 3-2.
<suffix unit>
SuffixReferenced Unit
VVolt
SSecond
3-5
3-6
4
Status Reporting
Status Reporting
An overview of the oscilloscope's status reporting structure is shown in Figure
4-1. The status reporting structure shows you how to monitor specific events
in the oscilloscope. Monitoring these events lets you determine the status of
an operation, the availability and reliability of the measured data, and more.
• To monitor an event, first clear the event, then enable the event. All of the
events are cleared when you initialize the oscilloscope.
• To generate a service request (SRQ) interrupt to an external computer,
enable at least one bit in the Status Byte Register.
The Status Byte Register, the Standard Event Status Register group, and the
Output Queue are defined as the Standard Status Data Structure Model in IEEE
488.2-1987. IEEE 488.2 defines data structures, commands, and common bit
definitions for status reporting. There are also oscilloscope-defined structures
and bits.
4-2
Figure 4-1
Status Reporting
Status Reporting Overview Block Diagram
The status reporting structure consists of the registers shown here.
Table 4-1 lists the bit definitions for each bit in the status reporting data
structure.
Table 4-1Status Reporting Bit Definition
BitDescriptionDefinition
PONPower OnIndicates power is turned on.
URQUser RequestNot Used. Permanently set to zero.
CMECommand ErrorIndicates if the parser detected an error.
EXEExecution ErrorIndicates if a parameter was out of range or was
inconsistent with the current settings.
4-3
Status Reporting
BitDescriptionDefinition
DDEDevice Dependent ErrorIndicates if the device was unable to complete an
QYEQuery ErrorIndicates if the protocol for queries has been violated.
RQLRequest ControlIndicates if the device is requesting control.
OPCOperation CompleteIndicates if the device has completed all pending
OPEROperation Status
Register
RQSRequest ServiceIndicates that the device is requesting service.
MSSMaster Summary StatusIndicates if a device has a reason for requesting
ESBEvent Status BitIndicates if any of the enabled conditions in the
MAV Message AvailableIndicates if there is a response in the output queue.
MSGMessageIndicates if an advisory has been displayed.
USRUser Event RegisterIndicates if any of the enabled conditions have
TRGTriggerIndicates if a trigger has been received.
WAIT
TRIG
Wait for TriggerIndicates the oscilloscope is armed and ready for
operation for device-dependent reasons.
operations.
Indicates if any of the enabled conditions in the
Operation Status Register have occurred.
service.
Standard Event Status Register have occurred.
occurred in the User Event Register.
trigger.
4-4
Status Reporting
Status Reporting Data Structures
Status Reporting Data Structures
The different status reporting data structures, descriptions, and interactions are shown
in Figure 4-2. To make it possible for any of the Standard Event Status Register bits
to generate a summary bit, you must enable the corresponding bits. These bits are
enabled by using the *ESE common command to set the corresponding bit in the
Standard Event Status Enable Register.
To generate a service request (SRQ) interrupt to the computer, you must enable at
least one bit in the Status Byte Register. These bits are enabled by using the *SRE
common command to set the corresponding bit in the Service Request Enable
Register. These enabled bits can then set RQS and MSS (bit 6) in the Status Byte
Register.
For more information about common commands, see the “Common Commands”
chapter.
4-5
Figure 4-2
Status Reporting
Status Reporting Data Structures
Status Reporting Data Structures
4-6
Figure 4-2 (Continued)
Status Reporting
Status Reporting Data Structures
Status Reporting Data Structures (Continued)
4-7
Status Reporting
Status Byte Registe r
Status Byte Register
The Status Byte Register is the summary-level register in the status reporting structure.
It contains summary bits that monitor activity in the other status registers and queues.
The Status Byte Register is a live register. That is, its summary bits are set and cleared
by the presence and absence of a summary bit from other event registers or queues.
If the Status Byte Register is to be used with the Service Request Enable Register to
set bit 6 (RQS/MSS) and to generate an SRQ, at least one of the summary bits must
be enabled, then set. Also, event bits in all other status registers must be specifically
enabled to generate the summary bit that sets the associated summary bit in the Status
Byte Register.
You can read the Status Byte Register using either the *STB? common command
query or the GPIB serial poll command. Both commands return the decimal-weighted
sum of all set bits in the register . The dif ference between the two methods is that the
serial poll command reads bit 6 as the Request Service (RQS) bit and clears the bit
which clears the SRQ interrupt. The *STB? query reads bit 6 as the Master Summary
Status (MSS) and does not clear the bit or have any effect on the SRQ interrupt. The
value returned is the total bit weights of all of the bits that are set at the present time.
The use of bit 6 can be confusing. This bit was defined to cover all possible computer
interfaces, including a computer that could not do a serial poll. The important point
to remember is that if you are using an SRQ interrupt to an external computer, the
serial poll command clears bit 6. Clearing bit 6 allows the oscilloscope to generate
another SRQ interrupt when another enabled event occurs.
The only other bit in the Status Byte Register affected by the *STB? query is the
Message A vailable bit (bit 4). If there are no other messages in the Output Queue, bit
4 (MAV) can be cleared as a result of reading the response to the *STB? query.
If bit 4 (weight = 16) and bit 5 (weight = 32) are set, a program would print the sum
of the two weights. Since these bits were not enabled to generate an SRQ, bit 6 (weight
= 64) is not set.
4-8
Status Reporting
Status Byt e Reg ister
Example 1This HP BASIC example uses the *STB? query to read the contents of the
oscilloscope’s Status Byte Register when none of the register's summary bits are
enabled to generate an SRQ interrupt.
10 OUTPUT 707;":SYSTEM:HEADER OFF;*STB?" !Turn headers off
20 ENTER 707;Result !Place result in a numeric variable
30 PRINT Result !Print the result
40 End
The next program prints 132 and clears bit 6 (RQS) of the Status Byte Register. The
difference in the decimal value between this example and the previous one is the value
of bit 6 (weight = 64). Bit 6 is set when the first enabled summary bit is set, and is
cleared when the Status Byte Register is read by the serial poll command.
Example 2This example uses the HP BASIC serial poll (SPOLL) command to read the contents
of the oscilloscope’s Status Byte Register.
10 Result = SPOLL(707)
20 PRINT Result
30 END
Use Serial Polling to Read the Status Byte Register
Serial polling is the preferred method to read the contents of the Status Byte
Register because it resets bit 6 and allows the next enabled event that occurs to
generate a new SRQ interrupt.
4-9
Status Reporting
Service Request Enable Register
Service Request Enable Register
Setting the Service Request Enable Register bits enables corresponding bits in the
Status Byte Register. These enabled bits can then set RQS and MSS (bit 6) in the
Status Byte Register.
Bits are set in the Service Request Enable Register using the *SRE command, and
the bits that are set are read with the *SRE? query. Bit 6 always returns 0. Refer to
the Status Reporting Data Structures shown in Figure 4-2.
ExampleThis example sets bit 4 (MAV) and bit 5 (ESB) in the Service Request Enable Register .
OUTPUT 707;"*SRE 48"
This example uses the parameter “48” to allow the oscilloscope to generate an SRQ
interrupt under the following conditions:
• When one or more bytes in the Output Queue set bit 4 (MAV).
• When an enabled event in the Standard Event Status Register generates a summary
bit that sets bit 5 (ESB).
Message Event Register
This register sets the MSG bit in the status byte register when an internally generated
message is written to the advisory line on the oscilloscope. The message is read using
the :SYSTEM:DSP? query. Note that messages written to the advisory line on the
oscilloscope using the :SYSTEM:DSP command does not set the MSG status bit.
Trigger Event Register
This register sets the TRG bit in the status byte register when a trigger event occurs.
The trigger event register stays set until it is cleared by reading the register with the
TER? query or by using the *CLS (clear status) command. If your application needs
to detect multiple triggers, the trigger event register must be cleared after each one.
If you are using the Service Request to interrupt a computer operation when the trigger
bit is set, you must clear the event register after each time it is set.
4-10
Status Reporting
Standard Event Status Register
Standard Event Status Register
The Standard Event Status Register (SESR) monitors the following oscilloscope
status events:
• PON - Power On
•CME - Command Error
• EXE - Execution Error
• DDE - Device Dependent Error
• QYE - Query Error
• RQC - Request Control
• OPC - Operation Complete
When one of these events occurs, the corresponding bit is set in the register.
If the corresponding bit is also enabled in the Standard Event Status Enable Register ,
a summary bit (ESB) in the Status Byte Register is set.
Y ou can read the contents of the S tandard Event Status Register and clear the register
by sending the *ESR? query. The value returned is the total bit weights of all bits set
at the present time.
ExampleThis example uses the *ESR? query to read the contents of the Standard Event Status
Register.
10 OUTPUT 707;":SYSTEM:HEADER OFF" !Turn headers off
20 OUTPUT 707;"*ESR?"
30 ENTER 707;Result !Place result in a numeric variable
40 PRINT Result !Print the result
50 End
If bit 4 (weight = 16) and bit 5 (weight = 32) are set, the program prints the sum of
the two weights.
4-11
Status Reporting
Standard Event Status Enable Register
Standard Event Status Enable Register
For any of the Standard Event Status Register bits to generate a summary bit, you
must first enable the bit. Use the *ESE (Event Status Enable) common command to
set the corresponding bit in the Standard Event Status Enable Register. Set bits are
read with the *ESE? query.
ExampleSuppose your application requires an interrupt whenever any type of error occurs.
The error status bits in the Standard Event Status Register are bits 2 through 5. The
sum of the decimal weights of these bits is 60. Therefore, you can enable any of these
bits to generate the summary bit by sending:
OUTPUT 707;"*ESE 60"
Whenever an error occurs, the oscilloscope sets one of these bits in the Standard Event
Status Register. Because the bits are all enabled, a summary bit is generated to set
bit 5 (ESB) in the Status Byte Register.
If bit 5 (ESB) in the Status Byte Register is enabled (via the *SRE command), a service
request interrupt (SRQ) is sent to the external computer.
Disabled Standard Event Status Register Bits Respond, but Do Not Generate
a Summary Bit
Standard Event Status Register bits that are not enabled still respond to their
corresponding conditions (that is, they are set if the corresponding event
occurs). However, because they are not enabled, they do not generate a
summary bit in the Status Byte Register.
4-12
Status Reporting
Operation Status Register
Operation Status Register
This register hosts the following bits:
• ACQ DONE bit 0
• PROC DONE bit 1
• WAIT TRIG bit 5
• MASK bit 9
• AUTO TRIG bit 11
• OVLR bit 12
The ACQ DONE done bit is set by the Acquisition Done Event Register.
The PROC DONE bit is set by the Process Done Event Register and indicates that all
functions and all math processes are done.
The WAIT TRIG bit is set by the Trigger Armed Event Register and indicates the
trigger is armed.
The MASK bit is set whenever at least one of the Mask Test Event Register bits is
enabled.
The AUTO TRIG bit is set by the Auto Trigger Event Register.
The OVLR bit is set whenever at least one of the Overload Event Register bits is
enabled.
If any of these bits are set, the OPER bit (bit 7) of the Status Byte Register is set. The
Operation Status Register is read and cleared with the OPER? query. The register
output is enabled or disabled using the mask value supplied with the OPEE command.
4-13
Status Reporting
Operation Status Enable Register
Operation Status Enable Register
For any of the Operation Status Register bits to generate a summary bit, you must first
enable the bit. Use the OPEE (Operation Event Status Enable) command to set the
corresponding bit in the Operation Status Enable Register. Set bits are read with the
OPEE? query.
ExampleSuppose your application requires an interrupt whenever any event occurs in the mask
test register. The error status bit in the Operation St atus Register is bit 9. Therefore,
you can enable this bit to generate the summary bit by sending:
OUTPUT 707;”OPEE 512” ( hex 200 )
Whenever an error occurs, the oscilloscope sets this bit in the Mask Test Event
Register. Because this bit is enabled, a su mmary bit is generated to set bit 9 (OPER)
in the Operation Status Register.
If bit 7 (OPER) in the Status Byte Register is enabled (via the *SRE command), a
service request interrupt (SRQ) is sent to the external computer.
Disabled Operation Status Register Bits Respond, but Do Not Generate a
Summary Bit
Operation Status Register bits that are not enabled still respond to their
corresponding conditions (that is, they are set if the corresponding event
occurs). However, because they are not enabled, they do not generate a
summary bit in the Status Byte Register.
4-14
Status Reporting
Mask Test Event Register
Mask Test Event Register
This register hosts the following bits:
• Mask Test Complete bit (bit 0)
• Mask Test Fail bit (bit 1)
• Mask Low Amplitude bit (bit 2)
• Mask High Amplitude bit (bit 3)
• Mask Align Complete bit (bit 4)
• Mask Align Fail bit (bit 5)
The Mask Test Complete bit is set whenever the mask test is complete.
The Mask Test Fail bit is set whenever the mask test failed.
The Mask Low Amplitude bit is set whenever the signal is below the mask amplitude.
The Mask High Amplitude bit is set whenever the signal is above the mask amplitude.
The Mask Align Complete bit is set whenever the mask align is complete.
The Mask Align Fail bit is set whenever the mask align failed.
If any of these bits are set, the MASK bit (bit 9) of the Operation Status Register is
set. The Mask Test Event Register is read and cleared with the MTER? query. The
register output is enabled or disabled using the mask value supplied with the MTEE
command.
4-15
Status Reporting
Mask Test Event Enable Register
Mask Test Event Enable Register
For any of the Mask Test Event Register bits to generate a summary bit, you must
first enable the bit. Use the MTEE (Mask Test Event Enable) command to set the
corresponding bit in the Mask Test Event Enable Registe r. Set bits are read with the
MTEE? query.
ExampleSuppose your application requires an interrupt whenever a Mask Test Fail occurs in
the mask test register. You can enable this bit to generate the summary bit by sending:
OUTPUT 707;”MTEE 2”
Whenever an error occurs, the oscilloscope sets the MASK bit in the Operation Status
Register. Because the bits in the Operation S tatus Enable Register are all enabled, a
summary bit is generated to set bit 7 (OPER) in the Status Byte Register.
If bit 7 (OPER) in the Status Byte Register is enabled (via the *SRE command), a
service request interrupt (SRQ) is sent to the external computer.
Disabled Mask Test Event Register Bits Respond, but Do Not Generate a
Summary Bit
Mask Test Event Register bits that are not enabled still respond to their
corresponding conditions (that is, they are set if the corresponding event
occurs). However, because they are not enabled, they do not generate a
summary bit in the Operation Status Register.
4-16
Status Reporting
Acquisition Done Event Register
Acquisition Done Event Register
The Acquisition Done Event Register (ACQ DONE) sets bit 0 (ACQ DONE bit) in
the Operation Status Register when the oscilloscope acquisition is completed.
The ACQ DONE event register stays set until it is cleared by reading the register by
a ADER? query. If your application needs to detect multiple acquisitions, the ACQ
DONE event register must be cleared after each acquisition.
Process Done Event Register
The Process Done Event Register(PDER) sets bit 1 (PROC DONE) of the Operation
Status Register when all functions and all math operations are completed. The PDER
bit stays set until cleared by a PDER? query.
Trigger Armed Event Register
The Trigger Armed Event Register (TDER) sets bit 5 (WAIT TRIG) in the Operation
Status Register when the oscilloscope becomes armed.
The ARM event register stays set until it is cleared by reading the register with the
AER? query. If your application needs to detect multiple triggers, the ARM event
register must be cleared after each one.
Auto Trigger Event Register
The Auto Trigger Event Register (AUTO TRIG) sets bit 11 (AUTO TRIG) in the
Operation Status Register when an auto trigger event occurs. The AUTO TRIG
register stays set until it is cleared by reading the register with the ATER? query. If
the application needs to detect multiple auto trigger events, the AUT TRIG register
must be cleared after each one.
4-17
Status Reporting
Error Queue
Error Queue
As errors are detected, they are placed in an error queue. This queue is a first-in, firstout queue. If the error queue overflows, the last error in the queue is replaced with
error -350, “Queue overflow.” Any time the queue overflows, the oldest errors remain
in the queue, and the most recent error is discarded. The length of the oscilloscope's
error queue is 30 (29 positions for the error messages, and 1 position for the “Queue
overflow” message).
The error queue is read with the :SYSTEM:ERROR? query. Executing this query
reads and removes the oldest error from the head of the queue, which opens a position
at the tail of the queue for a new error. When all the errors have been read from the
queue, subsequent error queries return 0, “No error.”
The error queue is cleared when any of these events occur:
• When the oscilloscope is powered up.
• When the oscilloscope receives the *CLS common command.
• When the last item is read from the error queue.
For more information on reading the error queue, refer to the :SYSTEM:ERROR?
query in the System Commands chapter. For a complete list of error messages, refer
to the chapter, “Error Messages.”
Output Queue
The output queue stores the oscilloscope-to-computer responses that are generated by
certain oscilloscope commands and queries. The output queue generates the Message
Available summary bit when the output queue contains one or more bytes. This
summary bit sets the MAV bit (bit 4) in the Status Byte Register. You may read the
output queue with the HP Basic ENTER statement.
4-18
Status Reporting
Message Queue
Message Queue
The message queue contains the text of the last message written to the advisory line
on the screen of the oscilloscope. The queue is read with the :SYSTEM:DSP? query .
Note that messages sent with the :SYSTEM:DSP command do not set the MSG status
bit in the Status Byte Register.
Clearing Registers and Queues
The *CLS common command clears all event registers and all queues except the
output queue. If *CLS is sent immediately following a program message terminator,
the output queue is also cleared.
4-19
Figure 4-3
Status Reporting
Clearing Registers and Queues
Status Reporting Decision Chart
4-20
5
Remote Acquisition Synchronization
Introduction
When remotely controlling an oscilloscope with SCPI commands, it is often necessary
to know when the oscilloscope has finished the previous operation and is ready for
the next SCPI command. The most common example is when an acquisition is started
using the :DIG, :RUN, or :SINGLE commands. Before a measurement result can be
queried, the acquisition must complete. Too often, fixed delays are used to accomplish
this wait, but fixed delays often use excessive time or the time may not be long enough.
A better solution is to use synchronous commands and status to know when the
oscilloscope is ready for the next request.
Programming Flow
Most remote programming follows these three general steps:
1 Setup the oscilloscope and device under test
2 Acquire a waveform
3 Retrieve results
Setting Up the Oscilloscope
Before making changes to the oscilloscope setup, it is best to make sure it is stopped
using the :STOP command followed by the *OPC? command.
NOTE: It is not necessary to use the *OPC? command, hard coded waits, or status
checking when setting up the oscilloscope.
After the oscilloscope is configured, it is ready for an acquisition.
Acquiring a Waveform
5-2
Table 0-1
Remote Acquisition Synchronization
Retrieving Results
When acquiring a waveform, there are two possible methods used to wait for the
acquisition to complete. These methods are blocking and polling. The table below
details when each method should be chosen and why.
Blocking WaitPolling Wait
Use When
Advantages
Disadvantages
You know the
oscilloscope will
trigger based on the
oscilloscope setup and
device under test
•No need for
polling
•Fast method
•Remote interface
may timeout
•Device clear only
way to get control
of oscilloscope if
there is no trigger
You know the
oscilloscope may or
may not trigger based
on the oscilloscope
setup and device
under test
•Remote interface
will not timeout
•No need for device
clear if no trigger
•Slower method
•Required polling
loop
•Required known
maximum wait
time
Retrieving Results
Once the acquisition is complete, it is safe to retrieve measurements and statistics.
Use the :DIGitize command to start the acquisition. This blocks subsequent queries
until the acquisition and processing is complete.
Example // Setup
:TRIGGER:MODE EDGE
:TIMEBASE:SCALE 5e-9
//Acquire
:DIG
//Get results
:MEASURE:RISETIME?
Polling Synchronization With Timeout
This example requires a timeout value so the operation can abort if an acquisition
does not occur within the timeout period.
Example TIMEOUT = 1000ms
currentTime = 0ms
// Setup
:STOP; *OPC? // if not stopped
:ADER? // clear ADER event
// Acquire
:SINGLE
while(currentTime <= TIMEOUT)
{
if (:ADER? == 1)
{
break;
}
else
{
// Use small wait to prevent excessive
// queries to the oscilloscope
wait (100ms)
currentTime += 100ms
5-4
Remote Acquisition Synchronization
Single Shot Device Under Test (DUT)
}
}
//Get results
if (currentTime < TIMEOUT)
{
:MEASURE:RISETIME?
}
Single Shot Device Under Test (DUT)
The examples in the previous section (Acquisition Synchronization) assumed the
DUT is continually running and, therefore, the oscilloscope will have more than one
opportunity to trigger. With a single shot DUT, there is only one opportunity for the
oscilloscope to trigger so it is necessary for the oscilloscope to be armed and ready
before the DUT is enabled.
NOTE: The blocking :DIGitize command cannot be used for a single shot DUT
because once the :DIGitize command is issued, the oscilloscope is blocked from any
further commands until the acquisition is complete.
This example is the same as the previous example with the addition of checking for
the armed event status.
// Setup
:STOP; *OPC? // if not stopped
:ADER? // clear ADER event
// Acquire
:SINGLE
while(AER? == 0)
{
wait(100ms)
}
//oscilloscope is armed and ready, enable DUT here
while(currentTime <= TIMEOUT)
{
if (:ADER? == 1)
{
break;
}
else
{
// Use small wait to prevent excessive
// queries to the oscilloscope
wait (100ms)
currentTime += 100ms
}
}
//Get results
if (currentTime < TIMEOUT)
{
:MEASURE:RISETIME?
}
Averaging Acquisition Synchronization
5-6
When averaging, it is necessary to know when the average count has been reached.
Since an ADER/PDER event occurs for every acquisition in the average count, these
commands cannot be used. The :SINGle command does not average.
If it is known that a trigger will occur, a :DIG will acquire the complete number of
averages, but if the number of averages is large, it may cause a timeout on the
connection.
The example below acquires the desired number of averages and then stops running.
Example AVERAGE_COUNT = 256
:STOP;*OPC?
:TER?
:ACQ:AVERage:COUNt AVERAGE_COUNT
:ACQ:AVERage ON
:RUN
Remote Acquisition Synchronization
Averaging Acquisition Synchronization
//Assume the oscilloscope will trigger, if not put a check here
while (:WAV:COUNT? < AVERAGE_COUNT)
{
wait(100ms)
}
This chapter describes conventions used to program the Infiniium-Series
Oscilloscopes, and conventions used throughout this manual. A description
of the command tree and command tree traversal is also included.
6-2
Programming Conventions
Truncation Rule
Truncation Rule
The truncation rule is used to produce the short form (abbreviated spelling) for the
mnemonics used in the programming headers and parameter arguments.
Command Truncation Rule
The mnemonic is the first four characters of the keyword, unless the fourth
character is a vowel. Then the mnemonic is the first three characters of the
keyword. If the length of the keyword is four characters or less, this rule does
not apply, and the short form is the same as the long form.
T able 5-1 shows how the truncation rule is applied to commands.
Table 6-1
Mnemonic Truncation
Long FormShort Form How the Rule is Applied
RANGERANGShort form is the first four characters of the keyword.
PATTERNPATTShort form is the first four characters of the keyword.
DISKDISKShort form is the same as the long form.
DELAYDELFourth character is a vowel; short form is the first three
characters.
6-3
Programming Conventions
The Command Tree
The Command Tree
The command tree in Figure 5-1 shows all of the commands in the Infiniium-Series
Oscilloscopes and the relationship of the commands to each other. The IEEE 488.2
common commands are not listed as part of the command tree because they do not
affect the position of the parser within the tree.
When a program message terminator (<NL>, linefeed - ASCII decimal 10) or a
leading colon (:) is sent to the oscilloscope, the parser is set to the “root” of the
command tree.
Command Types
The commands in this oscilloscope can be viewed as three types: common commands,
root level commands, and subsystem commands.
• Common commands are commands defined by IEEE 488.2 and control some
functions that are common to all IEEE 488.2 instruments. These commands are
independent of the tree and do not affect the position of the parser within the tree.
*RST is an example of a common command.
• Root level commands control many of the basic function s of the oscill oscope.
These commands reside at the root of the command tree. They can always be
parsed if they occur at the beginning of a program message or are preceded by a
colon. Unlike common commands, root level commands place the parser back at
the root of the command tree. AUTOSCALE is an example of a root level
command.
• Subsystem commands are grouped together under a common node of the command
tree, such as the TIMEBASE commands. You may select only one subsystem at
a given time. When you turn on the oscilloscope initially, the command parser is
set to the root of the command tree and no subsystem is selected.
6-4
Programming Conventions
The Command Tree
Tree Traversal Rules
Command headers are created by traversing down the command tree. A legal
command header from the command tree would be :TIMEBASE:RANGE. This is
referred to as a compound header. A compound header is a header made up of two
or more mnemonics separated by colons. The compound header contains no spaces.
The following rules apply to traversing the tree.
Tree Traversal Rules
A leading colon or a program message terminator (<NL> or EOI true on the
last byte) places the parser at the root of the command tree. A leading colon is
a colon that is the first character of a program header. Executing a subsystem
command places the oscilloscope in that subsystem until a leading colon or a
program message terminator is found.
In the command tree, use the last mnemonic in the compound header as a reference
point (for example, RANGE). Then find the last colon above that mnemonic
(TIMEBASE:). That is the point where the parser resides. Y ou can send any command
below this point within the current program message without sending the mnemonics
which appear above them (for example, REFERENCE).
6-5
HARDcopy:
AREA
DPRinter
FACTors
IMAGe
PRINters?
CHANnel<n>:
DISPlay
INPut
OFFSet
PROBe:
ATTenuation
EADapter
ECOupling
EXTernal:
GAIN
OFFSet
UNITs
GAIN
ID?
SKEW
STYPe
RANGe
SCALe
UNITs
ACQuire:
AVERage:
COUNt
COMPlete:
STATe
BANDwidth !+
INTerpolate
MODE
POINts:
AUTO
SRATe:
ABSolute
ADD
AVERage
COMMonmode
DIFF
DISPlay
DIVide
FFT:
FREQuency
RESolution?
WINDow
FFTMagnitude
FFTPhase
FUNCtion<N>?
HIGHpass
HORizontal:
POSition
RANGe