Tektronix 2230

--
Option 10 Status and Error Reporting
The status and error reporting system of Option 10
interrupts the GPIB bus controller by asserting an SRO
(service request). The service request indicates that an
event has occurred that requires attention. When the con-
troller polls the bus, the status-byte returned by the oscil-
loscope indicates the type of event that occurred. A further
EVEnt? query will return an event code that gives more
specific information about the cause of the service
request. The SRO status byte and the event code provide
a limited amount of information about the specific cause of
the service request. Command errors, execution errors,
and internal errors assert an immediate SRO (if ROS is
on). To retrieve other system event and warning status
bytes, OPC must also be ON, and the oscilloscope must
be queried by the STAtus? command. See Tables 7-34
and 7-35 at the back of this section for status and event
codes.
GPIB Programming
Programming considerations are provided in this part to
assist in developing your own unique programs for inter-
facing to the oscilloscope via the GPIB.
Before a program can be used for controlling the oscil-
loscope, the GPIB parameters (primary address, message
terminator, and talk/listen mode) must be set. Procedures
describing how these parameters are selected and set at
the oscilloscope were given previously in this section of
the manual.
Programs are usually composed of two main parts (or
routines), which can be generally categorized as a com-
mand handler and a service-request handler.
COMMAND HANDLER-Basically, a command handler
should establish communication between the controller
and oscilloscope, send commands and queries to the
oscilloscope, receive responses from the oscilloscope,
and display responses as required. The following out-
line indicates the general sequence of functions that
the command-handling routine should perform to
accommodate communications between the controller
and oscilloscope over the GPIB.
1. Initialize the controller.
2. Disable the service-request handler until the pro-
gram is ready to handle them.
3. Get the GPIB address of the oscilloscope.
Options and Accessories-2230 Operators
4. Enable the service-request handler.
5. Get the command to send to the oscilloscope.
6. Send the command to the oscilloscope.
7. Check for a response from the oscilloscope.
8. If there is a response, perform the
desired function.
9. You are ready for a new command. Repeat the
functions in statements 5 through 9 as many
times as desired.
SERVICE-REQUEST HANDLER- Typical service-
request handler routine contains the necessary
instructions to permit proper processing of interrupts.
For example, whenever power-on occurs, the oscillo-
scope asserts an SRO interrupt. If a GPIB program is
operating on the controller when a power-on SRO is
received, the program should be able to determine that
the oscilloscope's power was interrupted at some time
during program operation. This event could cause
improper program execution, unless the program was
written to adequately handle the possibility of a
power-on SRO occurring.
Other interrupts (or events) for which the oscilloscope
asserts SRO are identified in Table 7-14.
While some controllers have the capability of ignoring
service requests, others require that all SROs be
managed. The programmer should understand the con-
troller being used. If service requests are to be handled in
the program, the interrupts must first be enabled.
A service-request handler routine can be developed to
service interrupts when they occur during program opera-
tion. It basically should consist of an interrupt-enabling
statement (ON SRO) near the beginning of the program
and a serial-poll subroutine somewhere in the program.
The ON SRO statement directs program control to the
serial-poll subroutine whenever an SRO interrupt occurs.
For each interrupt received by the controller, the program
should perform a serial-poll subroutine.
The following general steps are required to handle ser-
vice requests from the oscilloscope:
7-9