Agilent 86100A Programming Manual

Agilent 86100A/B Wide-Bandwidth Oscilloscope Programmer’s Guide

Notices

duced in any form or by any means (including electronic storage and retrieval or translation into a foreign language) without prior agreement and written consent from Agilent Technologies, Inc. as governed by United States and international copyright lays.

Manual Part Number

86100-90049

Edition

First edition, June 2002 Printed in USA Agilent Technologies, Inc.

Lightwave Division 3910 Brickway Boulevard Santa Rosa, CA 95403, USA

Warranty

The material contained in this document is provided “as is,” and is subject to being changed, without notice, in future editions. Further, to the maximum extent permitted by applicable law, Agilent disclaims all warranties, either express or implied, with regard to this manual and any information contained herein, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. Agilent shall not be liable for errors or for incidental or consequential damages in connection with the furnishing, use, or performance of this document or of any information contained herein. Should Agilent and the user have a separate written agreement with warranty terms covering the material in this document that conflict with these terms, the warranty terms i n the separate agreement shall control.

Technology Licenses

The hardware and/or software described in this document are furnished under a license and may be used or copied only in accordance with the terms of such license.

Safety Notices

CAUTION

Caution denotes a 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

Warning denotes a 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.

Restricted Rights Legend

If software is for use in the performance of a U.S. Government prime contract or subcontract, Software is delivered and licensed as “Commercial c om pu ter so ftware” as defined in DFAR 252.227-7014 (June 1995), or as a “commercial item” as defined in FAR 2.101(a) or as “Restricted computer software” as defined in FAR

52.227-19 (June 1987) or any equivalent agency regulation or contract clause. Use, duplication or disclosure of Software is subject to Agilent Technologies’ standard commercial license terms, and non-DOD Departments and Agencies of the U.S. Government will receiv e no grea ter th an Restricted Rights as defined in FAR

52.227-19(c)(1-2) (June 1987). U.S. Government users will receive no greater than Limited Rights as defined in FAR

52.227-14 (June 1987) or DFAR 252.2277015 (b)(2) (November 1995), as applicable in any technical data.

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 Mne monics 1-7 Query Headers 1-7 Program Header Options 1-8 Character Program Data 1-9 Numeric Program Data 1-9 Embedded Strings 1-1 0 Program Message Terminator 1-10 Common Commands within a Subsystem 1-10 Selecting Mult ip le Subsystems 1-11 File Names and Types 1-11 File Locations 1-13 Getting St a rted 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 Status Reporting

Status Reporting Data Structures 3-6 Status Byte Register 3-9 Service Requ est Enable Register 3-11 Trigger Event Register (TRG) 3-11 Standard Event Status Register 3-12 Standard Event Status Enable Regi ster 3-13 User Event Register (UER) 3-13 Local Event Register (LCL) 3-14 Operation Status Register (OPR) 3-14 Clock Recovery Event Register (CRER) 3-14 Limit Test Event Register (LTER) 3-15 Acquisition Event Register (AER) 3-16 Mask Test Event Register (MTER) 3- 16 Precision Timebase Event Re gister (PTER) 3 - 1 7 Error Queue 3-17 Output Queue 3-18 Message Queue 3-18 Clearing Registers and Queues 3-18

4 Message Communication and System Functions

Protocols 4-2

5 Programming Conventions

Data Flow 5-2 Truncation Rule 5-3 The Command Tree 5-4 Infinity Representation 5-1 1 Sequential and Overlapped C ommands 5-11 Response Generation 5-11 EOI 5-11

6 Using Multiple Databases

Using Multiple Databa ses in Remote Programs 6-3 Downloading a Database 6-3

Contents-2

Auto Skew 6-4

7 Sample Programs

Sample Program Structure 7 -3 Sample C Programs 7-4 init.c - Initialization 7-5 init.c - Global Definitions and Main Program 7-6 init.c - Initializing the Analyzer 7-7 init.c - Acqu iring Data 7-8 init.c - Making Automatic Measurements 7-9 init.c - Error C hecking 7-11 init.c - Transferring Data to the PC 7-13 init.c - Converting Waveform Data 7-15 init.c - Storing Waveform Time and Voltage Information 7-16 gen_srq.c - Generating a Service Reque st 7-17 Listings of the Sample Programs 7-21 hpib_decl.h Sample Program 7-22 init.c Sample Program 7-24 gen_srq.c Sample Program 7-30 srq.c Sample Program 7-32 learnstr.c Sample Program 7-34 sicl_IO.c Sample Program 7-37 natl_IO.c Sample Program 7-40 multidatabase.c Sample Program 7-44 init.bas Sample Program 7-48 srq.bas Sample Program 7-54 lrn_str.bas Sample Program 7- 57

Contents

8 Common Commands

Receiving Common Commands 8-2 Status Registers 8-2 Common Commands 8-3 *CLS (Clear Status) 8-3 *ESE (Event Status Enable) 8-3 *ESR? (Event Status Register) 8-5 *IDN? (Identification Num ber) 8- 6 *LRN? (Learn) 8-6

Contents-3

Contents

*OPC (Operation Complete) 8-7 *OPT? (Option) 8-9 *RCL (Recall) 8-9 *RST (Reset ) 8 -1 0 *SAV (Save) 8-14 *SRE (Service Request Enable) 8-14 *STB? (Status Byte) 8-16 *TRG (Trigger) 8-18 *TST? (Test) 8-18 *WAI (Wait-to-Continue) 8-19

9 Root Level Commands

Status Reporting Data Structures 9-3 Root Level Commands 9-3 AEEN (Acquisition L im its Event Enable reg is ter) 9-3 ALER? (Acquisition Limits Event Register) 9-3 AUToscale 9-4 BLANk 9-5 CDISplay 9-6 COMMents 9-6 CREE (Clock Recovery Event Enable Register) 9-6 CRER? (Clock Recovery Event Register) 9-7 DIGitize 9-8 LER? (Local Event Register) 9-9 LTEE (Limit Test Event Enable register) 9-10 LTER? (Limit Test Event Register) 9-10 MODel? 9-11 MTEE (Mask Test Event Enable Register) 9-11 MTER? (Mask Test Event Register) 9-12 OPEE 9-12 OPER? 9-13 PRINt 9-13 RECall:SETup 9-13 RUN 9-14 SERial (Serial Number) 9-14 SINGle 9-15 STOP 9-15

Contents-4

STORe:SETup 9-15 STORe:WAVeform 9-16 TER? (Trigger Event Register) 9-16 UEE (User Event Enable register) 9-17 UER? (User Event Register) 9-17 VIEW 9-17

10 System Commands

DATE 10-2 DSP 10-3 ERRor? 10-3 HEADer 10-5 LONGform 10-6 MODE 10-7 SETup 10-7 TIME 10-9

Contents

11 Acquire Commands

AVERage 11-2 BEST 11-2 COUNt 11-3 LTESt 11-4 POINts 11-4 RUNTil 11-5 SSCReen 11-6 SSCReen:AREA 11-8 SSCReen:IMAGe 11-8 SWAVeform 11-9 SWAVeform:RESet 11-10

12 Calibration Commands

Mainframe Ca libration 12 -2 Module Calibration 12-2 Probe Calibration 12-4 CANCel 12-5 CONTinue 12-5 ERATio:DLEVel? 12-5

Contents-5

Contents

ERATio:STARt 12-6 ERATio:STATus? 12-6 FRAMe:LABel 12-6 FRAMe:STARt 12-7 FRAMe:TIME? 12-7 MODule:LRESistance 12-7 MODule:OCONversion? 12-8 MODule:OPO Wer 12-8 MODule:OPTical 12-8 MODule:OW A Velength 12-9 MODule:STA Tus? 12-9 MODule:TIME ? 1 2-9 MODule:VERTical 12-10 OUTPut 12-10 PROBe 12-11 RECommend? 12-11 SAMPlers 12-12 SDONe? 12-12 SKEW 12-13 SKEW:AUTO 12-13 STATus? 12-14 Calibration Procedure 12-14

13 Clock Recovery Commands

LOCKed? 13-2 RATE 13-2 SPResent? 13-4

14 Channel Commands

BANDwidth 14-2 DISPlay 14-3 FDEScription? 14-3 FILTer 14-4 FSELect 14-4 OFFSet 14-5 PROBe 14-6 PROBe:CALibrate 14-6

Contents-6

RANGe 14-6 SCALe 14-7 TDRSkew 14-8 UNITs 14-9 UNITs:ATTenuation 14-9 UNITs:OFFSet 14-9 WAVelength 14-9

15 Disk Commands

CDIRectory 15-2 DELete 15-3 DIRectory? 15-3 LOAD 15-4 MDIRectory 15-5 PWD? 15-5 SIMage 15-6 STORe 15-7

Contents

16 Display Commands

CGRade:LEVels? 16-2 CONNect 16-3 DATA? 16-3 DCOLor (Default COLor) 16-3 GRATicule 16-4 LABel 16-4 LABel:DALL 16-5 PERSistence 16-5 RRATe 16-6 SCOLor 16-7 SSAVer 16-8

17 Function Commands

DISPlay 17-2 FUNCtion<N>? 17-3 HORizontal 17-4 HORizontal:POSition 17-4 HORizontal:RANGe 17-5

Contents-7

Contents

INVert 17-6 MAGNify 17-6 MAXimum 17-7 MINimum 17-7 OFFSet 17-8 RANGe 17-9 SUBTract 17-9 VERSus 17-10 VERTical 17-11 VERTical:OFFSet 17-11 VERTical:RANGe 17-12

18 Hardcopy Commands

AREA 18-2 DPRinter 18-2 FACTors 18-4 IMAGe 18-5 PRINters? 18-5

19 Histogram Commands

Histograms and the Database 19-3 AXIS 19-4 MODE 19-4 SCALe:SIZE 19-5 SOURce 19-5 WINDow:BORDer 19-6 WINDow:DEFault 19-6 WINDow:SOURce 19-6 WINDow:X1Position 19-7 WINDow:X2Position 19-8 WINDow:Y1P osition 19-8 WINDow:Y2P osition 19-9

20 Limit Test Commands

FAIL 20-3 LLIMit 20-4 MNFound 20-4

Contents-8

RUNTil 20-6 SOURce 20-7 SSCReen 20-8 SSCReen:AREA 20-9 SSCReen:IMAGe 20-10 SSUMmary 20-10 SWAVeform 20-11 SWAVeform:RESet 20-12 TEST 20-12 ULIMit 20-13

21 Marker Commands

PROPagation 21-2 RPANnotation 21-3 STATe 21-3 X1Position 21-4 X1Y1source 21-5 X2Position 21-5 X2Y2source 21-6 XDELta? 21-6 XUNITs 21-7 Y1Position 21-7 Y2Position 21-8 YDELta? 21-9 YUNITs 21-9

Contents

22 Mask Test Commands

Mask Handling 22-3 Mask Files 22-3 ALIGn 22-4 AMEThod 22-4 COUNt:FAILures? 22-5 COUNt:FSAMples? 22-5 COUNt:HITS? 22-6 COUNt:SAMPles? 22-6 COUNt:WAVeforms? 22- 7 DELete 22-7

Contents-9

Contents

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

23 Measure Commands

Measureme n t Setup 23-3 User-Defin ed M easurements 23-3 Measurement Error 23-3 Making Measurements 23-4 ANNotation 23-6 APOWer 23-6 CGRade:AMPLitude 23-7 CGRade:BITRate 23-8 CGRade:COMP lete 23-8 CGRade:CRATio 23-9

Contents-10

CGRade:CROSsing 23-10 CGRade:DCDistortion 23-11 CGRade:DCYCle 23-12 CGRade:EHEight 23-12 CGRade:ERATio 23-13 CGRade:ESN 23-14 CGRade:EWIDth 23-15 CGRade:JITTer 23-15 CGRade:OFACtor 23-16 CGRade:OLEVel 23-17 CGRade:PEAK? 23-18 CGRade:PWIDth 23-18 CGRade:SOURce 23-19 CGRade:ZLEVel 23-20 CLEar 23-20 DEFine 23-21 DEFine CGRade 23-23 DELTatime 23-24 DUTYcycle 23-25 FALLtime 23-26 FREQuency 23-26 HISTogram:HITS? 23-27 HISTogram:M1S? 23-28 HISTogram:M2S? 23-29 HISTogram:M3S? 23-29 HISTogram:MEAN? 23-30 HISTogram:MEDian? 23-30 HISTogram:PEAK? 23-31 HISTogram:PP? 23-31 HISTogram:PPOSition? 23-32 HISTogram:SCALe? 23-33 HISTogram:STDDev? 23-33 NWIDth 23-34 OVERshoot 23-35 PERiod 23-36 PWIDth 23-36 RESults? 23-37

Contents

Contents-11

Contents

RISetime 23-40 SCRatch 23-41 SENDvalid 23-41 SOURce 23-42 TEDGe? 23-43 TMAX 23-44 TMIN 23-45 TVOLt? 23-45 VAMPlitude 23-46 VAVerage 23-47 VBASe 23-48 VMAX 23-49 VMIN 23-50 VPP 23-51 VRMS 23-51 VTIMe? 23-52 VTOP 23-53

24 TDR/TDT Commands

DCALib 24-3 PRESet 24-3 RATE 24-4 RESPonse 24-5 RESPonse:CALibra te 24-6 RESPonse:CALibra t e:CANCel 24-6 RESPonse:CALibrate:CONTinue 24-7 RESPonse:HORizontal 24-7 RESPonse:HORizontal:POSition 24-8 RESPonse:HORizontal:RANGe 24-9 RESPonse:RISetime 24-10 RESPonse:TDRDest 24-11 RESPonse:TDRTDT 24-11 RESPonse:TDTDest 24-12 RESPonse:VERT ic al 24-13 RESPonse:VERTical:OFFSet 24-14 RESPonse:VERTical:RANGe 24-15 STIMulus 24-16

Contents-12

25 Trigger Commands

ATTenuation 25-3 BWLimit 25-3 GATed 25-3 HYSTeresis 25-4 LEVel 25-4 SLOPe 25-4 SOURce 25-5

26 Timebase Commands

BRATe 26-2 POSition 26-2 PRECision 26-3 PRECision:RFRequency 26-4 PRECision:TREFerence 2 6-5 RANGe 26-5 REFerence 26-6 SCALe 26-7 UNITs 26-7

Contents

27 Waveform Commands

Data Acquisition 27 -2 Waveform Data and Preamble 27-2 Data Conversion 27-3 Conversion from Data Value to Units 27-3 Data Format for GPIB Transfer 27-5 BANDpass? 27-5 BYTeorder 27-5 COUNt? 27-6 DATA 27-7 FORMat 27-9 POINts? 27-11 PREamble 27-11 SOURce 27-15 SOURce:CGRade 27-16 TYPE? 27-17 XDISplay? 27-18

Contents-13

Contents

XINCrement? 27-18 XORigin? 27-19 XRANge? 27-19 XREFerence? 27-20 XUNits? 27-20 YDISplay? 27-21 YINCrement? 27-21 YORigin? 27-22 YRANge? 27-22 YREFerence? 27-23 YUNits? 27-23

28 Waveform Memory Commands

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

29 Language Compatib ility

Agilent 83480A Commands Not Used in the Agile nt 86100A/B 29-2

30 Error Messages

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

Contents-14

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 Mne monics 1- 7 Query Head ers 1-7 Program Header Options 1-8 Character Program Data 1-9 Numeric Progra m Data 1-9 Embedded Strings 1-10 Program Message Termi nator 1-10 Common Commands within a Subsystem 1-10 Selecting Multipl e Su bsystems 1-11 File Names and Types 1-11 File Locations 1-13 Getting St arted Programming 1-15 Initialization 1-15 Example Program 1-17 Using the DIGITIZE Command 1-18 Receiving Info rm a tion 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

Introduction

Introduction to Programming

This chapter introduces the basics for remote programmin g of an analy z er. 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 anal yze r.

• 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 stat e ment for sending co m mands 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 inter f ac e, messages are p lac ed on the bus using a n o utput command and passing the device address, program message, and a terminator. Passing the devic e a ddress ensures that the program mes sa ge 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 addres s represents the ad dress of the device being programm e d . 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 4, “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 c om mands like OUTPU T, ENTER, and CLEAR, to convert the examples.

Device Address

The location where the device address must be specified depends on the programming lan guage you are using. In some languag es, it may be speci f ied 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 program s , 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 " co mma n d. There are only a few instruct io ns 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 m ore command mnemo nics separated by colons (:) that repr esent the operation to be performed by the a n alyzer. See

Chapter 5, “Programming Conventi ons” for more information.

Queries are formed by adding a question mark (?) to the end of the header. Many instructi o ns can be used as either commands or queries, depending on whether or no t you i nclu de the questi on mark . The c ommand an d quer y 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 da ta param e ters, 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 accept able val-

ues. When there is more t ha n o ne da ta pa rameter, 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 si ngl e 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 CHAN 1), 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 sub sy stem, and the second mnemonic sele c ts the function within that subsystem. The mne m onics within the compound message are separated by col ons. For example:

To execute a si ngle function with in a subsystem:

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

For example:

OUTPUT 707;”:CHANNEL1:B AN DWIDTH HIGH”

Combining Commands in the Same Subsystem

To execut e m o re tha n 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 b etween the asterisk (*) and the comm and 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 scal e:

:CHANNEL1:RANGE .4

To set the hor iz o ntal time base to 1 se c ond full scale:

:TIMEBASE:RANGE 1

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

Query Headers

Command headers immediatel y followed by a que s tion mark (?) ar e queries. After receivin g 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 stateme nt:

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 anal yzer i s curr e ntl y con figured. 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 se nd th e quer y :MEA SURE :RIS ETIM E? you must fol low it with an input statem ent. In HP BASIC, this is usu a ll y done with an ENTER statement imm ediately follow ed by a variable name. This statem ent 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.

Y ou may send program command and query headers in either long form (complete spelling ) , short form (abbreviated spel ling), or any combination of long form and short form. For exampl e :

:TIMEBASE:DELAY 1E-6 is the long form. :TIM:DEL 1E-6 is the short form.

Using Long Form or Short Form

Programs written in long form are easily read and are almost self-documenting. The short form syntax conserves the amount of computer memory needed for program storage and reduces I/O activity.

The rules for the short form syntax are described in Chapter 5, “Programming

Conventions”.

1-8

Introduction

Character Program Data

Character program data is used to convey paramet er info rm ati on 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 ex ists), may be sent. U p percase and lowercase letters may be mixed freely. When receiving responses, uppercase letters are used ex clusively.

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 numer ical ly.

For numeric program data, you can use exponential notati on 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 informa tion see Chapter 2, “Interface Functions”.

All numbers are expected to be strings of ASCII characters.

• When sending th e num ber 9, you would send a byte representing the ASCII code for the character “9” (which is 57).

• A three-digit number li ke 102 would take up three bytes (ASCII codes 49, 48, and 50). The numb er of bytes is f igured automa tically whe n you include t he entire instruction in a string.

1-9

Introduction

Embedded Strings

Embedded strings conta in g rou ps of alphanumeric characters which are treated as a unit of data by the analyzer. An example of t his is the line of text written to the advisory li ne of the analyzer with the :SYSTEM:DSP command:

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

You may delimit em b edded 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 contr ol 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 a na lyzer, the analyzer remains in the select ed subsystem. For example, if the program messag e

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

is received by the analyzer, the analyzer turns averaging on, th en 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 , c o m p l etes the autoscal e o peration, then sets the acquire average count. In this example, :ACQUIRE must be sent again after the AUTOSCALE comm a nd to re-enter the AC QU IRE subsystem an d se t c o unt.

Selecting Multip le Subs yst em s

You can send multipl e prog ram commands and program queries for di ffe rent subsystems on the same line by separating each command with a semicolon. The colon follow ing the semicolon lets you enter a new su bsystem. For example:

<program mnemonic><data>;:<program mnemonic><data><terminator> :CHANNEL1:RANGE 0.4;:TIMEBASE:RANGE 1

Y ou Can Combine Compound and Si m ple Commands

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

File Names and Types

When specifying a file name in a remote c om mand, enclose the na m e in double quotation ma rks, such as "filen a me". If you specify a path, the path should be included in the quotation ma rks.

Y ou 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" or “.\screen1.jpg”

• a simple file name: "Memo r y1.txt"

All files stored usi ng remo te commands have file name extensions.The following table shows the file name exten si o n 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, .jpg, .tif Mask .msk, .pcm TDR/TDT .tdr

If you do not specify an ex tension when stor ing a file, or specif y a n incorrect extension, it will be corrected automatically accordi ng to the followi ng rules :

• No extension spe ci f ied: add the extension for th e file type.

• Extension does not match file type: retain the filename, (including the current

extension) and add the appropriate extension. Y ou do not need to use an extension when loading a file if you use the optional

destination para m eter. For example, :DISK:LOAD "STM1_OC3",SMASK will automatically add .msk to the file name.

Note

For .gif and .tif file formats, this instrument uses LZW compression/decompression licensed under U.S. patent No 4,558,302 and foreign counte rpart s. End user should not modify, copy, or distribute LZW compression/decompression capability.

For .jpg file format, this instrument uses the .jpg software written by the Independent JPEG Group.

The following ta b le shows the rule s used when loadi ng a specified file.

Table 1-2. Rul es f or Loading Fi l es

File Name Extension Destination Rule

No extension Not specified Default to internal waveform format; add .wfm

extension

1-12

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

File Name Extension Destination Rule

Introduction

File Locations

Extension does not match file type

Extension matches file type Not specified Use file name with no alterations; destination is

No extension Specified Add extension for destination type; default f or

Extension does not match destination file type

Extension matches destination file type

Not specified Default to internal waveform format; add .wfm

extension

based on extension file type

waveforms is internal format (.wfm)

Specified Retain file name; add extension for destination

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

Specified Retain file name; dest in a tion is as specified

Note

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

File Locations

If you don’t specify a director y w hen 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 Scal e C:\User Files\colorgrade-grayscale Screen Image C:\User Files\screen images Mask C:\Scope\masks (standard masks)

C:\User Files\masks (user-defined masks)

TDR/TDT calibration data C:\User Files\TDR normalization

1-13

Introduction

File Locations

When loading a file, yo u can specify the full path name, a rel ative path name, or no path name. The following table shows the rules for locating files, based on the path specif ied.

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, set with the command :DISK:CDIR. The present working directory can be read with the query :DISK: PWD?

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

(C:\User Files) 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 mes sage.

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

1-14

Introduction

Getting Started Programming

The remainder of this chapter discusse s ho w to set up the analyzer, how to retrieve setup information and measurement re su lt s, how to digi ti ze a waveform, and how to pass data to the com puter. Chapter 23, “Measure Com-

mands” describes sending me as urement data to the analyzer.

Initialization

T o make sure the bus and all appropriate interfaces are in a known state, begin every program wi th an initializa ti o n statement. For e xample, 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 8, “Com-

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

ual for information on initializing the interface.

Autoscale

The AUTOSCALE fea tu re of Agilent Technologies digitizing analyzers performs a very useful function on unknown waveforms by auto mati cally s ettin g up the vertical channel, time base, and trigger leve l of the analy zer.

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 Progra m

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 initial iz e s the analyzer interface to a known sta te.

• Line 20 initializes the analyzer to a preset stat e.

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

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

• Lines 60 throug h 70 set the vertical range to 160 millivolts full scale and th e center screen at −40 millivolts.

• Lines 80 throu gh 9 0 co nfig u re th e a nal yzer t o t rigge r at −0.4 volts with normal triggering.

• Line 100 turns system headers off.

• Line 110 turns the grid off.

1-17

Introduction

Using the DIGITIZE Comma nd

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 furt he r a na l ysis. The captured data co ns ists 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 DI GITIZE command in Chapter 9, “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:DA TA? query to get waveform data, specify the WAVEFORM parameters.

The number of data points comprising a waveform varies accordin g to the number requeste d in the ACQUIRE subsystem. The ACQUIR E subsystem determines the numb er of data points, type of acquis ition, and number of averages used by the DIGITIZE command. This allows you to specify exactly what the digitize d information conta ins. 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 receivin g the :WAVEFORM:DATA? query, the analyzer will start passing the waveform information when queried.

1-18

Introduction

Receiving Information from the Analy zer

Digitized wave for ms ar e pas se d from t he analy zer to th e compu ter by se ndin g a numerical representation of each di gitized point. The format of the numerical representation is controlled with the :WA VEFORM:FORMA T command and may be selected as BYTE, WORD, or ASCII.

The easiest method of e n te ri ng a digitized waveform depe nds on data structures, available formatting, and I/O capabilities. You must scale the integers to determine the vol t a g e v a lue of each point. Th ese integers are p assed starting with the leftmost po in t o n th e a nalyzer's display. For more information, refer to Chapter 27, “Waveform Commands”.

When using GPIB, a digitize oper a tion may be aborted by sending a Dev ice Clear over the bus (for example, CLEAR 707).

Note

The execution of the DIGITIZE command is subordinate to the status of ongoing limit tests. (See commands ACQuire:RUNTi l on page 11-5, MTEST:RUNTil on page 22-11, and LTEST:RUNTil on page 20-6.) The DIGITIZE command will not capture data if the stop condition for a limit test has been met.

Receiving Information from the Analyzer

After receiving a query (command header followed by a question mark), the analyzer place s 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 interf ace to the computer. The input statement for receiving a response message from an analyzer' s out put 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 se tti ng for the range in the stri ng variab le 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 th a t query with an input s t at e ment. In HP BASIC, this is usually done with an ENTER statement.

1-19

Introduction

String Variable Example

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.

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. Refe r to the specific com m a nds for the formats and type s of data returned from queries.

For the example pro g ra ms, assume that the de v ic e be ing programmed is at device address 707. The actual address depends on how y ou have configured the bus for your own applica tion.

In HP BASIC 5.0, string variables are cas e-sensitive, and must be express ed exactly the same way each time th ey a re used. This exam pl e 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

1-20

Introduction

Definite-Length Block Res p on s e Dat a

After running this program, the computer displays:

Definite-Length Block Response Data

Definite-length block response data allows any type of device-dependent data to be transmitted over the sy stem interface as a series of 8-bi t bi nary 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 synt ax wou ld be:

#44000 <4000 bytes of data> <terminator>

The leftmost “4” re presents the numbe r of dig its in the number of byte s, 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 nume ri c variables. For ex a mple, you could read the result of the query :TIMEBAS E:R ANG E?;DELAY? i nto th e st ri ng v ar iabl e Re sult s$ with the command:

ENTER 707;Results$

When you read the result of multiple queries into string variables, each response is sepa rated by a semicolon. For example, the response of t he query :TIMEBASE:RANGE?;DELAY? would be:

<range_value>;<delay_value>

Use the following program message to read the query :TIMEBASE:RANGE?;DELAY? into mult ip le n umeric 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 3, “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 manage ment issue s, 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. Fin ge r ti g hten the captive screws on both end s of the GPIB cable to avoid accidentally disconnecting the cable during operation.

A maximum of fifteen GPIB compatible instruments (including a computer) can be intercon nected in a system by stacking conn ec tors. This allo w s the analyzers to be connected in virtually any configuration, as lo ng as ther e is a path from the compu ter to every device operating on the bus.

CAUTION Avoid stacking more than three o r four cables on any o ne connector. Multiple

connectors produce leverage that can damage a connector mounting.

GPIB Default Startup Conditions

The following default GP IB conditions are established during power-up.

• The Request Service (RQS) bit in the status byte register is set to zero.

• All of the event re gisters, the Standa rd Event Statu s 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 Po ll/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 Trigg e r 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, com m and m ode and data mode. The bus is in the command mode when the Attention (ATN) control line is true. The command mod e is used to send talk and listen addresse s a n d 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 A TN line is false. The data mode is used to convey device-dependent messages across the bus. The de vice-de pen de nt messages include all of the anal yz e r specific comm ands, 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 th e pro gr am 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 analyzer on the GPIB must have a unique analyzer address between dec-

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 i s typically “7” for GPIB interface cards .

imal 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 48 8.1 bus commands ( ATN true). IEEE

488.2 defines many of the actions that are taken whe n these commands are received by the analyzer.

Device Clear The device clear (DCL) and selected device clear (SDC) commands clear the

input buffer and output queue, reset the parser, and clear any pending commands. If either of these commands is sent during a digitize operation, the digitize operat io n is aborted.

Group Execute Trigger

Interface Clear The interface clear (IFC) command halts all bus activity. This includes unad-

The group execute t rigge r (GET ) comman d arms th e trig ger. This is the same action produced by sending the RUN command.

dressing all listeners and the talker, disabling serial poll on all devices, and returning control to the system computer.

2-5

Status Reporting Data Structures 3-6 Status Byte Register 3-9 Service Request Enable Register 3-11 Trigger Event Register (TRG) 3-11 Standard Event Status Register 3-12 Standard Event Status Enable Register 3-13 User Event Register (UER) 3-13 Local Event Register (LCL) 3-14 Operation Status Register (OPR) 3-14 Clock Recovery Event Register (CRER) 3-14 Limit Test Event Register (LTER) 3-15 Acquisition Event Register (AER) 3-16 Mask Test Event Register (MTER) 3-16 Precision Timebase Event Re gister (PTER) 3-17 Error Queue 3-17 Output Queue 3-18 Message Queue 3-18 Clearing Registers and Queues 3-18

Status Reporting

An overview of the anal yzer's status re portin g struc ture is shown in the f ollowing figure. The status reportin g structure shows yo u ho w to m o ni to r specific events in the an alyzer. 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 clea re d w h e n you initialize th e analyzer.

• To generate a service request (SRQ) interrupt to an external computer, enable at least one bit in the Sta tus Byte Register.

The Status Byte Register, the Standard Event Status Register group, and the Output Queue are define d as the Standard Status Data Structure Model in IEEE 488.2-1987. IEEE 488.2 defines data structures, commands, and com mon bit definitions for sta tus reporting. There are also analyze r-defined structures and bits.

3-2

Status Reporting

Figure 3-1. Status Reporting Overview Block Diagram

The status reporting structure co nsists of the regis te rs shown in this figu re .

3-3

Status Reporting

The following tab le lists the bit defi nitions for each bit in the sta tus reporting data structure.

Table 3-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 t he pa r s e r de t e c t ed an error. EXE Execution Error Indicates if a parameter was out of range or was

inconsistent with the current set t ings.

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

operation for device dependen t 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

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

3-4

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

Event Status Register have occu rred.

in the User Event Register.

Status Reporting

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

Bit Description Definition

COMP Complete Indicates the specified test has completed. LTEST Limit Tes t Indicates that one of the enabled conditions in the Limit

Test Register has occurred.

MTEST Mask Test Indicates that one of the enabled conditions in the Mask

Test Register has occurred.

ACQ Acquisition Indicates that acquisition test has completed in the

Acquisition Register.

CLCK CloCk Indicates that one of the enabled conditions in the Clock

Recovery Register has occurred.

UNLK UNLoCKed Indicates that an unlocked or trigger loss condition has

occurred in the Clock Recovery Module.

LOCK LOCKed Indicates that a locked or trigger capture condition has

occurred in the Clock Recovery Module.

NSPR1 N o Signal Present

Receiver 1

SPR1 Signal Present

Receiver1

NSPR2 N o Signal Present

Receiver 2

SPR2 Signal Present

Receiver2

LOSS Time Reference Loss Indicates the Precision Timebase (provided by the

PTIME Precision Timebase Indicates that one of the enabled conditions in the

Indicates that the Clock Recovery Module has detected the loss of an optical signal on re ceiver one.

Indicates that the Clock Recovery Module has detected an optical signal on receiver one.

Indicates that the Clock Recovery Module has detected the loss of an optical signal on receiver two.

Indicates that the Clock Recovery Module has detected an optical signal on receiver two.

Agilent 86107A module ) has detected a time reference loss due to a change in the reference clock signal.

Precision Timebase Register has occurred .

3-5

Status Reporting

Status Report ing Data Structures

Status Reporting Data Structures

The different status re porting data structures, descriptions, and interactions are shown in the following figure. To make it possible f or a ny of the Standard Event Status Register bits to generate a summary bit, the corresponding bits must be enabled. These bits a re enabled by using the *ESE common command to set the corresponding bi t in the Standard Event Status Enab le Register.

T o 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 th e corre sponding 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 8, “Common

Commands”.

3-6

Status Reporting

Status Reporting Data Structures

Figure 3-2. Status Reporting Data Structures

3-7

Status Reporting

Status Report ing Data Structures

Status Reporting Data Structures (continued)

3-8

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 qu eues.

If the Status Byte Regist er is to be used with the Service Request Enable Register to set bit 6 (RQS/MSS) and to ge ne rate an SRQ, at least one of the summary bits must be enabled, then set . Also, event bits in all other status registers mus t be specificall y enabled to generate the summary bit t ha t 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 rem e mber is that, if you are usi n g a n SRQ interrupt to an external computer, the serial poll command clears bit 6. Clearing bit 6 allows the analyzer to generate another SRQ inter ru pt whe n another enabled event occurs.

The only other bit in the Status Byte R eg ister affected by the *STB? query i s the Message Available bit (bit 4) . If ther e are no ot her mes sag es in th e Out put 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 enab led to generate an SRQ, bit 6 (weight = 64) is not set.

3-9

Status Reporting

Status Byte Register

Example 1 This HP BASIC example uses the *STB? que ry to rea d th e con ten ts o f th e ana -

lyzer’s Status Byte Register when none of the register's summary bits are enabled to generate an SRQ int er rupt.

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 fi rst enabled summary bit is set, and is cleared when the Status Byte Register is read by the serial poll command.

Example 2 This exam ple uses the HP BASIC seria l poll (SPOLL) co mmand to read the

contents of the ana lyzer’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.

3-10

Status Reporting

Service Request En able Register

Service Request Enable Register

Setting the Servi ce Request En able Regist er bits enab les corresp onding bit s in the Status Byte Register. These enabled bits can then set RQS and MSS (bit 6) in the Status Byte Regist er.

Bits are set in th e Service Request Enable Regis t er 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 Figure3-2.

Example This example sets bit 4 (MAV) and bit 5 (ESB) in the Service Request Enable

OUTPUT 707;"*SRE 48"

This example uses t he pa ra meter “48” to allow the analyzer to generate an SRQ interrupt under the following con d itions:

• 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) comm a nd. 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 m ust clear the event register after each time it is set.

3-11

Status Reporting

Standard Event Stat u s Re gis te r

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 Depe ndent Error

• QYE - Query Error

• RQC - Request Control

• OPC - Operation Complete

When one of these event s occurs, th e correspo nding bit is set in the regist er . If the corresponding bit is al so 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 send ing the *ESR? quer y. The value returned is the total bit weights of all of the bits set at the present time.

Example This exampl e uses the *ESR? query to read the cont ents 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.

3-12

Status Reporting

Standard Event Sta tus En able Register

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 comma n d 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 d ecima l weight s of th ese bits is 60 . Ther efore, yo u can enable any o f these bits to generate the summary bit by sendi ng:

OUTPUT 707;"*ESE 60"

Whenever an erro r occurs, the analyzer sets one o f 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 By te Register.

If bit 5 (ESB) in the Status Byte Register is enabled (via the *SRE command), a service request interr upt (SRQ) is sent to the extern al com puter.

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. Fo r example, if you want to enable the LCL bit, you send a mask value of 1 with the UEE command; otherwise, se nd a mas k value of 0.

3-13

Status Reporting

Local Event Register (LCL)

This register se ts the LCL bit in the Use r Event Registe r a nd the USR bit (bit

1) in the Status byte . It indicates a remo te -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 CLCK bit (bit 7), the LTEST bit (bit 8), the ACQ bit (bit 9) and the MTEST bit (bit 10).

The CLCK bit is set when any of the enabled conditions in the Clock Recovery Event Register have o c cu r red.

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 MTEST bit is set when the Mask Test either fails specified conditions or satisfies its completion criteria, setting the c orresponding 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 O PER? qu er y. The register output is enabled or dis a b led using the mask value supplied with the OPEE command.

Clock Recovery Event Register (CRER)

This register hosts the UNLK bit (bit 0), LOCK bit (bit 1), NSPR1 bit (bit 2), SPR1 bit (bit 3), NSPR2 bit (bit 4) and SPR2 (bit 5).

Bit 0 (UNLK) of the Clock Recovery Event Register is set when Clock Recovery module becomes unlocked or tri gg er los s has occurred for the 83494A family of modules.

Bit 1 (LOCK) of the Clock Recovery Event Register is set when Clock Recovery module beco m es locked or a trigger capture has occ u rred for the 83494A family of modules.

3-14

Status Reporting

Limit Test Event Register (LT E R)

Bit 2 (NSPR1) of the Clock Recovery Event Register is set when Clock Recovery module transitions to no longer detecting an optical signal on receiver one.

Bit 3 (SPR1) of the Clock Recovery Event Register is set when Clock Recovery module transitions to detecting an optical signal on receiver one.

Bit 4 (NSPR2) of the Clock Recovery Event Register is set when Clock Recovery module transitions to no longer detecting an optical signal on receiver two.

Bit 5 (SPR2) of the Clock Recovery Event Register is set when Clock Recovery module transitions to detecting an optical signal on receiver two.

The Clock Recovery Event Register is read and cleared with the CRER? query. When either of the UNLK, LOCK, NSPR1, SPR1 , NS PR2 o r SPR2 bits are set,

they in turn set CLCK bit (bit 7) of th e Op eration Status Register. Results from the Clock Recovery Event Register can be masked by using the CREE command to set the Clock Recovery Event Enable Register . Refer to the CREE command in Chapter 9, “Root Level Commands” for enable and mask value definitions.

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 wh en the Limit Test fails. Failure criteri a fo r the Limit Test are defined by the LTESt:FAIL command.

The Limit Test Event Register is read and cleared with the LTER? query. 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 preventin g the m 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

3-15

Status Reporting

Acquisition Event Register (AER)

Bit 0 (COMP) of the Acquisition Ev e n t R egister is set whe n 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 bi t is set, it in turn sets th e AC Q bit (bit 9) of the Operation Status Register. Results from t he A cqu isit ion Regi ster can be mask ed by u sin g the AEEN command to s et the Ac qui si tion Ev ent Enable Regi st er to th e va lue

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

Mask Test Event Register (MTER)

Bit 0 (COMP) of the Mask Test Event Regist er is set when the Mask Test completes. The Mas k Test completion c riteria are set by the M TESt:RUMode co mmand.

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

The Mask Test Event Register is read and cleared with the MTER? quer y. When either the COMP or FAIL bits are set, they in turn set the MTEST bit

(bit 10) of the Oper a ti o n Status Register. You can mask the COMP and FAIL bits, thus preventing them from setting the MTEST bit, by setting corresponding bits to zero 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

3-16

Status Reporting

Precision Timebase Event Re gister (PTER)

Precision Timebase Event Register (PTER)

Bit 0 (LOSS) of the Precision Timebase Ev ent Register is se t w h e n loss of the time reference occurs. Time reference is lost when a change in the amplitude or frequency of th e ref erenc e clock signa l is de tec ted. Th e Pre cisio n T im ebase Event Register is rea d a nd c lea red with the PTER? query.

When the LOSS bit is set, it in turn sets the PTIME bit (bit 11) of the Operation Status Register. Results from the Precisi on Timebase R eg ister can be masked by using the PTEE command to set the Precision Timebase Event Enable Register to the value 0. You enable the LOSS bit by setting the mask value to 1.

Install the Precisio n Timebase Module

The Precision Timebase feature re quires the installation of the Agilent86107A Precision Timebase Module.

Error Queue

As errors are dete c ted, they are placed in an error queue. This queue is f irst in, first out. If the error queue overflows, th e la st error in the queue is replaced with error –350, “Queue ov erflow”. Any time the queue overflows, the oldest errors remain in the queue, and the most rece nt error is discarde d. The length of the analyzer's error queue is 30 (29 positions for the error messages, and 1 posit ion for the “Queue overfl o w ” 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 10, “System Commands”. For a complete list of error messages, re fer to Chapter 30, “Error Messages”.

3-17

Status Reporting

Output Queue

The output queue sto res the analyzer-to-computer responses th a t a re 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 HPBASIC ENTER statement.

Message Queue

The message queue contains the text of the last message w ritten to the advisory line on the scr ee n 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 statu s bit in the Status Byte Registe r.

Clearing Registers and Queues

The *CLS common command clears all event registers and all queu es except the output queue. If *CLS is sent immediately following a program message terminator, the output queu e is also cleared.

3-18

Status Reporting

Clearing Registers and Queues

Figure 3-3. Status Reporting Decision Chart

3-19

Status Reporting

Clearing Registers and Queues

3-20

Protocols 4-2

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

Message Communication and System Functions

This chapter describes the operation of analyzers that ope rat e in comp liance with the IEEE 488.2 (syntax) standard. It is intended to give you enough basic information about the IEEE 488.2 stand a rd to s ucce ss ful ly prog ram the analyzer. You can find additional detailed information about the IEE E 488 .2 s tandard in ANSI/IEEE Std 488.2-1987, “IEEE Standard Codes, Formats,

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 st andar d); 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 sp ecifically defined by IEEE 488.2.

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 defi ning 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.

4-2

Message Communication and System Functions

Protocols

Input Buffer 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.

Output Queue The output queue of the analyzer is the memory area where all output data, or

response messages, are stored until read by the computer.

Parser 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 terminato r.

Protocol Overview The analyzer and computer communicate using program messag es and

response messages . These mes sages serve as th e conta iners in to 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.

4-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 messa ge asso ciated with a query message before sending another program message to the same analyzer.

The analyzer a l lo ws the computer to send multip le queries in on e q u ery 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 th e or der they are received.

Protocol Exceptions

If an error occurs during the information exchange , the exchange may not be completed in a nor m a l ma nner.

Suffix Multiplier The suffix multipliers that the analyzer will accept are shown in Table 4-1.

Table 4-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

4-4

Message Communication and System Functions

Suffix Unit The suffi x un its that the analyzer will accept are shown in Table 4-2.

Table 4-2. <suffix unit>

Suffix Referenced Unit

V Volt s Second W Watt BIT Bits dB Decibel % Percent Hz Hertz

Protocols

4-5

Data Flow 5-2 Truncation Rule 5-3 The Command Tree 5-4 Infinity Representation 5- 11 Sequential and Overlapped Co m mands 5-11 Response Generation 5-11 EOI 5-11

Programming Conventions

This chapter describes conventions used to program the Agilent 86100A / B , and conventions used throug hout this manual. A block diagram and des cription 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-si g nal processing is applied to th e 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 analyze r.

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 displ a yed. The time it tak es fo r the sample data to b e di splayed depends on the number of post processes you have selected.

Averaging your sampled data helps remove an y unwanted noise from your waveform.

You can store your sample da ta 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 y our circui t may be performing to verify that your circuit is operati ng 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 sam pl e data points, giving an analog look to the waveform. This is sometimes called linear interpolation.

Truncation Rule

The following tr unc a tion 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 tab le shows how the truncation rule is applie d 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 f or m . 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/B and the relationship of th e comm ands to each other. The IEEE 488.2 common commands are not listed as part of the command tr ee 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 comma nds, 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 ex a m ple of a common comm a nd.

• 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 begi nning of a program mess age 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 giv en time. When th e a n a l yzer is initia l ly turned on, th e command parser is set to the roo t o f the command tree a nd no subsystem is sel e c ted.

Using Multiple Databases

Using Multip le Databases

Multiple Databases

Eye/Mask measurements in the Agilent 86100A are based on statistical data that is acquired and stored in the color grade/gray scale database. The color grade/gray scale database consists of all data samples displayed on the display graticule. The measure ment algorithms are dependent upon histograms derived from the database. This database is internal to the instr ume nt ’s appli- cations. The color grade/gray scale database cannot be im ported into an external database application.

Eye/Mask Measurem ents

If you want to perform an eye measurement, it is necessary that y ou fi rst produce an eye diagra m by triggering the instrument wit h a syn c hr onous clock signal. Measurements made on a pulse waveform while in Eye/Mask mode will fail.

Firmware revision A.03.00 and later allows for multiple color grade/gray scale databases to be acquired and displayed simultaneously. his includes

• all four instrument channels

• all four math functions

• one saved color grade/gray scale file

The ability to use multiple databases allows for the comparison of

• channels to each other

• channels to a saved color grade/gray scale file

• functions to the channel data on which it is based

The advantage of acquiring and displaying channel s and fu ncti ons simu ltaneously is test times are greatly reduced. For exa mple, the time taken to acquire two channels in parallel is appr oximately the same time taken to acquire a single channel.

6-2

Using Multiple Databases

Using Multiple Databases in Remote Pr og rams

Using Multiple Databases in Remote Programs

You will notice that througho ut thi s manu al, most command s that contr ol histograms, mask tests, or color grade data have additional opti onal parame te rs that were not available in firmware revisions prior to A.03.00. You can use the commands to control a single channel or add the argument APPend to enable more than one channel. The following example illustrates two uses of the CHANnel<n>:DISPlay comm and.

SYSTem:MODE EYE CHANnel1:DISPlay ON CHANnel2:DISPlay ON

The result using the above set of commands, is Channel 1 cleared and disabled while Channel 2 is enabled and displayed.

However, by adding the argument APPend to the last command of the set, both Channels 1 and 2 will be enabled and displayed .

SYSTem:MODE EYE CHANnel1:DISPlay ON CHANnel2:DISPlay ON,APPend

For a example of us ing multiple datab a ses, refer to “multidatabase.c Sample

Program” on page 7-44.

Downloading a Database

The general process for downloading a color grade/g ra y scale database is as follows:

1 Send the command :WAVEFORM :SO URCE CGRADE

This will select the color grade/gray scale database as the waveform source.

2 Issue :WAVefor m :FORMat WORD .

Database downloads only support word formatted data (16-bit integers).

3 Send the query :WAVeform:DATA?

The data will be sent by means of a block data transfer as a two-dimensional array, 450 words wide by 320 words high (refer to “Definite-Length Block

Response Data” on page 1-21). The data is transferred starting with the upper

left pixel of the display graticule, column by column, until the lower right pixel is transferred.

4 Send the command :WAVeform:XORigin to obtain th e ti m e of the left column.

6-3

Using Multip le Databases

Auto Skew

5 Send the command :WAVeform:XINC to obtain the time incre ment of each

column.

6 Send the command :WAVeform:YORigin to obtain the voltage or power of the

vertical center of the database.

7 Send the command :WAVeform:YORigin to obtain the voltage or power of the

incremental row. The informatio n f rom steps 4 through 7 can also be obtained with the com-

mand :WAVeform:PREambl e.

Auto Skew

Another multip le database feature is the au t o sk ew . You can use the auto skew feature to lse t the ho rizontal skew of mul tiple, active cha nnels with the same bit rate, so that the waveform crossings align with each other. This can be very convie nt when viewing multiple eye di a grams simultaneously. Slight differences between channels and test devices may cause a phase difference between channels. Auto skew ensures that each eye is properly aligned, so that measurements and mask tests can be properly executed.

In addition, auto skew opti m ize s the instrument trigger level. Prior to auto skew , at least one channel must display a complete eye diagram in order to make the initia l bit rate measurement.

Acquisition Time

Auto skew requires more data to be sampled; therefore, acquisition time during auto skew is slightly longer than acquisition time during measurements.

6-4

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

init.c - Initia lization 7-5 init.c - Global D efi nitions and Main Pro g ra m 7-6 init.c - Initializing the Analyzer 7-7 init.c - Acqu iring Data 7 -8 init.c - Making Automatic Measurements 7-9 init.c - Error C hecking 7- 1 1 init.c - Transferring Data to the PC 7-13 init.c - Converting Waveform Data 7-15 init.c - Storing Waveform Time and Voltage Information 7-16 gen_srq.c - Generating a Service Reque st 7-17

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

Listings of the Sample Programs 7-21

hpib_decl.h Samp le Program 7-22 init.c Sample Program 7 -24 gen_srq.c Sample Progr a m 7-30 srq.c Sample Program 7-32 learnstr.c Sample Program 7-34 sicl_IO.c Sample Program 7-37 natl_IO.c Sample Program 7-40 multidatabase.c Sample Program 7-44 init.bas Sample Program 7-48 srq.bas Sample Program 7-54 lrn_str.bas Sample Program 7-57

Sample Programs

Sample programs for the Agilent 86100 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 HPBASIC examples are incl u de d.

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

• multidatabase.c

The HP BASIC examples include:

• init.bas

• srq.bas

• lrn_str.bas

The sample prog ra m listings are included at the end of this chapter.

7-2

Sample Programs

Sample Program Structur e

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 wavefor m dat a and voltage/timing information ( t he preamble)

into the computer.

7-3

Sample Programs

Sample C Programs

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

7-4

Sample Programs

init.c - Initialization

/* init. c */ /* Command Order Example. This program demonstrates the order of commands suggested for operati on of the analyzer via GPIB.

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 86100 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 ( ); /* conve rts data to time/voltage values */ void store_csv ( ); /* stores time/voltage pairs to comma-separated

/* variable file format */

The include sta t ements start the program. Th e 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 di g iti ze d data to ti m e and voltag e pairs, and store the converted data in comma-separated variable file format.

See the followin g descriptions of t he program segments.

7-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_LENG TH]; /* 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 sc ope */ 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 value s.

7-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 i s reset to a known state and the * interface is cleared. System headers ar e tu r ned off to allow faster * throughput and immediate access to the dat a 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 s ta tus 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 de lay */ write_IO (":TIMebase:RE Fer ence 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:R A NG e 1.6;OFFSet -400e-3");

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

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

} /* end initialize ( ) */

7-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 re commended for acquisition of new * data when averaging is used. It will initialize data buf fers, acquire new data, and e nsur e that * acquisition criteria are met before acquisition of data is stop ped. The * captured data is then available for meas ur ements, 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 displ ay which is */

/* turned off by the :DIGitize command */

} /* end acquire_data ( ) */

7-8

init.c - Making Automatic Measurements

/* * Function name: auto_measurements * Parameters: none * Return value: none * Description: This routine perform s aut omatic measurements of volts * peak-to-peak and period on the acquired data. It also demonstrates * two methods of error detection when usin g aut omatic 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 indi cator. 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 indicator s. * * The second method simply requires that you check t he 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 transmi ssion 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_st r ,16L); /* read in value and result flag */ if (vpp_str[bytes_r ead-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 er ror with result %c\n",

7-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 measurement s and er r or checking with * :MEAS:RESULT S OF F */ 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 () */

7-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 indi cator. 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 indicator s.

* The second method simply requires that you check t he 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 fr om th e s cope. */

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 val ue 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 measurem ent er ror with result %c\n", period_str[bytes_read-2]) ; else

printf ("Period is %f\n" ,(float)atof (period_str)); /* * METHOD TWO - perform automated measurement s and er r or checking with * :MEAS:RESULT S OF F . */ 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 (perio d_st r,16L); /* read in value and result flag */

7-11

Sample Programs

init.c - Error Checking

period = (float) atof (period_st r) ; if ( period > 9.99e37 )

printf ("\nPeriod could not be measu re d .\n"); else printf ("\nThe period of channel 1 is %f seconds.\n", period );

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

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-pea k is %f volts.\n", vpp );

} /* end auto_measurements() */

7-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 :FO R Mat BY T E");

/* request values to allow interpretation of r aw data */

write_IO (":WAVeform:XINCrement?");

bytes_read = read_IO (xinc_st r ,32L);

xinc = atof (xinc_ s t r );

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_st r ,32L);

yinc = atof (yinc_ s t r );

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 */

7-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_st r ,( long)header_length); Acquired_length = atoi (header_st r); /* number of bytes */ bytes_read = read_IO (data,Acquired_length); /* input waveform data */

bytes_read = read_IO (&term,1 L); /* input termination char act er */

} /* 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 ). Th e 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.

7-14

Agilent 86100A Programming Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

Introduction

Interface Functions

Status Reporting

Message Communication and System Functions

Programming Conventions

Using Multiple Databases

Sample Programs