Instrument not recognized - computer too fast for AT-GPIB/TNT board

Question

I have a problem with a potentiostat (PAR 283) connected to ISA AT-GPIB/TNT (not pnp) board. I recently upgraded to a motherboard with 1.8GHz AMD processor. Potentiostat is recognized by other software as "28PD", "28PE" or sometimes just some garbage characters, instead of "283". I'm using driver version 1.6 (1.7 could not recognize the board). In "Measurement&Automation" potentiostat doesn't respond to *IDN? query (error EAB0). FRA analyzer connected to the same board is recognized without a problem. None of the Windows programs can control potentiostat (it's not recognized as "283). One DOS program, however, is able to recognize and control the potentiostat. I tested the whole system with 166MHz compu
ter, and everything worked fine.
My operating system is Win98
Does anyone have idea what could solve the problem?
Thanks
Darko

Answer 1

I don't necessarily have an answer to your problem, but I want to assure you those usually these problems are with the instrument. The IEEE 488.1 standard defines a 3-wire interlocked handshake to prevent any problems due to computer/device speeds.
However, some devices violate this protocol. They rely on internal timing to determine when things should occur on the bus. For example, the talker asserts the DAV hardware line to indicate that data is valid on the bus. Following that, the listener is supposed to latch the data from the bus and then assert NDAC to indicate that it has taken the data from the bus. At the moment that NDAC has been asserted, the talker is allowed to modify the data lines since they have already been latched. However, some devices have noted in the past that their is usually X amount of time that passes from when NDAC is asserted until the data is removed from the wire. In order to improve peformance, they actually assert NDAC sometime before the data has been latched, assuming that the data will be there when they are actually ready to receive this data. In the case of moving to a faster computer, this data is actually staying on the bus for a shorter period of time than expected and the device receives garbage data.
A similar phenomenon can occur when the device is the talker where is violates the proper 3-wire handshake.
Note that not all failures are intential on the side of the device, it could be a legitimate bug.
Now that I have given a somewhat long-winded description of how problems like this can manifest, I can give you a few recommendations.
1) Obtain a GPIB bus analyzer and examine the handshake sequence to determine where the failure is.
2) Talk to the equipment manufacturer to see if they have any updates
3) Modify the bus timing in NI-488.2 from 500ns to 2ms. This is not likely to work since you are on the receiving end.
4) Try to procure a GPIB-PCII/IIA board. This is a slower board that overall responds to handshaking slower than the AT-GPIB/TNT board and may mask the problem.
5) Increase your cable length (including to "illegal" lengths such as 8m). This can add propegation delays that can mask this problem. I have seen work in teh past with troubled instruments.
Good luck.