Why do some older instruments require waits between writes?

[David_Grucza]

This is something that I have wondered about. Often when using older instruments with newer computers it is necessary to slow down the writing of instrument specific commands (ie set freq, get number of points). Writing two commands too closely in time causes the test instrument to lock up or to generate errors. If the instrument meets the GPIB spec, this really should not happen. It should stop handshaking if it is not ready to receive data (such as commands). The argument that I've heard that computers have gotten much faster should not make sense since even a newer computer still writes through a GPIB interface, and the test instrument should be able to react quickly enough to meet the spec. I find it h
ard to believe that so many instrument did not really meet the spec, but were built to respond as quickly as computers at the time could issue data. Thanks for any help in resolving this mystery. If I can understand what is going on, perhaps I can stop peppering my programs with waits.

[srm@viewpointusa.com]

Indeed the older instruments may not have been fully compliant. The response time of the micros in these instruments running @ 4 Mhz is just not good enough to respond to (or even change bus states) back to back commands from a 3 GHz processor. They may also have depended upon one of the other forms of handshaking requiring you to test for device ready before communicating again. The developer tester of the time would not have encountered a problem depending on the test methodology. Even today, a rush to market will leave untested and non-compliant corners of device interaction. Nothing to do except hope that you are working with a company that is responsive to your needs. My opinion.

[Brian_Powell]

You wrote, "I find it hard to believe that so many instrument did not really meet the spec...".

I think you ascribe too much computing intelligence to these instruments. Many of these devices run a simple "homemade" operating system, or better, a commercial single-threaded embedded operating system.

I'd bet most devices have a single microcontroller that is monitoring I/O, command processing, front panel processing, and taking the measurements. And the code to handle all that wants to handle just one thing at a time. For example, if an instrument is taking a measurement, and you're sending it the next command, a lot of instruments abort the measurement because it thinks you have something new and important to say.

Part of the beauty of virtual instru
mentation is that you have a real operating system at your disposal, and a lot of different things can be going on in the computer at the same time without interference.

Brian