Agilent 86100A Programmer’s Guide

Programmer’s Guide

Agilent Part No. 86100-90003 Printed in USA February 2000

Agilent Technologies Lightwave Division 1400 Fountaingrove Parkway Santa Rosa, CA 95403-1799, USA (707) 577-1400

Notice.

The information contained in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. Agilent Technologies 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. Agilent Technologies 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.

Restricted Rights Legend.

Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies.

Warranty.

This Agilent Technologies instrument product is warranted against defects in material and workmanship for a period of one year from date of shipment. During the warranty period, Agilent Technologies will, at its option, either repair or replace products which prove to be defective. For warranty service or repair, this product must be returned to a service facility designated by Agilent Technologies. Buyer shall prepay shipping charges to Agilent Technologies and Agilent Technologies shall pay shipping charges to return the product to Buyer. However, Buyer shall pay all shipping charges, duties, and taxes for products returned to Agilent Technologies from another country.

Agilent Technologies warrants that its software and firmware designated by Agilent Technologies for use with an instrument will execute its programming instructions when properly installed on that instrument. Agilent Technologies does not warrant that the operation of the instrument, or software, or firmware will be uninterrupted or errorfree.

Limitation of Warranty.

The foregoing warranty shall not apply to defects resulting from improper or inadequate maintenance by Buyer, Buyersupplied software or interfacing, unauthorized modification or misuse, operation outside of the environmental specifications for the product, or improper site preparation or maintenance.

No other warranty is expressed or implied. Agilent Technologies specifically dis-

claims the implied warranties of merchantability and fitness for a particular purpose.

Exclusive Remedies.

The remedies provided herein are buyer's sole and exclusive remedies. Agilent Technologies shall not be liable for any direct, indirect, special, incidental, or consequential damages, whether based on contract, tort, or any other legal theory.

Safety Symbols.

CAUTION

The hazard. It calls attention to a procedure which, if not correctly performed or adhered to, could result in damage to or destruction of the product. Do not proceed beyond a caution sign until the indicated conditions are fully understood and met.

WARNING

The hazard. It calls attention to a procedure which, if not correctly performed or adhered to, could result in injury or loss of life. Do not proceed beyond a warning sign until the indicated conditions are fully understood and met.

sign denotes a

caution

warning

sign denotes a

The instruction manual symbol. The product is marked with this warning symbol when it is necessary for the user to refer to the instructions in the manual.

The laser radiation symbol. This warning symbol is marked on products which have a laser output.

The AC symbol is used to indicate the required nature of the line module input power.

The ON symbols are

used to mark the positions of the instrument power line switch.

The OFF symbols

❍

are used to mark the positions of the instrument power line switch.

The CE mark is a registered trademark of the European Community.

The CSA mark is a registered trademark of the Canadian Standards Association.

ISM1-A This text denotes that the instrument is an Industrial Scientific and Medical Group 1 Class A product.

Typographical Conventions.

The following conventions are used in this book:

key type

for keys or text located on the keyboard or instrument.

softkey type

are displayed on the instrument’s screen.

display type

characters displayed on the computer’s screen or instrument’s display.

user type

ters that you type or enter.

emphasis

characters that emphasize some point or that are used as place holders for text that you type.

for key names that

for words or

for words or charac-

type for words or

General Safety Considerations

WARNING

CAUTION

If this product is not used as specified, the protection provided by the equipment could be impaired. This product must be used in a normal condition (in which all means for protection are intact) only.

No operator serviceable parts inside. Refer servicing to qualified personnel. To prevent electrical shock, do not remove covers.

Fiber-optic connectors are easily damaged when connected to dirty or damaged cables and accessories. The digital communications analyzer’s frontpanel INPUT connector is no exception. When you use improper cleaning and handling techniques, you risk expensive instrument repairs, damaged cables, and compromised measurements. Before you connect any fiber-optic cable to the digital communications analyzer, refer to “Cleaning Connectors for Accurate Measurements” in the instrument on-line help system.

This product has been designed and tested in accordance with IEC Publication 61010-1, Safety Requirements for Electrical Equipment for Measurement, Control, and Laboratory Use, and has been supplied in a safe condition. The instruction documentation contains information and warnings that must be followed by the user to ensure safe operation and to maintain the product in a safe condition.

Agilent 86100A Quick Start Guide

, or in the

iii

1 Introduction

Communicating with the Analyzer 1-2 Output Command 1-3 Device Address 1-3 Instructions 1-4 Instruction Header 1-4 White Space (Separator) 1-4 Program Data 1-5 Header Types 1-5 Duplicate Mnemonics 1-7 Query Headers 1-7 Program Header Options 1-8 Character Program Data 1-9 Numeric Program Data 1-9 Embedded Strings 1-10 Program Message Terminator 1-10 Common Commands within a Subsystem 1-10 Selecting Multiple Subsystems 1-11 File Names and Types 1-11 File Locations 1-13 Getting Started Programming 1-15 Initialization 1-15 Example Program 1-17 Using the DIGITIZE Command 1-18 Receiving Information from the Analyzer 1-19 String Variable Example 1-20 Numeric Variable Example 1-20 Definite-Length Block Response Data 1-21 Multiple Queries 1-21 Analyzer Status 1-22

2 Interface Functions

GPIB Interface Connector 2-2 GPIB Default Startup Conditions 2-2 Interface Capabilities 2-3 Command and Data Concepts 2-3 Communicating Over the Bus 2-4

Contents-1

Contents

Bus Commands 2-5

3 Message Communication and System Functions

Protocols 3-2

4 Status Reporting

Status Reporting Data Structures 4-5 Status Byte Register 4-8 Service Request Enable Register 4-10 Trigger Event Register (TRG) 4-10 Standard Event Status Register 4-11 Standard Event Status Enable Register 4-12 User Event Register (UER) 4-12 Local Event Register (LCL) 4-13 Operation Status Register (OPR) 4-13 Limit Test Event Register (LTER) 4-13 Mask Test Event Register (MTER) 4-14 Acquisition Event Register (AER) 4-15 Error Queue 4-15 Output Queue 4-16 Message Queue 4-16 Clearing Registers and Queues 4-16

5 Programming Conventions

Data Flow 5-2 Truncation Rule 5-3 The Command Tree 5-4 Infinity Representation 5-10 Sequential and Overlapped Commands 5-10 Response Generation 5-10 EOI 5-10

6 Sample Programs

Sample Program Structure 6-3 Sample C Programs 6-4 init.c - Initialization 6-5 init.c - Global Definitions and Main Program 6-6

Contents-2

init.c - Initializing the Analyzer 6-7 init.c - Acquiring Data 6-8 init.c - Making Automatic Measurements 6-9 init.c - Error Checking 6-11 init.c - Transferring Data to the PC 6-13 init.c - Converting Waveform Data 6-15 init.c - Storing Waveform Time and Voltage Information 6-16 gen_srq.c - Generating a Service Request 6-17 Listings of the Sample Programs 6-21 hpib_decl.h Sample Program 6-22 init.c Sample Program 6-24 gen_srq.c Sample Program 6-30 srq.c Sample Program 6-32 learnstr.c Sample Program 6-34 sicl_IO.c Sample Program 6-37 natl_IO.c Sample Program 6-40 init.bas Sample Program 6-44 srq.bas Sample Program 6-50 lrn_str.bas Sample Program 6-53

Contents

7 Common Commands

Receiving Common Commands 7-2 Status Registers 7-3 Common Commands 7-4 *CLS (Clear Status) 7-4 *ESE (Event Status Enable) 7-4 *ESR? (Event Status Register) 7-6 *IDN? (Identification Number) 7-7 *LRN? (Learn) 7-7 *OPC (Operation Complete) 7-9 *OPT? (Option) 7-10 *RCL (Recall) 7-10 *RST (Reset) 7-11 *SAV (Save) 7-16 *SRE (Service Request Enable) 7-16 *STB? (Status Byte) 7-17 *TRG (Trigger) 7-19

Contents-3

Contents

*TST? (Test) 7-19 *WAI (Wait-to-Continue) 7-20

8 Root Level Commands

Status Reporting Data Structures 8-3 Root Level Commands 8-4 AEEN (Acquisition Limits Event Enable register) 8-4 ALER? (Acquisition Limits Event Register) 8-4 AUToscale 8-4 BLANk 8-5 CDISplay 8-6 COMMents 8-6 DIGitize 8-7 LER? (Local Event Register) 8-8 LTEE (Limit Test Event Enable register) 8-8 LTER? (Limit Test Event Register) 8-9 MODel? 8-9 MTEE (Mask Event Enable register) 8-10 MTER? (Mask Test Event Register) 8-11 OPEE 8-11 OPER? 8-11 PRINt 8-12 RECall:SETup 8-12 RUN 8-12 SERial (Serial Number) 8-12 SINGle 8-13 STOP 8-14 STORe:SETup 8-14 STORe:WAVEform 8-14 TER? (Trigger Event Register) 8-15 UEE (User Event Enable register) 8-15 UER? (User Event Register) 8-16 VIEW 8-16

9 System Commands

DATE 9-3 DSP 9-3

Contents-4

ERRor? 9-4 HEADer 9-6 MODE 9-7 SETup 9-7 TIME 9-9

10 Acquire Commands

AVERage 10-3 COUNt 10-3 POINts 10-4 RUNTil 10-4 SSCReen 10-5 SSCReen:AREA 10-6 SSCReen:IMAGe 10-6 SWAVeform 10-7 SWAVeform:RESet 10-8

Contents

11 Calibration Commands

Mainframe Calibration 11-2 Module Calibration 11-2 Probe Calibration 11-4 CANCel 11-5 CONTinue 11-5 ERATio:DLEVel? CHANnel<N> 11-5 ERATio:STARt CHANnel<N> 11-6 ERATio:STATus? 11-6 FRAMe:LABel 11-6 FRAMe:STARt 11-6 FRAMe:TIME? 11-7 MODule:OCONversion 11-7 MODule:OPOWer 11-7 MODule:OPTical 11-8 MODule:OWAVelength 11-8 MODule:STATus? 11-8 MODule:TIME? 11-9 MODule:VERTical 11-9 OUTPut 11-9

Contents-5

Contents

PROBe:CHANnel<N> 11-10 SAMPlers 11-10 SDONe? 11-11 SKEW 11-11 STATus? 11-12 Calibration Procedure 11-12

12 Channel Commands

BANDwidth 12-3 DISPlay 12-3 FDEScription? 12-4 FILTer 12-4 FSELect 12-5 OFFSet 12-6 PROBe:CALibrate 12-6 RANGe 12-7 SCALe 12-7 WAVelength 12-8

13 Disk Commands

CDIRectory 13-3 DELete 13-3 DIRectory? 13-4 LOAD 13-4 MDIRectory 13-5 PWD? 13-5 STORe 13-6

14 Display Commands

CGRade:LEVels? 14-3 CONNect 14-3 DATA? 14-4 DCOLor (Default COLor) 14-4 GRATicule 14-5 LABel 14-6 LABel:DALL 14-6 PERSistence 14-6

Contents-6

SCOLor 14-7 SSAVer 14-9 TEXT 14-9

15 Function Commands

FUNCtion<N>? 15-3 DISPlay 15-3 HORizontal 15-4 HORizontal:POSition 15-4 HORizontal:RANGe 15-5 INVert 15-6 MAGNify 15-6 OFFSet 15-7 RANGe 15-8 SUBTract 15-9 VERSus 15-10 VERTical 15-11 VERTical:OFFSet 15-12 VERTical:RANGe 15-13

Contents

16 Hardcopy Commands

AREA 16-3 DPRinter 16-3 FACTors 16-4 IMAGe 16-5 PRINters? 16-5

17 Histogram Commands

Histograms and the Database 17-3 AXIS 17-4 MODE 17-4 SCALe:SIZE 17-5 WINDow:DEFault 17-5 WINDow:SOURce 17-6 WINDow:X1Position 17-6 WINDow:X2Position 17-7 WINDow:Y1Position 17-8

Contents-7

Contents

WINDow:Y2Position 17-9

18 Limit Test Commands

FAIL 18-3 LLIMit 18-4 MNFound 18-5 RUNTil 18-6 SOURce 18-7 SSCReen 18-7 SSCReen:AREA 18-8 SSCReen:IMAGe 18-9 SSUMmary 18-9 SWAVeform 18-10 SWAVeform:RESet 18-11 TEST 18-11 ULIMit 18-13

19 Marker Commands

STATe 19-3 X1Position 19-4 X1Y1source 19-4 X2Position 19-5 X2Y2source 19-6 XDELta? 19-6 Y1Position 19-7 Y2Position 19-8 YDELta? 19-9

20 Mask Test Commands

Mask Handling 20-3 Mask Files 20-3 ALIGn 20-4 COUNt:FAILures? 20-4 COUNt:FSAMples? 20-5 COUNt:HITS? 20-5 COUNt:SAMPles? 20-6 COUNt:WAVeforms? 20-6

Contents-8

DELete 20-7 EXIT 20-7 LOAD 20-7 MASK:DELete 20-8 MMARgin:PERCent 20-9 MMARgin:STATe 20-9 RUNTil 20-10 SCALe:DEFault 20-11 SCALe:SOURce? 20-11 SCALe:X1 20-12 SCALe:XDELta 20-13 SCALe:Y1 20-14 SCALe:Y2 20-14 SCALe:YTRack 20-15 SSCReen 20-16 SSCReen:AREA 20-17 SSCReen:IMAGe 20-17 SSUMmary 20-18 STARt 20-19 SWAVeform 20-19 SWAVeform:RESet 20-20 TEST 20-20 TITLe? 20-21

Contents

21 Measure Commands

Measurement Setup 21-3 User-Defined Measurements 21-3 Measurement Error 21-3 Making Measurements 21-4 APOWer 21-6 CGRade:COMPlete 21-7 CGRade:CROSsing 21-7 CGRade:DCDistortion 21-8 CGRade:EHEight 21-9 CGRade:ERATio 21-10 CGRade:ESN 21-10 CGRade:EWIDth 21-11

Contents-9

Contents

CGRade:JITTer 21-12 CGRade:OLEvel 21-13 CGRade:PEAK? 21-13 CGRade:ZLEVel 21-14 CLEar 21-15 DEFine 21-15 FALLtime 21-17 HISTogram:HITS 21-18 HISTogram:M1S 21-19 HISTogram:M2S 21-20 HISTogram:M3S 21-21 HISTogram:MEAN 21-22 HISTogram:MEDian 21-22 HISTogram:PEAK 21-23 HISTogram:PP 21-24 HISTogram:SCALe? 21-25 HISTogram:STDDev 21-25 OVERshoot 21-26 PERiod 21-27 RESults? 21-28 RISetime 21-29 SCRatch 21-30 SENDvalid 21-31 SOURce 21-31 TEDGe? 21-32 VAMPlitude 21-33 VPP 21-34 VRMS 21-35

22 Time Base Commands

BRATe 22-2 POSition 22-2 RANGe 22-3 REFerence 22-4 SCALe 22-4 UNITs 22-5

Contents-10

23 Trigger Commands

BWLimit 23-3 GATed 23-3 HYSTeresis 23-4 LEVel 23-4 SLOPe 23-4 SOURce 23-5

24 Waveform Commands

Data Acquisition 24-2 Waveform Data and Preamble 24-2 Data Conversion 24-3 Conversion from Data Value to Units 24-3 Data Format for GPIB Transfer 24-4 BANDpass? 24-5 BYTeorder 24-5 COUNt? 24-6 DATA 24-6 FORMat 24-9 POINts? 24-10 PREamble 24-11 SOURce 24-14 TYPE? 24-15 XDISplay? 24-16 XINCrement? 24-16 XORigin? 24-17 XRANge? 24-17 XREFerence? 24-18 XUNits? 24-18 YDISplay? 24-19 YINCrement? 24-19 YORigin? 24-20 YRANge? 24-20 YREFerence? 24-21 YUNits? 24-21

Contents

Contents-11

Contents

25 Waveform Memory Commands

DISPlay 25-3 LOAD 25-3 SAVE 25-4 XOFFset 25-4 XRANge 25-4 YOFFset 25-5 YRANge 25-6

26 Language Compatability

Agilent 83480A Commands Not Used in the Agilent 86100A 26-2

27 Error Messages

Error Queue 27-2 Error Numbers 27-3 Command Error 27-3 Execution Error 27-4 Device- or Analyzer-Specific Error 27-4 Query Error 27-5 List of Error Messages 27-6

Index

Contents-12

Introduction

Introduction to Programming

This chapter introduces the basics for remote programming of an analyzer. 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 (GPIB controller) and an analyzer include:

• Set up the analyzer.

• Make measurements.

• Get data (waveform, measurements, configuration) from the analyzer.

• Send information, such as waveforms and configurations, to the analyzer.

Other tasks are accomplished 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.

Communicating with the Analyzer

Computers communicate with the analyzer by sending and receiving messages over a remote interface, usually with GPIB programming. Commands for programming normally appear as ASCII character strings embedded in the output statements of a “host” language available on your computer. The input commands of the host language are used to read in responses from the analyzer.

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.

1-2

Introduction

Output Command

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.

This HP BASIC OUTPUT statement sends a command that sets the channel 1 scale value to 500 mV:

OUTPUT <device address>;":CHANNEL1:SCALE 500E-3"<terminator>

The device address represents the address of the device being programmed. Each of the other parts of the above statement are explained in 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”.

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 analyzer and interface card are at GPIB device address 707. When writing programs, the device address varies according to how the bus is configured.

1-3

Introduction

Instructions

Instructions, both commands and queries, normally appear as strings embedded in a statement of your host language, such as HP 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 information to clarify the meaning

of the instruction.

Instruction Header

The instruction header is one or more command mnemonics separated by colons (:) that represent the operation to be performed by the analyzer. See

Chapter 5, “Programming Conventions” 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.

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.

1-4

Introduction

Program Data

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. See “Numeric Program Data” on

page 1-9 for more information about general syntax rules and acceptable val-

ues.

When there is more than one data parameter, they are separated by commas (,). You can add spaces around the commas to improve readability.

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 analyzer. The syntax is:

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:

OUTPUT 707;”:DIGITIZE CHANNEL1,FUNCTION2”

1-5

Introduction

Header Types

Compound Command Header

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:

To execute a single function within a subsystem:

:<subsystem>:<function><separator><program data><terminator>

For example:

OUTPUT 707;”:CHANNEL1:BANDWIDTH HIGH”

Combining Commands in the Same Subsystem

To execute more than one command within the same subsystem, use a semicolon (;) to separate the commands:

:<subsystem>:<command><separator><data>;<command><separator><data><terminator>

For example:

:CHANNEL1:DISPLAY ON;BWLIMIT ON

Common Command Header

Common command headers, such as clear status, control the IEEE 488.2 functions within the analyzer. 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-6

Introduction

Duplicate Mnemonics

Identical function mnemonics can be used for more than one subsystem. For example, the function mnemonic RANGE may be used to change the vertical range or to change the 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

CHANNEL1 and TIMEBASE are subsystem selectors, and determine which range is being modified.

Query Headers

Command headers immediately followed by a question mark (?) are queries. After receiving a query, the analyzer 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 query commands to find out how the analyzer is currently configured. They are also used to get results of measurements made by the analyzer. For example, the command:

:MEASURE:RISETIME?

tells the analyzer to measure the rise time of your waveform and place the result in the output queue.

1-7

Introduction

Program Header Options

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.

Handling 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.

Program Header Options

You can send program headers using any combination of uppercase or lowercase ASCII characters. Analyzer responses, however, are always returned in uppercase.

You may send program command and query 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

:TIM:DEL 1E-6

is the short form.

is the long 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 Chapter 5, “Programming

Conventions”.

1-8

Introduction

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. Either the long form of commands, or the short form (if one exists), may be sent. Uppercase and lowercase letters may be mixed freely. When receiving responses, uppercase letters are used exclusively.

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 Chapter 2, “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-9

Introduction

Embedded Strings

Embedded strings contain groups of alphanumeric characters which are treated as a unit of data by the analyzer. An example of this is the line of text written to the advisory line of the analyzer with the :SYSTEM:DSP command:

:SYSTEM:DSP ""This is a message.""

You may delimit embedded strings with either single (') or double (") quotation marks. These strings are case-sensitive, and spaces act as legal characters just like any other character.

Program Message Terminator

The program instructions within a data message are executed after the program message terminator is received. The terminator may be either a 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.

Common Commands within a Subsystem

Common commands can be received and processed by the analyzer 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 analyzer, the analyzer remains in the selected subsystem. For example, if the program message

":ACQUIRE:AVERAGE ON;*CLS;COUNT 1024"

is received by the analyzer, the analyzer turns averaging on, then clears the status information without leaving the selected subsystem.

1-10

Introduction

Selecting Multiple Subsystems

If some other type of command is received within a program message, you must re-enter the original subsystem after the command. For example, the program message

":ACQUIRE:AVERAGE ON;:AUTOSCALE;:ACQUIRE:AVERAGE:COUNT 1024"

turns averaging on, completes the autoscale operation, then sets the acquire average count. In this example, :ACQUIRE must be sent again after the AUTOSCALE command to re-enter the ACQUIRE subsystem and set 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:

:CHANNEL1:RANGE 0.4;:TIMEBASE:RANGE 1

You Can Combine Compound and Simple Commands

Multiple commands may be any combination of compound and simple commands.

File Names and Types

When specifying a file name in a remote command, enclose the name in double quotation marks, such as "filename". If you specify a path, the path should be included in the quotation marks.

You can use the full path name, a relative path name, or no path. For example, you can specify:

• a full path name: "C:\User Files\waveforms\channel2.wfm"

• a relative path name: "..\myfile.set"

• a simple file name: "Memory1.txt"

All files stored using remote commands have file name extensions.The following table shows the file name extension used for each file type.

1-11

Introduction

File Names and Types

Table 1-1. File Name Extensions

File Type File Name Extension

Waveform - internal format .wfm

Waveform - text format (Verbose or Y values) .txt

Setup .set

Color grade - Gray Scale .cgs

Screen image .bmp, .eps, .gif, .pcx, .ps

Mask .msk

If you do not specify an extension when storing a file, or specify an incorrect extension, it will be corrected automatically according to the following rules:

• No extension specified: add the extension for the file type.

• Extension does not match file type: Retain the filename and change to the ap-

propriate extension.

You do not need to use an extension when loading a file if you use the optional destination parameter. For example, :DISK:LOAD "STM1_OC3",MASK will automatically add .msk to the file name.

The following table shows the rules used when loading a specified file.

Table 1-2. Rules for Loading Files

File Name Extension Destination Rule

No extension Not specified Default to internal waveform

format; add .wfm extension

Extension does not match file type

Extension matches file type Not specified Use file name with no

No extension Specified Add extension for destination

1-12

Not specified Default to internal waveform

format; add .wfm extension

alterations; destination is based on extension file type

type; default for waveforms is internal format (.wfm)

Table 1-2. Rules for Loading Files (Continued)

File Name Extension Destination Rule

Introduction

File Locations

Extension does not match destination file type

Extension matches destination file type

Specified Retain file name; add extension

for destination type. Default for waveforms is internal format (.wfm)

Specified Retain file name; destination is

as specified

Note

ASCII waveform files can be loaded only if the file name explicitly includes the .txt extensio

File Locations

If you don’t specify a directory when storing a file, the location of the file will be based on the file type. The following table shows the default locations for storing files.

Table 1-3. Default File Locations (Storing Files)

File Type Default Location

Waveform - internal format C:\User Files\waveforms

Waveform - text format (Verbose or Y values) C:\User Files\waveforms

Setup C:\User Files\setups

Color Grade - Gray Scale C:\User Files\colorgrade-grayscale

Screen Image C:\User Files\screen images

Mask C:\Scope\masks (for standard masks)

When loading a file, you can specify the full path name, a relative path name, or no path name. The following table shows the rules for locating files, based on the path specified.

1-13

Introduction

File Locations

Table 1-4. File Locations (Loading Files)

File Name Rule

Full path name Use file name and path specified

Relative path name Full path name is formed relative to the present

working directory (determine using :DISK:PWD?)

File name with no preceding path Add the file name to the default path based on

the file type.

Files may be stored to or loaded from an internal hard drive under the root path C:\User Files only. The only exceptions are the standard masks loaded from C:\Scope\masks. Attempting to access files outside the root path will generate an error message.

Files may be stored to or loaded from any path on the A: drive.

1-14

Introduction

Getting Started Programming

The remainder of this chapter discusses how to set up the analyzer, how to retrieve setup information and measurement results, how to digitize a waveform, and how to pass data to the computer. Chapter 21, “Measure Com-

mands” describes sending measurement data to the analyzer.

Initialization

To 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 analyzer

When you are using GPIB, CLEAR also resets the analyzer's parser. The parser is the program that reads in the instructions you send.

After clearing the interface, initialize the analyzer to a preset state:

OUTPUT 707;"*RST" ! initializes the analyzer to a preset state

Initializing the analyzer

The commands and syntax for initializing the analyzer are discussed in Chapter 7, “Com-

mon Commands”. Refer to your GPIB manual and programming language reference man-

ual for information on initializing the interface.

Autoscale

The AUTOSCALE feature of Agilent Technologies digitizing analyzers performs a very useful function on unknown waveforms by automatically setting up the vertical channel, time base, and trigger level of the analyzer.

The syntax for the autoscale function is:

:AUTOSCALE<terminator>

1-15

Introduction

Initialization

Setting Up the Analyzer

A typical analyzer 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 analyzer are:

:CHANNEL1: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-16

Introduction

Example Program

This program demonstrates the basic command structure used to program the analyzer.

10 CLEAR 707 Initialize analyzer interface 20 OUTPUT 707;"*RST" !Initialize analyzer to preset state 30 OUTPUT 707;":TIMEBASE:RANGE 5E-4"! Time base to 500 us full scale 40 OUTPUT 707;":TIMEBASE:DELAY 25E-9"! Delay to 25 ns 50 OUTPUT 707;":TIMEBASE:REFERENCE CENTER"! Display reference at center 60 OUTPUT 707;":CHANNEL1:RANGE .16"! Vertical range to 160 mV full scale 70 OUTPUT 707;":CHANNEL1:OFFSET -.04"! Offset to -40 mV 80 OUTPUT 707;":TRIGGER:LEVEL,-.4"! Trigger level to -0.4 90 OUTPUT 707;":TRIGGER:SLOPE POSITIVE"! Trigger on positive slope 100 OUTPUT 707;":SYSTEM:HEADER OFF"<terminator> 110 OUTPUT 707;":DISPLAY:GRATICULE FRAME"! Grid off 120 END

Overview of the Program

• Line 10 initializes the analyzer interface to a known state.

• Line 20 initializes the analyzer to a preset state.

• Lines 30 through 50 set the time base, the horizontal time at 500µs full scale,

and 25 ns of delay referenced at the center of the graticule.

• Lines 60 through 70 set the vertical range to 160 millivolts full scale and the center screen at

• Lines 80 through 90 configure the analyzer to trigger at −0.4 volts with normal triggering.

• Line 100 turns system headers off.

• Line 110 turns the grid off.

−40

millivolts.

1-17

Introduction

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. The captured data can then be measured by the analyzer or transferred to the computer for further analysis. The captured data consists of two parts: the preamble and the waveform data record.

After changing the analyzer configuration, the waveform buffers are cleared. Before doing a measurement, the DIGITIZE command should be sent 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 Chapter 8, “Root Level Com-

mands” for details.

When the DIGITIZE command is sent to an analyzer, the specified channel’s waveform is digitized with the current ACQUIRE parameters. Before sending the :WAVEFORM:DATA? query to get waveform data, 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 allows you to specify exactly what the digitized information contains. The following program example shows a typical setup:

OUTPUT 707;":SYSTEM:HEADER OFF"<terminator> OUTPUT 707;":WAVEFORM:SOURCE CHANNEL1"<terminator> OUTPUT 707;":WAVEFORM:FORMAT BYTE"<terminator> OUTPUT 707;":ACQUIRE:COUNT 8"<terminator> OUTPUT 707;":ACQUIRE:POINTS 500"<terminator> OUTPUT 707;":DIGITIZE CHANNEL1"<terminator> OUTPUT 707;":WAVEFORM:DATA?"<terminator>

This setup places the analyzer to acquire 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 analyzer will start passing the waveform information when queried.

1-18

Introduction

Receiving Information from the Analyzer

Digitized waveforms are passed from the analyzer to the computer by sending a numerical representation of each digitized point. The format of the numerical representation is controlled with the :WAVEFORM:FORMAT command and may be selected as BYTE, WORD, or ASCII.

The easiest method of entering a digitized waveform depends on data structures, available formatting, and I/O capabilities. You must scale the integers to determine the voltage value of each point. These integers are passed starting with the leftmost point on the analyzer's display. For more information, refer to Chapter 24, “Waveform Commands”.

When using GPIB, a digitize operation may be aborted by sending a Device Clear over the bus (for example, CLEAR 707).

Receiving Information from the Analyzer

After receiving a query (command header followed by a question mark), the analyzer 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 analyzer'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:RANGE? you would execute the HP BASIC statement:

ENTER <device address>;Setting$

The device address parameter represents the address of the analyzer. This would enter the current setting for the range in the string variable Setting$.

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.

Handling 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.

1-19

Introduction

String Variable Example

The format specification for handling response messages depends on both the computer and the programming language.

String Variable Example

The output of the analyzer 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 way 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:

1-20

Introduction

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 nonzero 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 leftmost “4” represents the number of digits in the number of bytes, and “4000” represents the number of bytes to be transmitted.

Multiple Queries

You can send multiple queries to the analyzer 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?;DELAY? 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

1-21

Introduction

Analyzer Status

Status registers track the current status of the analyzer. By checking the analyzer status, you can find out whether an operation has completed, is receiving triggers, and more. Chapter 4, “Status Reporting” explains how to check the status of the analyzer.

1-22

GPIB Interface Connector 2-2 GPIB Default Startup Conditions 2-2 Interface Capabilities 2-3 Command and Data Concepts 2-3 Communicating Over the Bus 2-4 Bus Commands 2-5

Interface Functions

The interface functions deal with general bus management issues, as well as messages that can be sent over the bus as bus commands. In general, these functions are defined by IEEE 488.1.

GPIB Interface Connector

The analyzer 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 analyzer 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 analyzers to be connected in virtually any configuration, as long as there is a path from the computer to every device operating on the bus.

CAUTION

Avoid stacking more than three or four cables on any one connector. Multiple connectors produce leverage that can damage a connector mounting.

GPIB Default Startup Conditions

The following default GPIB 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, the Standard Event Status Enable Register, Service

Request Enable Register, and the Status Byte Register are cleared.

2-2

Interface Functions

Interface Capabilities

The interface capabilities of this analyzer, as defined by IEEE 488.1, are listed in the following table.

Table 2-1. Interface Capabilities

Code Interface Function Capability

SH1 Source Handshake Full Capability

AH1 Acceptor Handshake Full Capability

T5 Talker Basic Talker/Serial Poll/Talk Only Mode/

Unaddress if Listen Address (MLA)

L4 Listener Basic Listener/

Unaddresses if Talk Address (MTA)

SR1 Service Request Full Capability

RL1 Remote Local Complete Capability

PP1 Parallel Poll Remote Configuration

DC1 Device Clear Full Capability

DT1 Device Trigger Full Capability

C0 Computer No Capability

E2 Driver Electronics Tri State (1 MB/SEC MAX)

Command and Data Concepts

The GPIB has two modes of operation, command mode and data mode. The bus 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 bus commands such as group execute trigger (GET).

2-3

Interface Functions

Communicating Over the Bus

The bus 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 analyzer specific commands, queries, and responses found in this manual, including analyzer status information.

Communicating Over the Bus

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 analyzer address.

Device Address = (Interface Select Code * 100) + (Analyzer Address)

The Analyzer is at Address 707 in Examples

The examples in this manual assume that the analyzer is at device address 707.

Interface Select Code

Analyzer Address

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 GPIB interface cards.

Each analyzer on the GPIB must have a unique analyzer address between decimal 0 and 30. This analyzer address is used by the computer to direct commands and communications to the proper analyzer on an interface. The default is typically “7” for this analyzer. You can change the analyzer address in the Utilities, Remote Interface dialog box.

Do Not Use Address 21 for an Analyzer Address

Address 21 is usually reserved for the Computer interface Talk/Listen address and should not be used as an analyzer address.

2-4

Interface Functions

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 analyzer.

Device Clear

Group Execute Trigger

Interface 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.

The group execute trigger (GET) command arms the trigger. This is the same action produced by sending the RUN command.

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-5

Protocols 3-2

Functional Elements 3-2 Input Buffer 3-3 Output Queue 3-3 Parser 3-3 Protocol Overview 3-3 Protocol Operation 3-3 Protocol Exceptions 3-4 Suffix Multiplier 3-4 Suffix Unit 3-5

Message Communication and System Functions

This chapter describes the operation of analyzers 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 analyzer. You can find additional detailed information about the IEEE 488.2 standard in ANSI/IEEE Std 488.2-1987,

Protocols, and Common Commands.”

This analyzer series is designed to be compatible with other Agilent Technologies IEEE 488.2 compatible instruments. Analyzers that are compatible with IEEE 488.2 must also be compatible with IEEE 488.1 (GPIB bus standard); however, IEEE 488.1 compatible analyzers may or may not conform to the IEEE 488.2 standard. The IEEE 488.2 standard defines the message exchange protocols by which the analyzer and the computer will communicate. It also defines some common capabilities that are found in all IEEE 488.2 analyzers.

This chapter also contains some information about the message communication and system functions not specifically defined by IEEE 488.2.

“IEEE Standard Codes, Formats,

Functional Elements

Protocols

The message exchange protocols of IEEE 488.2 define the overall scheme used by the computer and the analyzer to communicate. This includes defining when it is appropriate for devices to talk or listen, and what happens when the protocol is not followed.

Before proceeding with the description of the protocol, you should understand a few system components.

3-2

Message Communication and System Functions

Protocols

Input Buffer

Output Queue

Parser

Protocol Overview

The input buffer of the analyzer 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 analyzer, then proceed to talk to another analyzer while the first analyzer is parsing and executing commands.

The output queue of the analyzer is the memory area where all output data, or response messages, are stored until read by the computer.

The analyzer's parser is the component that interprets the commands sent to the analyzer 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 analyzer 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 analyzer while they are executing, you should send all of the commands before sending the program message terminator.

The analyzer and computer communicate using program messages and response messages. These messages serve as the containers into which sets of program commands or analyzer responses are placed.

A program message is sent by the computer to the analyzer, and a response message is sent from the analyzer 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 analyzer 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.

Protocol Operation

Remember This Rule of Analyzer Communication

The basic rule to remember is that the analyzer will only talk when prompted to, and it then expects to talk before being told to do something else.

When the analyzer is turned on, the input buffer and output queue are cleared, and the parser is reset to the root level of the command tree.

3-3

Message Communication and System Functions

Protocols

The analyzer 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 analyzer will terminate response messages except during a hardcopy output.

After a query message is sent, 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 analyzer.

The analyzer allows the computer to send multiple queries in one query message. This is referred to as 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

Suffix Multiplier

If an error occurs during the information exchange, the exchange may not be completed in a normal manner.

The suffix multipliers that the analyzer will accept are shown in Table 3-1.

Table 3-1. <suffix mult>

Value Mnemonic Value Mnemonic

1E18 EX 1E-3 M

1E15 PE 1E-6 U

1E12 T 1E-9 N

1E9 G 1E-12 P

1E6 MA 1E-15 F

1E3 K 1E-18 A

3-4

Message Communication and System Functions

Protocols

Suffix Unit

The suffix units that the analyzer will accept are shown in Table 3 -2.

Table 3-2. <suffix unit>

Suffix Referenced Unit

VVolt

S Second

3-5

Status Reporting Data Structures 4-5 Status Byte Register 4-8 Service Request Enable Register 4-10 Trigger Event Register (TRG) 4-10 Standard Event Status Register 4-11 Standard Event Status Enable Register 4-12 Operation Status Register (OPR) 4-13 Limit Test Event Register (LTER) 4-13 Mask Test Event Register (MTER) 4-14 Acquisition Event Register (AER) 4-15 Error Queue 4-15 Output Queue 4-16 Message Queue 4-16 Clearing Registers and Queues 4-16

Status Reporting

An overview of the analyzer's status reporting structure is shown in the following figure. The status reporting structure shows you how to monitor specific events in the analyzer. Monitoring these events allows determination of 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 analyzer.

• 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 analyzer-defined structures and bits.

4-2

Status Reporting

Figure 4-1. Status Reporting Overview Block Diagram

The status reporting structure consists of the registers shown in this figure.

4-3

Status Reporting

The following table lists the bit definitions for each bit in the status reporting data structure.

Table 4-1. Status Reporting Bit Definition

Bit Description Definition

PON Power On Indicates power is turned on.

URQ Not used. Permanently set to zero.

CME Command Error Indicates if the parser detected an error.

EXE Execution Error Indicates if a parameter was out of range or was

inconsistent with the current settings.

DDE Device Dependent Error Indicates if the device was unable to complete an

operation for device dependent reasons.

QYE Query Error Indicates if the protocol for queries has been violated.

RQL Request Control Indicates if the device is requesting control.

OPC Operation Complete Indicates if the device has completed all pending

operations.

OPER Operation Status

RQS Request Service Indicates that the device is requesting service.

MSS Master Summary Status Indicates if a device has a reason for requesting service.

ESB Event Status Bit Indicates if any of the enabled conditions in the Standard

MAV Message Available Indicates if there is a response in the output queue.

MSG Message Indicates if an advisory has been displayed.

USR User Event Register Indicates if any of the enabled conditions have occurred

TRG Trigger Indicates if a trigger has been received.

LCL Local Indicates if a remote-to-local transition occurs.

FAIL Fail Indicates the specified test has failed.

4-4

Indicates if any of the enabled conditions in the Operation Status Register have occurred.

Event Status Register have occurred.

in the User Event Register.

Status Reporting Data Structures

Table 4-1. Status Reporting Bit Definition (Continued)

Bit Description Definition

COMP Complete Indicates the specified test has completed.

Status Reporting

WAIT TRIG

Wait for Trigger Indicates analyzer is armed and ready for trigger.

Status Reporting Data Structures

The different status reporting data structures, descriptions, and interactions are shown in the following figure. To make it possible for any of the Standard Event Status Register bits to generate a summary bit, the corresponding bits must be enabled. 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, at least one bit in the Status Byte Register must be enabled. 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 Chapter 7, “Common

Commands”.

4-5

Status Reporting

Status Reporting Data Structures

Figure 4-2. Status Reporting Data Structures

4-6

Status Reporting

Status Reporting Data Structures

Status Reporting Data Structures (continued)

4-7

Status Reporting

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.

The Status Byte Register can be read 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 difference 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 affect 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 analyzer 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 Available 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 Byte Register

Example 1

Example 2

This HP BASIC example uses the *STB? query to read the contents of the analyzer’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.

This example uses the HP BASIC serial poll (SPOLL) command to read the contents of the analyzer’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

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.

Example

This 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 analyzer 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 sum-

mary bit that sets bit 5 (ESB).

Trigger Event Register (TRG)

This register sets the TRG bit in the status byte when a trigger event occurs.

The TRG event register stays set until it is cleared by reading the register or using the *CLS (clear status) command. If your application needs to detect multiple triggers, the TRG 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

The Standard Event Status Register (SESR) monitors the following analyzer 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.

The contents of the Standard Event Status Register can be read and the register cleared by sending the *ESR? query. The value returned is the total bit weights of all of the bits set at the present time.

Example

This 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

For any of the Standard Event Status Register (SESR) 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.

Example

Suppose 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 analyzer 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 SESR 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.

User Event Register (UER)

This register hosts the LCL bit (bit 0) from the Local Events Register. The other 15 bits are reserved. You can read and clear this register using the UER? query. This register is enabled with the UEE command. For example, if you want to enable the LCL bit, you send a mask value of 1 with the UEE command; otherwise, send a mask value of 0.

4-12

Status Reporting

Local Event Register (LCL)

This register sets the LCL bit in the User Event Register and the USR bit (bit

1) in the Status byte. It indicates a remote-to-local transition has occurred. The LER? query is used to read and to clear this register.

Operation Status Register (OPR)

This register hosts the WAIT TRIG bit (bit 5), the LTEST bit (bit 8), the ACQ bit (bit 9) the MASK bit (bit 10) and the PROG bit (bit 14).

The WAIT TRIG bit is set by the Trigger Armed Event Register and indicates that the trigger is armed.

THE LTEST bit is set when a limit test fails or is completed and sets the corresponding FAIL or COMP bit in the Limit Test Events Register.

The ACQ bit is set when the COMP bit is set in the Acquisition Event Register, indicating that the data acquisition has satisfied the specified completion criteria.

The MASK bit is set when the Mask Test either fails specified conditions or satisfies its completion criteria, setting the corresponding FAIl or COMP bits in the Mask Test Events Register.

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.

Limit Test Event Register (LTER)

Bit 0 (COMP) of the Limit Test Event Register is set when the Limit Test completes. The Limit Test completion criteria are set by the LTESt:RUN command.

Bit 1 (FAIL) of the Limit Test Event Register is set when the Limit Test fails. Failure criteria for the Limit Test are defined by the LTESt:FAIL command.

The Limit Test Event Register is read and cleared with the LTER? query.

4-13

Status Reporting

Mask Test Event Register (MTER)

When either the COMP or FAIL bits are set, they in turn set the LTEST bit (bit 8) of the Operation Status Register. You can mask the COMP and FAIL bits, thus preventing them from setting the LTEST bit, by defining a mask using the LTEE command.

Enable Mask Value

Block COMP and FAIL 0

Enable COMP, block FAIL 1

Enable FAIL, block COMP 2

Enable COMP and FAIL 3

Mask Test Event Register (MTER)

Bit 0 (COMP) of the Mask Test Event Register is set when the Mask Test completes. The Mask Test completion criteria are set by the MTESt:RUMode command.

Bit 1 (FAIL) of the Mask Test Event Register is set when the Mask Test fails. This will occur whenever any sample is recorded within any region defined in the mask.

The Mask Test Event Register is read and cleared with the MTER? query.

When either the COMP or FAIL bits are set, they in turn set the Mask bit (bit

10) of the Operation Status Register. You can mask the COMP and FAIL bits, thus preventing them from setting the MASK bit, by defining a mask using the MTEE command.

Enable Mask Value

Block COMP and FAIL 0

Enable COMP, block FAIL 1

Enable FAIL, block COMP 2

Enable COMP and FAIL 3

4-14

Status Reporting

Acquisition Event Register (AER)

Bit 0 (COMP) of the Acquisition Event Register is set when the acquisition limits complete. The Acquisition completion criteria are set by the ACQuire:RUNtil command. The Acquisition Event Register is read and cleared with the ALER? query.

When the COMP bit is set, it in turn sets the ACQ bit (bit 9) of the Operation Status Register. Results from the Acquisition Register can be masked by using the AEEN command to set the Acquisition Event Enable Register to the value

0. You enable the COMP bit by setting the mask value to 1.

Error Queue

As errors are detected, they are placed in an error queue. This queue is first in, first out. 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 analyzer'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 the following occurs:

• When the analyzer is powered up.

• When the analyzer 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 Chapter 9, “System Commands”. For a complete list of error messages, refer to Chapter 27, “Error Messages”.

4-15

Status Reporting

Output Queue

The output queue stores the analyzer-to-computer responses that are generated by certain analyzer 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. The output queue may be read with the HP BASIC ENTER statement.

Message Queue

The message queue contains the text of the last message written to the advisory line on the screen of the analyzer. 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-16

Status Reporting

Clearing Registers and Queues

Figure 4-3. Status Reporting Decision Chart

4-17

Data Flow 5-2 Truncation Rule 5-3 The Command Tree 5-4 Infinity Representation 5-10 Sequential and Overlapped Commands 5-10 Response Generation 5-10 EOI 5-10

Programming Conventions

This chapter describes conventions used to program the Agilent 86100A, and conventions used throughout this manual. A block diagram and description of data flow is included for understanding analyzer operations. A description of the command tree and command tree traversal is also included. See the Quick Reference for more information about command syntax.

Data Flow

The data flow gives you an idea of where the measurements are made on the acquired data and when the post-signal processing is applied to the data.

The following figure is a block diagram of the analyzer. The diagram is laid out serially for a visual perception of how the data is affected by the analyzer.

Figure 5-1. Sample Data Processing

5-2

Programming Conventions

Truncation Rule

The sample data is stored in the channel memory for further processing before being displayed. The time it takes for the sample data to be displayed depends on the number of post processes you have selected.

Averaging your sampled data helps remove any unwanted noise from your waveform.

You can store your sample data in the analyzer’s waveform memories for use as one of the sources in Math functions, or to visually compare against a waveform that is captured at a future time. The Math functions allow you to apply mathematical operations on your sampled data. You can use these functions to duplicate many of the mathematical operations that your circuit may be performing to verify that your circuit is operating correctly.

The measurements section performs any of the automated measurements that are available in the analyzer. The measurements that you have selected appear at the bottom of the display.

The Connect Dots section draws a straight line between sample data points, giving an analog look to the waveform. This is sometimes called linear interpolation.

Truncation Rule

The following truncation rule is used to produce the short form (abbreviated spelling) for the mnemonics used in the programming headers and alpha 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.

5-3

Programming Conventions

The Command Tree

The following table shows how the truncation rule is applied to commands.

Table 5-1. Mnemonic Truncation

Long Form Short Form How the Rule is Applied

RANGE RANG Short form is the first four characters of the keyword.

PATTERN PATT Short form is the first four characters of the keyword.

DISK DISK Short form is the same as the long form.

DELAY DEL Fourth character is a vowel, short form is the first three characters.

The Command Tree

The command tree in Figure 5-2 on page 5-6 shows all of the commands in the Agilent 86100A 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 analyzer, the parser is set to the “root” of the command tree.

Command Types

The commands in this analyzer can be placed into 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 functions of the analyzer. 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.

5-4

Programming Conventions

The Command Tree

• Subsystem commands are grouped together under a common node of the command tree, such as the TIMEBASE commands. Only one subsystem may be selected at a given time. When the analyzer is initially turned on, the command parser is set to the root of the command tree and no subsystem is selected.

Infinity Representation

The representation for infinity for this analyzer is 9.99999E+37. This is also the value returned when a measurement cannot be made.

Sequential and Overlapped Commands

IEEE 488.2 makes a distinction between sequential and overlapped commands.

Sequential commands finish their task before the execution of the next command starts.

Overlapped commands run concurrently. Commands following an overlapped command may be started before the overlapped command is completed. The common commands *WAI and *OPC may be used to ensure that commands are completely processed before subsequent commands are executed.

Response Generation

As defined by IEEE 488.2, query responses may be buffered for the following reasons:

• When the query is parsed by the analyzer.

• When the computer addresses the analyzer to talk so that it may read the re-

sponse.

This analyzer buffers responses to a query when the query is parsed.

EOI

The EOI bus control line follows the IEEE 488.2 standard without exception.

5-10

Sample Program Structure 6-3 Sample C Programs 6-4

init.c - Initialization 6-5 init.c - Global Definitions and Main Program 6-6 init.c - Initializing the Analyzer 6-7 init.c - Acquiring Data 6-8 init.c - Making Automatic Measurements 6-9 init.c - Error Checking 6-11 init.c - Transferring Data to the PC 6-13 init.c - Converting Waveform Data 6-15 init.c - Storing Waveform Time and Voltage Information 6-16 gen_srq.c - Generating a Service Request 6-17

Initializing the Analyzer 6-18 Setting Up a Service Request 6-19 Generating a Service Request 6-20

Listings of the Sample Programs 6-21

hpib_decl.h Sample Program 6-22 init.c Sample Program 6-24 gen_srq.c Sample Program 6-30 srq.c Sample Program 6-32 learnstr.c Sample Program 6-34 sicl_IO.c Sample Program 6-37 natl_IO.c Sample Program 6-40 init.bas Sample Program 6-44 srq.bas Sample Program 6-50 lrn_str.bas Sample Program 6-53

Sample Programs

Sample programs for the Agilent 86100A analyzers are shipped on a disk with the instrument. Each program demonstrates specific sets of instructions. This chapter shows you some of those functions, and describes the commands being executed. Both C and HP BASIC examples are included.

The header file is:

hpibdecl.h

•

The C examples include:

• init.c

• gen_srq.c

• srq.c

• learnstr.c

• sicl_IO.c

natl_IO.c

•

The HP BASIC examples include:

• init.bas

• srq.bas

lrn_str.bas

•

The sample program listings are included at the end of this chapter.

6-2

Sample Programs

Sample Program Structure

This chapter includes segments of both the C and HP BASIC sample programs. Each program includes the basic functions of initializing the interface and analyzer, capturing the data, and analyzing the data.

In general, both the C and HP BASIC sample programs typically contain the following fundamental segments:

Segment Description

main program Defines global variables and constants, specifies include files, and

calls various functions.

initialize Initializes the GPIB and analyzer, and sets up the analyzer and the

ACQuire subsystem.

acquire_data Digitizes the waveform to capture data.

auto_measurements Performs simple parametric measurements.

transfer_data Brings waveform data and voltage/timing information (the preamble)

into the computer.

6-3

Sample Programs

Sample C Programs

Segments of the sample programs “init.c” and “gen_srq.c” are shown and described in this chapter.

6-4

Sample Programs

init.c - Initialization

/* init. c */

/* Command Order Example. This program demonstrates the order of commands suggested for operation of the analyzer via HPIB.

This program initializes the scope, acquires data, performs automatic measurements, and transfers and stores the data on the PC as time/voltage pairs in a comma-separated file format useful for spreadsheet applications. It assumes a SICL INTERFACE exists as 'hpib7' and an Agilent 86100A analyzer at address 7. It also requires the cal signal attached to Channel 1.

See the README file on the demo disk for development and linking information.

# include <stdio.h> /* location of: printf ( ) */ # include <stdlib.h> /* location of: atof(), atoi ( ) */ # include "hpibdecl.h" /* prototypes, global declarations, constants */

void initialize ( ); /* initialize the scope */ void acquire_data ( ); /* digitize signal */ void auto_measurements ( ); /* perform built-in automatic measurements */ void transfer_data ( ); /* transfers waveform data from scope to PC */ void convert_data ( ); /* converts data to time/voltage values */ void store_csv ( ); /* stores time/voltage pairs to comma-separated

/* variable file format */

The include statements start the program. The file “hpibdecl.h” includes pro- totypes and declarations that are necessary for the analyzer sample programs.

This segment of the sample program defines the functions, in order, that are used to initialize the scope, digitize the data, perform measurements, transfer data from the scope to the PC, convert the digitized data to time and voltage pairs, and store the converted data in comma-separated variable file format.

See the following descriptions of the program segments.

6-5

Sample Programs

init.c - Global Definitions and Main Program

/* GLOBALS */ int count; double xorg,xref,xinc; /* values necessary for conversion of data */ double yorg,yref,yinc; int Acquired_length; char data[MAX_LENGTH]; /* data buffer */ double time_value[MAX_LENGTH]; /* time value of data */ double volts[MAX_LENGTH]; /* voltage value of data */

void main( void ) { /* initialize interface and device sessions */ /* note: routine found in sicl_IO.c or natl_IO.c */

init_IO ( );

initialize ( ); /* initialize the scope and interface and set up SRQ */ acquire_data ( ); /* capture the data */ auto_measurements ( ); /* perform automated measurements on acquired data */ transfer_data ( ); /* transfer waveform data to the PC from scope */ convert_data ( ); /* convert data to time/voltage pairs */ store_csv ( ); /* store the time/voltage pairs as csv file */ close_IO ( ); /* close interface and device sessions */

} /* end main ( ) */

/* note: routine found in sicl_IO.c or natl_IO.c */

The init_IO routine initializes the analyzer and interface so that the scope can capture data and perform measurements on the data. At the start of the program, global symbols are defined which will be used to store and convert the digitized data to time and voltage values.

6-6

init.c - Initializing the Analyzer

/* * Function name: initialize * Parameters: none * Return value: none * Description: This routine initializes the analyzer for proper * acquisition of data. The instrument is reset to a known state and the * interface is cleared. System headers are turned off to allow faster * throughput and immediate access to the data values requested by queries. * The analyzer time base, channel, and trigger subsystems are then * configured. Finally, the acquisition subsystem is initialized. */ void initialize ( ) {

write_IO ("*RST"); /* reset scope - initialize to known state */ write_IO ("*CLS"); /* clear status registers and output queue */

write_IO (":SYSTem:HEADer OFF"); /* turn off system headers */

/* initialize time base parameters to center reference, */ /* 2 ms full-scale (200 us/div), and 20 us delay */ write_IO (":TIMebase:REFerence CENTer;RANGe 2e-3;POSition 20e-6");

Sample Programs

init.c - Initializing the Analyzer

/* initialize Channel1 1.6V full-scale (200 mv/div); offset -400mv */ write_IO (":CHANnel1:RANGe 1.6;OFFSet -400e-3");

/* initialize trigger info: channel1 signal on positive slope at 300mv */ write_IO (":TRIGger:SOURce FPANel;SLOPe POSitive"); write_IO (":TRIGger:LEVel-0.40");

/* initialize acquisition subsystem */ /* Real time acquisition - no averaging; record length 4096 */ write_IO (":ACQuire:AVERage OFF;POINts 4096");

} /* end initialize ( ) */

6-7

Sample Programs

init.c - Acquiring Data

/* * Function name: acquire_data * Parameters: none * Return value: none * Description: This routine acquires data according to the current * instrument settings. */ void acquire_data ( ) { /* * The root level :DIGitize command is recommended for acquisition of new * data. It will initialize data buffers, acquire new data, and ensure that * acquisition criteria are met before acquisition of data is stopped. The * captured data is then available for measurements, storage, or transfer * to a PC. Note that the display is automatically turned off by the * :DIGitize command and must be turned on to view the captured data. */

write_IO (":DIGitize CHANnel1"); write_IO (":CHANnel1:DISPlay ON"); /* turn on channel 1 display which is */

/* turned off by the :DIGitize command */

} /* end acquire_data ( ) */

6-8

init.c - Making Automatic Measurements

/* * Function name: auto_measurements * Parameters: none * Return value: none * Description: This routine performs automatic measurements of volts * peak-to-peak and period on the acquired data. It also demonstrates * two methods of error detection when using automatic measurements. */

void auto_measurements ( ) { float period, vpp; unsigned char vpp_str[16]; unsigned char period_str[16]; int bytes_read;

/* * Error checking on automatic measurements can be done using one of two methods. * The first method requires that you turn on results in the Measurements * subsystem using the command :MEASure:SEND ON. When this is on, the analyzer * will return the measurement and a result indicator. The result flag is zero * if the measurement was successfully completed, otherwise a non-zero value is * returned which indicates why the measurement failed. See the Programmer's Manual * for descriptions of result indicators. * * The second method simply requires that you check the return value of the * measurement. Any measurement not made successfully will return with the value * +9.999E37. This could indicate that either the measurement was unable to be * performed, or that insufficient waveform data was available to make the * measurement. */ /* * METHOD ONE - turn on results to indicate whether the measurement completed * successfully. Note that this requires transmission of extra data from the scope. */ write_IO (":MEASure:SEND ON"); /* turn results on */ write_IO (":MEASure:VPP? CHANnel1"); /* query -- volts peak-to-peak channel 1*/

Sample Programs

bytes_read = read_IO(vpp_str,16L); /* read in value and result flag */

if (vpp_str[bytes_read-2] != '0') printf ("Automated vpp measurement error with result %c\n",

vpp_str [bytes_read-2]); else printf ("VPP is %f\n", (float) atof (vpp_str));

write_IO (":MEASure:PERiod? CHANnel1"); /* period channel 1 */

bytes_read = read_IO (period_str,16L); /* read in value and result flag */

if period_str[bytes_read-2] != '0') printf ("Automated period measurement error with result %c\n",

6-9

Sample Programs

init.c - Making Automatic Measurements

period_str [bytes_read-2]); else printf ("Period is %f\n",(float)atof (period_str));

/* * METHOD TWO - perform automated measurements and error checking with * :MEAS:RESULTS OFF */ period = (float) 0; vpp = (float) 0;

/* turn off results */ write_IO (":MEASure:SEND OFF");

write_IO (":MEASure:PERiod? CHANnel1"); /*period 1 */ bytes_read = read_IO (period_str,16L); /* read in value and result flag */

period = (float) atof (period_str);

if (period > 9.99e37 ) printf ("\nPeriod could not be measured.\n"); else printf ("\nThe period of channel 1 is %f seconds.\n", period );

write_IO (":MEASure:VPP? CHANnel1"); bytes_read = read_IO ( vpp_str,16L );

vpp = (float) atof (vpp_str);

if ( vpp > 9.99e37 ) printf ("Peak-to-peak voltage could not be measured.\n"); else printf ("The voltage peak-to-peak is %f volts.\n", vpp );

} /* end auto_measurements () */

6-10

init.c - Error Checking

/* Error checking on automatic measurements can be done using one of two methods. * The first method requires that you turn on results in the Measurements * subsystem using the command :MEASure:SEND ON. When this is on, the analyzer * will return the measurement and a result indicator. The result flag is zero * if the measurement was successfully completed, otherwise a non-zero value is * returned which indicates why the measurement failed. See the Programmer's Manual * for descriptions of result indicators.

* The second method simply requires that you check the return value of the * measurement. Any measurement not made successfully will return with the value * +9.999E37. This could indicate that either the measurement was unable to be * performed, or that insufficient waveform data was available to make the * measurement.

* METHOD ONE - turn on results to indicate whether the measurement completed * successfully. Note that this requires transmission of extra data from the scope. */

write_IO (":MEASure:SEND ON"); /* turn results on */

/* query -- volts peak-to-peak channel 1*/ write_IO (":MEASure:VPP? CHANnel1");

Sample Programs

init.c - Error Checking

bytes_read = read_IO(vpp_str,16L); /* read in value and result flag */

if (vpp_str[bytes_read-2] != '0') printf ("Automated vpp measurement error with result %c\n", vpp_str[bytes_read-2]); else printf ("VPP is %f\n",(float)atof(vpp_str));

write_IO (":MEASure:PERiod? CHANnel1"); /* period channel 1 */ bytes_read = read_IO(period_str,16L); /* read in value and result flag */

if period_str[bytes_read-2] != '0') printf ("Automated period measurement error with result %c\n", period_str[bytes_read-2]); else

printf ("Period is %f\n",(float)atof (period_str)); /* * METHOD TWO - perform automated measurements and error checking with * :MEAS:RESULTS OFF. */ period = (float) 0; vpp = (float) 0;

/* turn off results */

write_IO (":MEASure:SEND OFF");

write_IO (":MEASure:PERiod? CHANnel1"); /* period channel 1 */

bytes_read = read_IO (period_str,16L); /* read in value and result flag */

6-11

Sample Programs

init.c - Error Checking

period = (float) atof (period_str);

if ( period > 9.99e37 ) printf ("\nPeriod could not be measured.\n"); else printf ("\nThe period of channel 1 is %f seconds.\n", period );

write_IO (":MEASure:VPP? CHANnel1"); bytes_read = read_IO ( vpp_str,16L );

vpp = (float) atof (vpp_str);

if ( vpp > 9.99e37 ) printf ("Peak-to-peak voltage could not be measured.\n"); else printf ("The voltage peak-to-peak is %f volts.\n", vpp );

} /* end auto_measurements() */

6-12

init.c - Transferring Data to the PC

/* * Function name: transfer_data * Parameters: none * Return value: none * Description: This routine transfers the waveform conversion factors and * waveform data to the PC. */

void transfer_data ( ) {

int header_length;

char header_str[8];

char term;

char xinc_str[32],xorg_str[32],xref_str[32];

char yinc_str[32],yref_str[32],yorg_str[32];

int bytes_read;

/* waveform data source channel 1 */

write_IO (":WAVeform:SOURce CHANnel1");

/* setup transfer format */

write_IO (":WAVeform:FORMat BYTE");

/* request values to allow interpretation of raw data */

write_IO (":WAVeform:XINCrement?");

bytes_read = read_IO (xinc_str,32L);

xinc = atof (xinc_str);

write_IO (":WAVeform:XORigin?");

bytes_read = read_IO (xorg_str,32L);

xorg = atof (xorg_str);

Sample Programs

init.c - Transferring Data to the PC

write_IO (":WAVeform:XREFerence?");

bytes_read = read_IO (xref_str,32L);

xref = atof (xref_str);

write_IO (":WAVeform:YINCrement?");

bytes_read = read_IO (yinc_str,32L);

yinc = atof (yinc_str);

write_IO (":WAVeform:YORigin?");

bytes_read = read_IO (yorg_str,32L);

yorg = atof (yorg_str);

write_IO (":WAVeform:YREFerence?");

bytes_read = read_IO (yref_str,32L);

yref = atof (yref_str);

write_IO (":WAVeform:DATA?"); /* request waveform data */

while (data[0] != ‘#’)

bytes_read = read_IO (data,1L); /* find the # character */

bytes_read = read_IO (header_str,1L); /* input byte counter */

6-13

Sample Programs

init.c - Transferring Data to the PC

header_length = atoi (header_str);

/* read number of points - value in bytes */ bytes_read = read_IO (header_str,(long)header_length);

Acquired_length = atoi (header_str); /* number of bytes */

bytes_read = read_IO (data,Acquired_length); /* input waveform data */ bytes_read = read_IO (&term,1L); /* input termination character */

} /* end transfer_data () */

An example header resembles the following when the information is stripped off:

#510225

The left-most “5” defines the number of digits that follow (10225). The number “10225” is the number of points in the waveform. The information is stripped off of the header to get the number of data bytes that need to be read from the analyzer.

6-14

init.c - Converting Waveform Data

/* * Function name: convert_data * Parameters: none * Return value: none * Description: This routine converts the waveform data to time/voltage * information using the values that describe the waveform. These values are * stored in global arrays for use by other routines. */

void convert_data ( ) {

int i;

for (i = 0; i < Acquired_length; i++)

{

time_value[i] = ((i - xref) * xinc) + xorg;/* calculate time info */

volts[i] = ((data[i] - yref) * yinc) + yorg;/* calculate volt info */

} } /* end convert_data ( ) */

The data values are returned as digitized samples (sometimes called quantization levels or q-levels). These data values must be converted into voltage and time values.

Sample Programs

init.c - Converting Waveform Data

6-15

Sample Programs

init.c - Storing Waveform Time and Voltage Information

/* * Function name: store_csv * Parameters: none * Return value: none * Description: This routine stores the time and voltage information about * the waveform as time/voltage pairs in a comma-separated variable file * format. */

void store_csv ( ) {

FILE *fp; int i;

fp = fopen ("pairs.csv","wb"); /* open file in binary mode - clear file */

if (fp != NULL) { for (i = 0; i < Acquired_length; i++) { /* write time,volt pairs to file */

fprintf ( fp,"%e,%lf\n",time_value[i],volts[i]);

} fclose ( fp ); /* close file */ } else printf ("Unable to open file 'pairs.csv'\n");

/* if already exists */

} /* end store_csv ( ) */

The time and voltage information of the waveform is stored in integer format, with the time stored first, followed by a comma, and the voltage stored second.

6-16

gen_srq.c - Generating a Service Request

Sample Programs

Segments of the sample C program “gen_srq.c” show

interface and analyzer, and generate a service request.

Two include statements start the “gen_srq.c” program. The file “stdio.h” defines the standard location of the printf routine, and is needed whenever input or output functions are used. The file “hpibdecl.h” includes necessary prototypes and declarations for the analyzers sample programs. The path of these files must specify the disk drive and directory where the “include” files reside.

/* gen_srq.c */

/* * This example program initializes the Agilent 86100A scope, runs an autoscale, * then generates and responds to a Service Request from the scope. The program * assumes an Agilent 86100A at address 7, an interface card at interface select code 7, * and a signal source attached to channel 1. */

#include <stdio.h> /* location of: printf ( ) */ #include "hpibdecl.h"

void initialize ( ); void setup_SRQ ( ); void create_SRQ ( );

void main ( void ) {

init_IO ( ); /* initialize interface and device sessions */

initialize ( ); /* initialize the scope and interface */

setup_SRQ ( ); /* enable SRQs on scope and set up SRQ handler */

create_SRQ ( ); /* generate SRQ */

close_IO ( ); /* close interface and device sessions */

how to initialize the

} /* end main ( ) */

The routine “init_IO” contains three subroutines that initialize the analyzer and interface, and sets up and generate a service request.

The following segment describes the initialize subroutine.

6-17

Sample Programs

gen_srq.c - Generating a Service Request

Initializing the Analyzer

The following function is demonstrated in the “gen_srq.c” sample program.

/* * Function name: initialize * Parameters: none * Return value: none * Description: This routine initializes the analyzer for proper acquisition * of data. The instrument is reset to a known state and the interface is * cleared. System headers are turned off to allow faster throughput and * immediate access to the data values requested by queries. The analyzer * performs an autoscale to acquire waveform data. */

void initialize ( ) {

write_IO ("*RST"); /* reset scope - initialize to known state */ write_IO ("*CLS"); /* clear status registers and output queue */ write_IO (":SYSTem:HEADer OFF");/* turn off system headers */ write_IO (":AUToscale"); /* perform autoscale */

} /* end initialize ( ) */

*RST

The default configuration. Using this command ensures that the analyzer is in a known state before you configure it. able results. Without ent results in following runs if the analyzer is configured differently.

For example, if the trigger mode is normally set to edge, the program may function properly. But, if someone puts the analyzer in the advanced TV trigger mode from the front panel, the program may read measurement results that are totally incorrect. So, that the program can proceed from the same state each time.

The

AUToscale

should program the analyzer’s time base, channel, and trigger for the specific measurement to be made, as you would do from the front panel, and use whatever other commands are needed to configure the analyzer for the desired measurement.

command is a common command that resets the analyzer to a known

*RST

, a program may run one time, but it may give differ-

*RST

*CLS

command clears the status registers and the output queue.

finds and displays all signals that are attached to the analyzer. You

*RST

ensures very consistent and repeat-

defaults the scope to a set configuration so

6-18

Setting Up a Service Request

The following code segment shows how to generate a service request. The following function is demonstrated in the “gen_srq.c” sample program.

/* * Function name: setup_SRQ * Parameters: none * Return value: none * Description: This routine initializes the device to generate Service Requests. It * sets the Service Request Enable Register Event Status Bit and the Standard * Event Status Enable Register to allow SRQs on Command, Execution, Device * Dependent, or Query errors. */ void setup_SRQ ( ) {

/* Enable Service Request Enable Register - Event Status Bit */

Sample Programs

gen_srq.c - Generating a Service Request

write_IO ("*SRE 32"); /* Enable Standard Event Status Enable Register */

write_IO ("*ESE 36");

} /* end setup_SRQ ( ) */

/* enable Command Error - bit 4 - value 32 */ /* Query Error - bit 1 - value 4 */

6-19

Sample Programs

gen_srq.c - Generating a Service Request

Generating a Service Request

The following function is demonstrated in the “gen_srq.c” sample program.

/* * Function name: create_SRQ * Parameters: none * Return value: none * Description: This routine sends two illegal commands to the scope which will * generate an SRQ and will place two error strings in the error queue. The scope * ID is requested to allow time for the SRQ to be generated. The ID string * will contain a leading character which is the response placed in the output * queue by the interrupted query. */

void create_SRQ ( ) {

char buf [256] = { 0 }; //read buffer for id string int bytes_read = 0; int srq_asserted;

/* Generate query error (interrupted query)*/ /* send legal query followed by another command other than a read query response */ write_IO (":CHANnel2:DISPlay?"); write_IO (":CHANnel2:DISPlay OFF");

/* Generate command error - send illegal header */ write_IO (":CHANnel:DISPlay OFF");

/* get instrument ID - allow time for SRQ to set */ write_IO ("*IDN?"); bytes_read = read_IO (buf,256L);

/* add NULL to end of string */ buf [bytes_read] = '\0';

printf ( "%s\n", buf);

srq_asserted = check_SRQ ( );

if ( srq_asserted ) srq_handler ( );

} /* end create_SRQ ( ) */

6-20

Listings of the Sample Programs

Listings of the C sample programs in this section include:

• hpibdecl.h

• init.c

• gen_srq.c

• srq.c

• learnstr.c

• sicl_IO.c

• natl_IO.c

Listings of the HP BASIC sample programs in this section include:

• init.bas

• srq.bas

• lrn_str.bas

Sample Programs

Read the README File Before Using the Sample Programs

Before using the sample programs, be sure to read the README file on the disk that contains the sample programs.

6-21

Sample Programs

hpib_decl.h Sample Program

/* hpibdecl.h */

/* * This file includes necessary prototypes and declarations for * the example programs for the Agilent 86100A */ */

/* * User must indicate which HPIB card (HP or National) is being used. * Also, if using a National card, indicate which version of windows * (WIN31 or WIN95) is being used. */

#define HP /* Uncomment if using HP interface card */ /* #define NATL */

/* #define WIN31 */ /* For National card ONLY - select windows version */ #define WIN95

#ifdef HP #include <sicl.h> #else

#ifdef WIN95 #include <windows.h> /* include file for Windows 95 */ #include <decl-32.h> #else #include <windecl.h> /* include file for Windows 3.1 */ #endif

#endif

#define CME 32 #define EXE 16 #define DDE 8 #define QYE 4

#define SRQ_BIT 64 #define MAX_LRNSTR 14000 #define MAX_LENGTH 4096 #define MAX_INT 4192

#ifdef HP #define DEVICE_ADDR "hpib7,7" #define INTERFACE "hpib7" #else #define INTERFACE "hpib0"

#define board_index 0 #define prim_addr 7 #define second_addr 0

6-22

Agilent 86100A Programmer’s Guide

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

Introduction

Communicating with the Analyzer

Output Command

Device Address

Instructions

Instruction Header

White Space (Separator)

Program Data

Header Types

Duplicate Mnemonics

Query Headers

Program Header Options

Character Program Data

Numeric Program Data

Embedded Strings

Program Message Terminator

Common Commands within a Subsystem

Selecting Multiple Subsystems

File Names and Types

File Locations

Getting Started Programming

Initialization

Example Program

Using the DIGITIZE Command

Receiving Information from the Analyzer

String Variable Example

Numeric Variable Example

Definite-Length Block Response Data

Multiple Queries

Analyzer Status

Interface Functions

GPIB Interface Connector

GPIB Default Startup Conditions

Interface Capabilities

Command and Data Concepts

Communicating Over the Bus

Bus Commands

Message Communication and System Functions

Protocols

Status Reporting

Status Reporting Data Structures

Status Byte Register

Service Request Enable Register

Trigger Event Register (TRG)

Standard Event Status Register

Standard Event Status Enable Register

User Event Register (UER)

Local Event Register (LCL)

Operation Status Register (OPR)

Limit Test Event Register (LTER)

Mask Test Event Register (MTER)

Acquisition Event Register (AER)

Error Queue

Output Queue

Message Queue

Clearing Registers and Queues

Programming Conventions

Data Flow

Truncation Rule

The Command Tree

Infinity Representation

Sequential and Overlapped Commands

Response Generation

Sample Programs

Sample Program Structure

Sample C Programs

init.c - Initialization

init.c - Global Definitions and Main Program

init.c - Initializing the Analyzer

init.c - Acquiring Data

init.c - Making Automatic Measurements

init.c - Error Checking

init.c - Transferring Data to the PC

init.c - Converting Waveform Data

init.c - Storing Waveform Time and Voltage Information