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

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

C-6 Troubleshooting
03/16/01
Personal488 for Windows 95/98/Me/NT/2000
“My system occasionally locks up.”
This is another of those intermittent problems that can take a long time to troubleshoot, especially
if the mean time between failures is several hours, days or months. As before, the best way to
approach the problem is to allow the Analyzer488 to record all of the transactions occurring on
the bus. When the number of transactions goes beyond 32,767, the capture pointer will wrap
around and continue to record. The last 32,767 transactions will always be stored in memory.
When the system crashes, the processing of IEEE bus transactions will probably end also. With
the last 32K transactions captured in memory, it is easy to step back through the capture buffer
and decipher the sequence of operations that caused the crash.
One possible cause for an intermittent crash problem is the asynchronous occurrence of SRQs as
discussed above. There may be areas in your application program that do not react well to being
interrupted. Since the SRQ can happen at any time, it may or may not occur during the processing
of this sensitive area. But the longer the system runs, the probability that the SRQ will happen at
exactly the wrong time increases. A sensitive area may be a part of your code that uses a group of
closely related variables that are modified by the SRQ handler. For example, three IEEE 488
counters are used to take readings from three motion encoders. Each counter is programmed to
generate an SRQ when its count reaches 256. The SRQ handler reads all three counters and stores
them into three separate variables used later by the main program. The main program has a loop
that reads the three variables, combines them with some calculation, and sends commands to a
motor controller. If the main program was in the process of using the variables and an SRQ
occurred (which modifies all three variables), the main program may end up using one old value
and two new ones in its calculation.
One way to avoid this kind of problem is to disarm the automatic SRQ vectoring during the
processing of sensitive program areas. IOtech’s Driver488 has several means by which to arm,
disarm and synchronize the servicing of SRQs to your program.
Another source of system malfunctions is from the instruments themselves. Most of today’s
complex instruments are microprocessor controlled. The internal processor handles the collection
of data, the changing of programmable states, the monitoring of trigger events, and the
communication on the IEEE interface. These instruments are actually computers, prone to all of
the same problems as any other computer.
It is possible that your instrument reacts improperly to a perfectly good application program. The
transaction report that Analyzer488 prints out can be used to communicate instrument problems
to the manufacturer. The report is easy to read and concisely describes the operation of the
controller and the response of the instrument.
New Standards Simplify Programming
Many of the difficulties encountered during the development of IEEE software are due to the
non-standard elements of operating the IEEE bus. Terminators, common command syntax, and
SRQ handling, among others, were not standardized within IEEE 488.1 and were left to the
instrument and controller designers to deal with.
New standards and extensions to older standards are now becoming available that may
significantly simplify IEEE system integration. Although supported by only a few instruments
presently, standards like IEEE 488.2 and SCPI (Standard Commands for Programmable
Instruments) are changing the way instruments are controlled.
The IEEE 488.2 standard is, for the most part, an extension to the present standard, IEEE 488.1.
There are only a few hardware differences between the new and old standards, assuring that older
instruments conforming to IEEE 488.1 can still be used alongside newer IEEE 488.2 instruments.
The major difference between the two standards lies in the software protocol. Previously non-
standard elements of bus communication such as terminators and data types have now been
included in the standard. These standards will eliminate some of the variables encountered when
integrating instrumentation systems, making debugging simpler.