Abstraction of register reads over GPIB bus

[IntheStix]

Can anyone tell me if the GPIB board abstracts any register read commands (for example, "STAT:OPER:COND?" which gets the standard operation status group register in many Agilent instruments)?  That is, do such commands get captured by the card, where the card knows that it merely has to read the voltage on several hard-wired lines on the GPIB bus to get the answer and as such does not "send" the command to the instrument and read back an answer?  This relates to a question posed by one of my colleagues - When a command is issued to an instrument, and then the program continuously reads a register (or queries *OPC, or whatever) to see if the instrument's done doing what it was told, does the act of continuously polling the instrument (or reading registers or what have you) actually cause the instrument to take longer to process the command?  It's like me assigning a task to someone and constantly asking, "Are you done yet?  Are you done yet?  Are you done yet?  Are you done yet?  How about now?  Are you done yet?"  ... ad nausean.  Sometime a few tens of milliseconds adds up.  Any info would be appreciated

Thanks!

[Dennis_Knutson]

The operation register is inside the instrument and the only way to get the data is by doing a read of the data lines after the command is sent. There are no dedicated lines on the GPIB bus other than the data, handshake(i.e. DAV), and interface management (i.e. SRQ). Whether doing a poll of the instrument will slow things down, that would be a function of the instrument's firmware but it has not been something that I have observed, though I've never really tried testing it. In many cases, what you do with the instrument is set it so that it issues an SRQ when the operation is complete. In this case, the software on the pc would keep checking the status of the dedicated SRQ line on the bus and this would have no affect on the measurement time.