IOtech Personal488, Руководство пользователя

Страница: 143 / 150

Personal488 for Windows 95/98/Me/NT/2000
03/16/01
Troubleshooting C-5
“When I ask for data, bad data is returned.”
Many times the variability of data formats of an instrument will cause problems. Devices can
transmit data in binary, ASCII, BCD, packed BCD, or anything else that will fit into 8 bits. Data
terminators can be EOI, a byte count, or imbedded characters like CR LF. Data can be sent with
prefixes, suffixes, or full headers. IOtech’s Driver488 can account for all of these parameters, but
some other drivers may not allow this level of flexibility.
When using higher level software packages, the problem of data formats may be impossible to
overcome. Usually, menu-driven and turnkey packages go to great lengths to hide the IEEE bus
from the operator. The documentation, therefore, makes no attempt to inform the operator of what
is actually happening on the bus.
You may encounter a problem if your instrument transmits data in a format that is not recognized
by your software package. Check your instrument manual for data format characteristics. Does
your instrument transmit non-numeric prefixes or suffixes; is the data in binary or ASCII? Some
software drivers will automatically throw away any non-numerics. Others do not. Even if your
software throws the non-numerics away, you may encounter problems with instruments that
transmit numbers like channel tags in their data prefix.
Most instruments, including IOtech’s ADC488 analog to digital data acquisition instrument, can
be programmed to adjust their data format for software compatibility. Analyzer488 allows you to
quickly inspect the data being transmitted by your instrument, enabling you to make the proper
adjustments in your software.
“An SRQ from an instrument sometimes causes a catastrophe.”
The asynchronous nature of instrument interrupts can sometimes cause elusive problems. The
best way to attack a problem like this is to start the Analyzer488 recording and just let it and the
system run. Analyzer488 has a large 32K transaction buffer that is configured in a circular
fashion. After 32K transactions have been recorded, new transactions will overwrite the oldest
transactions. There is a very high probability that the events leading up to the system “crash” will
still be in the recorded memory (not overwritten) after the system has locked-up. Stepping
backwards in memory can usually uncover the sequence of operations that caused the problem.
The Analyzer488 can also be set up to trigger on the occurrence of one or several SRQs with both
a post and pre-trigger assigned. In this way a specified number of events can be captured before
and after the occurrence of an SRQ. The Analyzer488 also has comprehensive search features
allowing the capture buffer to be scanned for all of the occurrences of any event, including an
SRQ.
Some instruments have the capability of generating an SRQ for any of several internal events.
Usually an SRQ mask is sent to the instrument to instruct it to generate an SRQ for only a
selected subset of those events. Some instruments, by default, will interrupt the controller with an
SRQ when an internal error is encountered and not respond to any further bus transactions until
the interrupt is serviced. The next time your application program requests data from that
instrument, your system will fail. By inspecting the Analyzer488 transaction recording working
backward from the end, it will be obvious that an SRQ was asserted by someone on the bus and
that it remained without service.