The block diagram below shows how GPIB bus commands are serviced in the instrument. The instrument model consists of the following components:
The individual components work independently and simultaneously. They communicate with each other by means of so-called "messages".
The input unit receives commands character by character from the controller and collects them in the input buffer. The input unit sends a message to the command recognition as soon as the input buffer is full or as soon as it receives a delimiter, <PROGRAM MESSAGE TERMINATOR>, as defined in IEEE 488.2, or the interface message DCL.
If the input buffer is full, the message data traffic is stopped and the data received up to then is processed. Subsequently the traffic is continued. If, however, the buffer is not yet full when receiving the delimiter, the input unit can already receive the next command during command recognition and execution. The receipt of a DCL clears the input buffer and immediately initiates a message to the command recognition.
The command recognition stage analyzes the data received from the input unit. It proceeds in the order in which it receives the data. Only a DCL is serviced with priority, e.g. a GET (Group Execute Trigger) is only executed after the commands received before. Each recognized command is immediately transferred to the data set but not executed immediately.
The command recognition detects syntax errors in the commands and transfers them to the status reporting system. The rest of a command line after a syntax error is still executed, if possible. After the syntax check, the range of the numerical parameters is checked, if required.
If the command recognition detects a delimiter or a DCL, it also requests the data set to perform the necessary instrument hardware settings. Subsequently it is immediately prepared to process further commands. This means that new commands can already be serviced while the hardware is still being set ("overlapping execution").
The expression "instrument hardware" denotes the part of the instrument fulfilling the actual instrument function – signal generation, measurement etc. The controller is not included. The data base manages all the parameters and associated settings required for the instrument hardware.
Setting commands lead to an alteration in the data set. The data set management enters the new values (e.g. frequency) into the data set, however, it only passes them on to the hardware when requested by the command recognition. This can only occur at the end of a command line, therefore the order of the setting commands in the command line is not relevant.
The commands are only checked for their compatibility among each other and with the instrument hardware immediately before they are transmitted to the instrument hardware. If the instrument detects that execution is not possible, an "execution error" is signalled to the status reporting system. All alterations of the data set are cancelled, the instrument hardware is not reset. Due to the delayed checking and hardware setting, however, impermissible instrument states can be set for a short period of time within one command line without this leading to an error message (example: simultaneous activation of a frequency and a power sweep). At the end of the command line, however, a permissible instrument state must have been reached again.
Before passing on the data to the hardware, the settling bit in the STATus:OPERation register is set (cf. section STATus:OPERation Register). The hardware executes the settings and resets the bit again as soon as the new state has settled. This fact can be used to synchronize command servicing.
Queries induce the data set management to send the desired data to the output unit.
The status reporting system collects information on the instrument state and makes it available to the output unit on request. The exact structure and function are described in section Status Reporting System.
The output unit collects the information requested by the controller, which it receives from the data set management. It processes it according to the SCPI rules and makes it available in the output buffer. If the information requested is longer, it is made available "in portions" without this being recognized by the controller.
If the instrument is addressed as a talker without the output buffer containing data or awaiting data from the data set management, the output unit sends the error message "Query UNTERMINATED" to the status reporting system. No data is sent on the GPIB bus or via the Ethernet, the controller waits until it has reached its time limit. This behavior is specified by SCPI.
IEEE 488.2 defines a distinction between overlapped and sequential commands:
A sequential command is one which finishes executing before the next command starts executing. Commands that are processed quickly are usually implemented as sequential commands.
An overlapping command is one which does not automatically finish executing before the next command starts executing. Usually, overlapping commands take longer to process and allow the program to do other tasks while being executed. If overlapping commands do have to be executed in a defined order, e.g. in order to avoid wrong measurement results, they must be serviced sequentially. This is called synchronization between the controller and the analyzer.
According to section Data Set and Instrument Hardware, setting commands within one command line, even though they may be implemented as sequential commands, are not necessarily serviced in the order in which they have been received. In order to make sure that commands are actually carried out in a certain order, each command must be sent in a separate command line. Examples:
Example 1: Commands and queries in one message
The response to a query combined in a program message with commands that affect the queried value is not predictable. Sending
:FREQ:STAR 1GHZ;SPAN 100
:FREQ:STAR?
always returns 1000000000 (1 GHz). When:
:FREQ:STAR 1GHz;STAR?;SPAN 1000000
is sent, however, the result is not specified by SCPI. The result could be the value of STARt before the command was sent since the instrument might defer executing the individual commands until a program message terminator is received. The result could also be 1 GHz if the instrument executes commands as they are received.
As a general rule, send commands and queries in different program messages.
Example 2: Overlapping command with *OPC
The analyzer implements INITiate[:IMMediate] as an overlapped command. Assuming that INITiate[:IMMediate] takes longer to execute than *OPC, sending the command sequence
INIT; *OPC.
results in initiating a sweep and, after some time, setting the OPC bit in the ESR. Sending the commands:
INIT; *OPC; *CLS
still initiates a sweep. Since the operation is still pending when the analyzer executes *CLS, forcing it into the Operation Complete Command Idle State (OCIS), *OPC is effectively skipped. The OPC bit is not set until the analyzer executes another *OPC command.
The analyzer provides only one overlapped command, INITiate<Ch>[:IMMediate].
What is said below is not relevant for the other (sequential) SCPI commands.
Preventing
overlapping execution
To prevent an overlapping execution of commands, one of the commands *OPC, *OPC? or *WAI can be used. For a programming example refer to section Command Synchronizationin Chapter Programming Examples.
|
Command |
Action after the hardware has settled |
Programming the controller |
|
*WAI |
Stops further command processing
until all commands sent before *WAI have been executed |
Send *WAI directly after the command which should be terminated before the next command is executed. |
|
*OPC? |
Stops command processing until 1 is returned, i.e. until the Operation Complete bit has been set in the ESR. This bit indicates that the previous commands have been completed. |
Send *OPC? directly after the command which should be terminated before the next command is executed. |
|
*OPC |
Sets the operation complete bit in the ESR after all previous commands have been executed. |
–
Set bit 0 in the ESE |
