You just hit one of my favorite hot topics! Remember that a GPIB bus has parallel handshaking. The *OPC? will return under 2 conditions: a) the maximum timeout expired and b) The GPIB controller observed that the a Service Request was initiated by the specific address on the bus.
The controller conducts polls sequentially from address 1 to 30 and stops at the first address that is asserting SRQ. Therefore, if any other lower address is asserting SRQ it will mask your o'scope's service request untill it has been serviced (if no other loop is looking for this SRQ at the lower address you will timeout regardless off the O'scope function). This can burn you pretty hard during debug because you forget to look at the other bus children.
I always try to avoid dependance on SRQ and you can almost always code around it. One method that works well for TEK O'scopes is:
1: Read tmo (VISA property node>Timeout value)
2:set tmo to a low value (500mS) (VISA property node>Timeout value = 500 )
3: Read number of acquisitions from the O'scope
4: Trigger the scope
5: Enter a loop that reads number of acquisitions from the O'scope (exit when it increments or number of iterations is insane)
6: get your reading
7: SET the tmo back to its original reading ( Remember this isn't the only VI that uses tmo if you don't set it back you may get unexpected results in another O'scope vi.
Your LabVIEW gurus will tell you this is poor practice for code effecientcy (and it is). But it is the most effective for avoiding re-writing your drivers when you hang non-complient devices on your GPIB bus (or change addressing)
enjoy!
"Should be" isn't "Is" -Jay
