LabVIEW
GPIB problems
"partially compliant". Is that kind of like "slightly pregnant"? 
Seriously though, it is not at all uncommon for GPIB interfaces from that era to only be compliant with the standard to the extent that the connector was the right shape! This gets into an area that most young engineers have never had to address: How to interface with an instrument that does not play well with the other children on the bus.
First thing, make sure you are NOT using the VISA or 488.2 drivers, you want the original GPIB interface routines.
Next, I mostly remember errors that were related to the speed at which the instrument was accessed. Even with LV1 running on a 1MHz Mac Plus I can remember instruments that couldn't keep up with my code. When I ran into problems like this my first experiment would be to put something like a 500msec delays between every IO function. If this miraculously made the problem go away, I played with it further to find out which of the delays I really needed and then how long the delay really had to be. I remember crashing (!!) a Hewlett-Packard spectrum analyzer because I was polling it too fast...
If delays didn't work it's possible that the device isn't interacting with the bus properly. In those situations you get to really learn how the GPIB interface works because you have to use the GPIB Misc function to essentially bit-bang the interface. The GPIB spec will tell you what the command mean, and the documentation for the instrument will tell you what a bus cycle should look like for it.
And yes, this sort of work is a major pain, and yes it was not that unusual 15-20 years ago... you did it a lot... And that's only what it takes to get the device communicating on the bus. Once you get that working you get to find all the places where the command don't do what the documentation says they are supposed to.
Mike...
PS: Why do I suddenly have the overwhelming urge to use the word "whipper-snapper" right now? hmmmmm...
Seriously though, it is not at all uncommon for GPIB interfaces from that era to only be compliant with the standard to the extent that the connector was the right shape! This gets into an area that most young engineers have never had to address: How to interface with an instrument that does not play well with the other children on the bus.
First thing, make sure you are NOT using the VISA or 488.2 drivers, you want the original GPIB interface routines.
Next, I mostly remember errors that were related to the speed at which the instrument was accessed. Even with LV1 running on a 1MHz Mac Plus I can remember instruments that couldn't keep up with my code. When I ran into problems like this my first experiment would be to put something like a 500msec delays between every IO function. If this miraculously made the problem go away, I played with it further to find out which of the delays I really needed and then how long the delay really had to be. I remember crashing (!!) a Hewlett-Packard spectrum analyzer because I was polling it too fast...
If delays didn't work it's possible that the device isn't interacting with the bus properly. In those situations you get to really learn how the GPIB interface works because you have to use the GPIB Misc function to essentially bit-bang the interface. The GPIB spec will tell you what the command mean, and the documentation for the instrument will tell you what a bus cycle should look like for it.
And yes, this sort of work is a major pain, and yes it was not that unusual 15-20 years ago... you did it a lot... And that's only what it takes to get the device communicating on the bus. Once you get that working you get to find all the places where the command don't do what the documentation says they are supposed to.
Mike...
PS: Why do I suddenly have the overwhelming urge to use the word "whipper-snapper" right now? hmmmmm...
Message Edited by mikeporter on 05-18-2007 07:42 PM
