Tektronix 2221 - Page 92

Options and Accessories -- 2221 Operators
COMMAND HANDLER - Basically , a command handler
establishes communication between the controller and the
oscilloscope
,
sends
commands
to the
oscilloscope
,
receives responses from the oscilloscope , and displays the
responses as required . The steps of the following
procedure are the general functions that the command
handler software routine should be able to do for the most
useful
communications
.
result of a STAtus ? query , or when OPC is on . The
immediate mode service request may cause the controller
to halt unless the controller's program is written to
properly handle them . A user may also want the controller
routine to be able to recognize and handle the other
events requiring service . These events are identified in
Tables 7-34 and 7-35 at the back of this section .
The following general steps are required to handle ser
vice requests from the oscilloscope .
controller
in
the
communi
1.
Initialize the
cations
mode
.
2.
Watch
for a
service
request
.
1. Watch for an asynchronous service - request status
byte . This is the same concept as checking for an SRQ
with
the
GPIB
controller
program .
3. Check the event code ( by sending an EVEnt ?
query ) if a service request occurs .
2. Send an EVEnt ? query to obtain the event - code byte
that describes in more depth what caused the service
request .
4. Determine the action needed to be taken from
the event code byte that is returned and take it .
3. If the response to the EVEnt ? query is not zero , per
form the action required to handle the event .
5. Get
a
command to
send to the
oscilloscope
.
4.
Return
to
the
main
program
.
6.
Send a
command to
the
oscilloscope .
7.
Check for a
response from the
oscilloscope .
8. If the response is an error status , check the
event
code ( Step 3 )
and take
the
appropriate
action (
Step
4
) .
9. Repeat Steps 5 through 8 as many times as
needed
.
Option 12
Status and Error
Reporting
The status and error reporting system used by the
Communication
Option sends status
bytes that
may be
viewed as a service request when monitored by the
appropriate controller software . As soon as a change of
status or an error occurs , the 2200 Family instrument
returns a service request status byte that indicates the
type of event that occurred ( if RSQ is on ) . The status byte
returned and the event code returned as the reply to an
EVEnt ? query provide a limited amount of information
about the specific cause of the service - request status
byte . Command errors , execution errors , and internal
errors generate a service - request status byte immediately
( if RQS is ON ) . To retrieve other system - event and warn
ing status bytes , OPC must 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
-
byte
and event
codes .
SERVICE
REQUEST
HANDLER
—
The
service
-
request
handler
routine should
contain
the
necessary
instructions
to process the possible event codes generated by the
2200
Family
DSO
. The
2200
Family
DSO requests
service
by sending asynchronous status bytes when certain errors
occur ( it
RQS is ON ) .
Other status
bytes return
as the
7-16