I would say you first assumption is probably correct, that the scope
has trouble handling the status query and data aquistion at the same
time. Is your timeout error generated by a GPIB read function or a
GPIB write function? If it is a read error, most likely the scope
must first handle the acquired data before it can respond to any
commands in the buffer. Have you tried simply increasing the timeout
value of the function generating the error (or if you're using VISA,
set the timeout with a property node)?
If a write command is generating the error, the scope is probably
asserting the NRFD (not ready for data) line on the GPIB bus. In this
instance, the write function will be instructed by the driver to halt
sending characters until the line is clear. You need to increase your
timeout value to give the write function more time to wait until the
line is clear.
I find the best way to avoid these situations is to take more direct
control of the instrument in question. It sounds as if the scope is
configured to "trigger" or "sweep" continuously, and you are just
saving the data if there is anything new. It may be better to trigger
the instrument to sweep from your program rather than letting it run
continuously. That way you have control over the sequence of events.
I use a few different brands of optical spectrum analyzers and they
all work better this way. First I issue the command to sweep (acquire
new data) then (depending on the model) I either wait in a loop while
polling the status byte to see if the sweep is done, or I issue the
*OPC? command, which causes the instrument to return a "1" byte when
the acquistion is complete. In the second method, I set the labview
timeout of the GPIB Read (the instance that reads the response of the
*OPC? command) to a value longer than the longest known sweep time for
the instrument. This insures the program will wait until the
instrument responds to the *OPC? command or until the timeout expires
(something went wrong). When using the first method of status
polling, it is sometimes necessary to wait a short period (a few
hundred milliseconds or so) to allow the instrument to update the
status byte with the "busy" status after acquisition has been started.
I found this to be true with Ando OSA's.
Finally, some instruments refuse to continue GPIB operation if the
commands you are sending are generating an error and the error message
buffer is full. This is pretty rare, but I have seen it. Check the
command for reading the error buffer and add it to your program
(:SYST:ERR? is common) to see if you are generating errors on each
iteration of the loop. Hope this helps.
gm
Prog Guy wrote in message news:<50650000000800000098610000-1031838699000@exchange.ni.com>...
> Here is the whole deal.
>
> I have LabVIEW set up to drive an O-Scope and a DMM. The DMM is set up
> so that a GPIB Read will get a sample of the voltage. The O-Scope is
> set to trigger and capture 4 channels of data. So much for hardware.
>
> The software is written in two "threads" in the same VI. The top one
> polls the O-Scope to see if it is running (waiting for a trigger) or
> has stopped (a trigger occurred.) If the scope has triggered, then the
> wave forms are sucked off the scope and written to disk. The bottom
> thread reads the next voltage from the DMM. When it gets 180 samples
> it writes the min and max to a log file.
>
> Intermittantly the O-Scope thread gets a timeout error. A retry
> corrects the issue and by looking at error logs and log file dates it
> seems that the failure always occurs right before a new set of
> waveforms is written to disk. (Within a second.)
>
> Two possibilities occur to me. The Code polls the O-Scope Right as it
> is capturing data and the query is lost or ignored. The other is that
> since both instruments are accessed asynchronously that somehow the
> query of the DMM sometimes screws up the query of the O-Scope.
>
> It could be something else.
>
> Any advice is appreciated.
>
> Thanks!
