Filter
Top Products
50 Remote Programming
Types of SCPI Commands
SCPI has two types of commands, common and subsystem.
■ Common commands (see table 7-1) generally are not related to specific operation but to controlling overall Agilent
SAS functions, such as reset, status, and synchronization. All common commands consist of a three-letter mnemonic
preceded by an asterisk: *RST *IDN? *SRE 8
■ Subsystem commands (see table 7-2) perform specific Agilent SAS functions. They are organized into an inverted tree
structure with the "root" at the top. The following figure shows a portion of a subsystem command tree, from which
you access the commands located along the various paths.
Figure 6-1 shows a portion of the subsystem command tree (you can see the complete tree in table 7-2). Note the location
of the ROOT node at the top of the tree. The SCPI interface is at this location when:
■ The Agilent SAS is powered on.
■ A device clear (DCL) is sent to the Agilent SAS.
■ The interface encounters a message terminator.
■ The interface encounters a root specifier.
Figure 6-1. Partial Command Tree
Multiple Commands in a Message
Multiple SCPI commands can be combined and sent as a single message with one message terminator. There are two
important considerations when sending several commands within a single message:
■ Use a semicolon to separate commands within a message.
■ There is an implied header path that affects how commands are interpreted by the Agilent SAS.
The header path can be thought of as a string that gets inserted before each command within a message. For the first
command in a message, the header path is a null string. For each subsequent command the header path is defined as the
characters that make up the headers of the previous command in the message up to and including the last colon separator.
An example of a message with two commands is:
CURR:LEV 3;PROT:STAT OFF
which shows the use of the semicolon separating the two commands, and also illustrates the header path concept. Note that
with the second command, the leading header "CURR" was omitted because after the "CURR:LEV 3" command, the header
path was became defined as "CURR" and thus the instrument interpreted the second command as:
CURR:PROT:STAT OFF
In fact, it would have been syntactically incorrect to include the "CURR" explicitly in the second command, since the result
after combining it with the header path would be:
CURR:CURR:PROT:STAT OFF
which is incorrect.