Measurement Computing Personal488 rev.3.0 For DOS & Windows 3.Xi - Manual (Page 108)

II. SOFTWARE GUIDES - 8. Driver488/DRV 8J. Spreadsheets
Personal488 User’s Manual, Rev. 3.0 II-93
Taking Readings
Once we have set the 195’s operating mode, we can take a reading:
{WRITELN ENTER 16}
{READLN Reading}
The ENTER command takes a bus address (with an optional secondary address) and configures that bus
device so that it is able to send data (addressed to talk). No data is actually transferred, however, until
the
READLN statement requests the result from Driver488/DRV at which time data is transferred to the
program into the cell Reading .
Once the result has been received, any Lotus 1-2-3 functions or statements can be used to modify or
interpret it. In this example, the result is in the form
NDCV+1.23456E-2 showing the range ( NDCV )
and the numeric value of the reading ( +1.23456E-2 ). The Lotus 1-2-3 @MID function can be used to
strip off the range characters and keep only the numeric part (the fifth character and beyond), and the
@VALUE function can be used to convert this string to a number:
{LET Voltage,@VALUE(@MID(Reading,4,11))}
All the power of Lotus 1-2-3 may be used to manipulate, print, store, and analyze the data read from
the IEEE 488 bus. For example, the following statements compute the average of ten readings from the
195:
{FOR Index,0,9,1,Sum1}
Sum1:
{WRITELN ENTER 16}
{READLN Reading}
{PUT Voltages,0,Index,@VALUE(@MID(Reading,4,11))}
{RETURN}
The FOR statement sets Index to each of the successive values from 0 to 9 , calling the Sum1 subroutine
for each value of Index . Sum1 takes a reading from the 195, converts it to a numeric value, and places
it into a row of the range Voltages . The ten readings in Voltages are finally averaged by a formula
in the cell named Average which can be seen in the example spreadsheet.
Interrupt Handling
The IEEE 488 bus is designed to be able to attend to asynchronous (unpredictable) events or
conditions. When such an event occurs, the bus device needing attention can assert the Service
Request (
SRQ ) line to signal that condition to the controller. Once the controller notices the SRQ , it can
interrogate the bus devices, using Parallel Poll ( PPOLL ) and/or Serial Poll ( SPOLL ) to determine the
source and cause of the SRQ , and take the appropriate action.
Parallel Poll is the fastest method of determining which device requires service. Parallel Poll is a very
short, simple IEEE 488 bus transaction that quickly returns the status from many devices. Each of the
eight IEEE 488 bus data bits can contain the Parallel Poll response from one or more devices. So, if
there are eight or fewer devices on the bus, then just the single Parallel Poll can determine which
requires service. Even if the bus is occupied by the full complement of 15 devices, then Parallel Poll
can narrow the possibilities down to a choice of at most two.
Unfortunately, the utility of Parallel Poll is limited when working with actual devices. Some have no
Parallel Poll response capability. Others must be configured in hardware, usually with switches or
jumpers, to set their Parallel Poll response. If Parallel Poll is not available, or several devices share the
same Parallel Poll response bit, then Serial Polling is still required to determine which device is
requesting service.
Serial Poll, though it is not as fast as Parallel Poll, does offer two major advantages: it returns
additional status information beyond the simple request/no-request for service, and it is implemented on
virtually all bus devices.
The SRQ line can be monitored in two ways: it can be periodically polled using the STATUS command,
or it can be used to cause an external interrupt when asserted.