Options
and
Accessories-2230 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.
1.
Initialize the controller
in
the communi-
cations mode.
2.
Watch for a service request.
3.
Check the event code (by sending
an
EVEnt?
query) if a service request occurs.
4.
Determine the action needed to
be
taken from
the event code byte that
is
returned
and
take it.
5.
Get a command to
send
to the oscilloscope.
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.
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 (if
ROS
is
ON).
Other status bytes return
as
the
7-16
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.
1.
Watch for
an
asynchronous service-request status
byte. This
is
the same concept
as
checking for
an
SRQ
with the
GPIB
controller program.
2.
Send
an
EVEnt? query to obtain the event-code byte
that describes
in
more depth what caused the service
request.
3.
If the response to the EVEnt? query
is
not zero, per-
form the action required to handle the event.
4.
Return to the
main
program.
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.
--
To Next Page
Loading...
