Remote Commands
Checking Product Status 6
6-79
Read the ISR, ISCR, or ISCE
To read the contents of the ISR, send the remote command, "ISR?." To read the
contents of the ISCR0 or 1, send the remote command, "ISCR0?", or "ISCR1?".
To read the contents of the ISCE0 or 1, send the remote command, "ISCE0?", or
"ISCE1?". The Product responds by sending a decimal number that represents
bits 0 through 15. Each time you read the ISCR0 or 1, its contents are zeroed.
By setting the bits in an ISCE register, the associated bits in the ISCR can be
masked (disabled). For example, to cause an SRQ interrupt when the input
frequency goes over range, bit 10 (MDCHG) in the ISCE1 register must be 1.
(The ISCB bit must also be enabled in the SRE.)
Output Queue
The output queue is loaded whenever a query is processed, and holds up to 128
characters. If the queue is empty, the Product does not respond to the query
statement from the controller. The Message Available (MAV) bit in the Status
Byte Register is 1 if there is something in the output queue and 0 if the output
queue is empty.
Error Queue
When a command error, execution error, or device-dependent error occurs, its
error code is placed in the error queue where it can be read by the ERR?
command. All error codes are defined in Appendix A of this manual. Another way
to decode a error code is to send the command, EXPLAIN?, which returns a
description of a error code. Reading the first error with the ERR? Command
removes that error from the queue. A response of "0" means the error queue is
empty. The Error Available (EAV) bit in the Status Byte Register indicates
whether the queue is empty. The error queue is cleared when you turn off the
power, and when you use the *CLS (Clear Status) common command.
The error queue contains up to 16 entries. If many errors occur, only the first 15
errors are kept in the queue. A 16th entry in the queue is always an "error queue
overflow" error, and all later errors are discarded until the queue is at least
partially read. The first errors are kept, because if many errors occur before the
user can acknowledge and read them, the earliest errors are the most likely to
point to the problem. The later errors are usually repetitions or consequences of
the original problem.