What is Proper GPIB Communication Scheme?

[IEC]

Hey everyone... yet another question...

So I have a sub VI whose sole function is to acquire data from 2 SR830 lockin amplifiers.  I want it to run as fast as possible.  It sends a command to one lockin, gets the response (float), then sends a command to second lockin and gets a similar response.  It gets hung up a lot and I can seem to get it to run smoothly.

Is there a proper procedure for communicating with GPIB?  Ie - should I clear the bus between commands? should I monitor some sort of GPIB status?  I can use wait timers but then I don't know how fast it can truly run.... 

I'm looking for some sort of sequence that will ensure proper communication, like dev. clear, gpib write, gpib read, wait on rqs, etc... something like that

Oh, and what IS RQS?

Thanks

Jonathan

[johnsold]

Jonathon,

I don't know what is best, but the SR830 can operate in sevral modes, so maybe you should run some tests. A quick look at the manual did not show any data on how quickly the instrument responds to a query. It did, however, state that a 250 element command buffer exists. Perhaps you could write to write to unit 1, read from unit 2, write to unit 2, read from unit 1, ...

Lynn

[tbob]

RQS is Request for Service.  It is sort of like an interrupt on the GPIB bus.  If you look in the Instrument I/O - GPIB (488) palette, you will see lots of low level functions there.  Looking at the help window for each will give you an idea of what they are.  Typically, an instrument will accept a GPIB command and then set a status register bit to show it is busy fulfilling the command request.  When it is done, the bit is changed to show it is done.  There are other bits in the status register for errors and such.  Your device manual should explain what the status bits are.  Typically, you would send a command, then use a loop to check the status bit for Done or something like that.  Keep looping until the bit indicates that the device is done making its measurement or completing the command.  Then exit the loop.  At this point you can either read data on the bus or send another command.  If you want to run as fast as possible, you will have to use these register bits.  There are several low level vi's to read the register, poll for a bit, clear the registers, etc...

[IEC]

Awesome!  Thanks for the replies, both were helpful.  One related question...

Everytime I do a serial poll, do I need to reset the bits? serial poll is same thing as doing a bit check on the device's hardware registers right? 
Or is this dependant upon the specific device?

Oh and thanks to all the help from everyone in the forums, I've been able to build my first system ever (for my master's thesis)... it's a laser-beam-induced-current imaging device (used to characterize various types of solar cells), and runs with help from the super awesome ni vision package.  I'll make a post soon showing some pictures it created... it's pretty cool. These new string of questions I've been posting recently is related to improving the scan time and speed it up.

Jonathan

[tbob]

The registers are device dependant.  You should check the owners manual for polling bits, when to reset, etc.  For common name brand equipment (Agilent, Keithley, etc.) there is usually a section in the manual that explains all about GPIB communications, even example programs in Basic or C.