All Agilent Technologies VXI instruments created in the last couple of years conform to SCPI (Standard Commands for programmable instruments). The SCPI language includes all of IEEE 488.2 which previous to SCPI was the most extensive set of programming conventions.

The manufacturers of SCPI instruments all claim that the users of these instruments will experience productivity gains because they all program in a similar manner. I have found this to be true, especially when it comes to debugging programs that control these instruments.

The ten steps outlined below do not depend on any particular programming language, however all of the examples are given in HP BASIC since this language has been optimized for I/O programming tasks.

When a SCPI program doesn't seem to be producing the desired results, then follow this ten step process. Steps 1 thru 4 will help you find 80% of the errors that occur. Steps 5 thru 10 will help you find the remaining 20% of the errors, which tend to be harder to track down.

1. Verify that you can communicate with each instrument
2. Start your program by fully resetting each instrument
3. Query the instrument for errors
4. Query all command parameter settings, that you have set
5. Check that your program is trying to enter the same amount of data that the instrument is trying to output
6. Check the instruments Arm-Trigger subsystem
7. Check that coupled commands are sent as a group
8. Check for Command synchronization problems
9. Re-read the manual to fully understand the commands
10. Find a expert

The first problem that is faced is to verify that you have discovered the correct address and the method of sending commands and receiving responses thru your computer.

Agilent VXI systems that have a command module, have a system instrument that is always located at secondary address 00. Its primary address is defaulted to be 09. This instrument can be used to discover the other instruments in the system.

The VXI-5 document specifies a standard set of commands to access VXI system information. These commands follow the conventions used in SCPI and IEEE 488.2. Use the command VXI:CONF:LADD? to return a list of all Logical Addresses set in the system. This is important because the logical addresses are usually set by switches, and this allows you to verify that the system sees the switch settings as you intended. A common mistake is to interpret the Msb for the Lsb or a 1 for a 0.

These logical addresses divided by eight are the secondary addresses of the remaining instruments in the system.

To find additional information about the instrument at a logical address do the following query.

All command sequences must end with a proper terminator called a program message terminator which may be a Line Feed, Line Feed with EOI, or EOI. Most programming systems provide some method of specifying the terminator. HP BASIC automatically provides a Line Feed at the end of all OUTPUT statements.

Data returned from the instrument will always terminate with a Line Feed and EOI. HP BASIC ENTER statements will terminate with this. IEEE 488.2 specifies that all instruments will respond to the *IDN? command with a response string that identifies the instrument. Use this to verify that you can communicate with each instrument.

2) Start your program by fully resetting each instrument

An instrument is fully reset when you cycle the power to it, or go through the three levels of reset hierarchy. It is important to go thru all levels in the proper order because some instruments can get to states that can only be aborted by this sequence

1. Issue a IEEE 488 Interface clear which will unhang any hung bus handshaking. i.e. ABORT 7
2. Issue a IEEE 488 selected device clear which will terminate instrument activity and clear input/output buffers i.e. CLEAR 70900
3. Reset all features of each instrument and wait for it to complete. i.e. OUTPUT @Sys;"*RST;*CLS;*ESE 0;*RSE 0;*OPC?" ENTER @SYS;A

The *RST resets the instrument specific functions. The *ClS;*ESE 0;*SRE 0 resets the instruments status subsytem that is defined by IEEE 488.2.

The *OPC? command outputs a 1 when all commands in front of it have completed. See also step 8) Check for synchronization problems

3) Query the instrument for errors

SCPI defines that all instruments will have a error queue. Any time a error occurs, a message is placed into this queue. This error queue is read by sending the command SYST:ERR?.

Knowing that the error queue exists and frequently reading it is one of the most important things to know. Perhaps the single most common problem is to send a command string that has some syntax problem in it. When the command is parsed and the error is detected a message is written to the error queue, however, no other action is taken as instruments do not guess at what the command was supposed to be. No other indication of a error is usually seen, thus reading the error queue is so very important.

4) Query all command parameter settings, that you have set

When the error queue has a error in it, then the problem is to discover which command caused it. Since most commands set parameters and when a command has a error, it is not executed, a very effective debugging technique is to query previously sent commands for their current setting. When a queried setting doesn't match what you intended it to be, you have just located the problem.

SCPI commands have levels much like a computer path name. The levels are separated by colons. Each level will have one correct long spelling and one correct abbreviation. Upper or lower case may be used when these commands are sent to a instrument, however, the documentation specifies the abbreviation in upper case, with the lower case concatenated on to form the long form. If the command has parameters their will then be a space followed by the parameters. If their is more than one parameter, then they will be separated by commas. The query form of a command will end in a question mark.

1. Command spelling
2. Missing the space between command and parameters
3. Parameters out of range
4. Setting Conflict caused by coupled commands not sent as a group -- see 7) Check that coupled commands are sent as a group

5) Check that your program is trying to enter the same amount of data that the instrument is trying to output

A common error is to not receive from the instrument the exact amount of data expected. Check the parameters as in 4) and then compare this with the number of data items that you have programmed to receive. See also 6). Pay special attention as to whether arrays start with zero or one. When one query command returns multiple results they will be separated by commas.

All SCPI instruments follow a Arm-Trigger model that is described in the SCPI document. This model has required and optional levels.

The Arm-Trigger subsystem starts with the IDLE state which occurs after a power on, :ABORT, *RST, or a previous Arm-Trigger cycle that has completed.

When in the IDLE state each of the lower levels is configured for their parameters. A few examples are:

After all of the layers are configured then the INIT command is given which moves the system to the INITIATED state. This is what enables all of the lower layers to start their activity.

Since each instrument may implement a differing number of layers, the instrument manual should be consulted. Look for a Trigger diagram and then look at the commands, that it references. Following are a couple of examples.

Program a Function Generator to output 100 cycles of a wave form whenever a signal is applied to it's Aux In port

7) Check that coupled commands are sent as a group

Coupled commands are commands that have combinations of parameters that are not allowed. In order to transition from one valid set of parameters to another valid set, all of the commands must be sent with semicolons (program message separator) between each command and then after the last command is sent a Line Feed, Line Feed with EOI, or a EOI (program message terminator) is sent. If the error message from 4) is "Settings Conflict" then you probably have a coupled commands problem. The instrument manual should indicate which commands are coupled, although the reader frequently misses this.

Here are two methods of sending coupled commands.

8) Check for Command synchronization problems

IEEE 488.2 specifies that all instruments will have a input buffer and that execution of these commands doesn't start until a program message terminator is received i.e. Line Feed, Line Feed with EOI, or EOI.

The common problem is that the computer will send commands to the input buffers of two instruments, and then its possible that the second instrument may actually execute its commands before the first instrument has. Thus instruments may execute there functions in a order that is different from the command sequence in the computer program.

Synchronization of instrument to computer is accomplished by sending a command which will return data. The computer then waits for the data to be returned. A special command defined by IEEE 488.2 was created to do this task. The Command *OPC? will return a one when all of the commands in front of it have finished executing.

Here is a example of closing four relays, waiting for them to complete, and then reading a voltmeter

9) Re-read the manual to fully understand the commands

The instrument manual is always the best place to go to understand instrument specific commands. Look for examples that are close to your desired tasks, then read the command reference to understand the commands that the manual uses.

Some manuals focus mostly on the instrument specific commands and do not fully document the Common Commands that IEEE 488.2 specifies. IEEE488.2 common commans all start with a "*". i.e. *OPC? The easiest to read source on these common commands is "Tutorial Description of the Agilent Technologies Interface Bus."

10) Find a expert

If the above tips do not solve your problem, then you should conclude that you have a unique, and possibly hard problem. You should seek out co-workers who have done similar problems, or contact a field or factory support person for help on the instrument that you are using.

As a productivity aid many of the above steps have been coded into IBASIC which is a controller language available in the Agilent VXI command modules. See AES189--Debugging, ERROR & TIMEOUT handling shell