03-26-2015 11:30 AM - edited 03-26-2015 11:31 AM
Hello all,
Disclaimer: I am relatively new to LabVIEW so it's very possible that there's something easy and obvious that I am missing. That said, I thank you in advance for your help.
I am writing a data acquisition program for an experimental setup featuring multiple instruments from which I need to record data asynchronously over a GPIB connection.
My plan, I thought, was pretty straightforward: I wish to use the GPIB I/O functions to wait for an instrument to interrupt the controller, serial poll to find out which instrument has data ready, read, then repeat.
For the moment, I am testing my program with an HP 3478A DMM.
My problem is this: I noticed using NI I/O Trace that my program gets hung up for more than ten seconds whenever it needs to read an instrument output. However, I know I have read from this instrument at far greater speeds. I built a quick test VI, and noticed that if I simply read from the instrument without checking for SRQ or Data Ready then GPIB Read operates quickly (0.2 s/measurement). However, if I insert an SPOLL before the Read (not doing anything with it, just calling the function) then it hangs for around 17 seconds before continuing.
I have attached my simple test VI, an image of it, as well as screen-shots of the I/O Trace outputs for when the SPOLL is enabled vs disabled.
Again, I am pretty new to LabVIEW; it may be that this is some simple error, or that it's something specific to the 3478A, or our GPIB set up.
Thank you again for your help!
03-26-2015 02:41 PM
03-26-2015 04:14 PM
Hi Mike,
Thanks for replying.
To clarify, the serial poll call itself executed in around 2 ms. In my actual program I use the status byte to determine whether an instrument has data ready.
It was the subsequent call to GPIB Read which took a long time depending on whether I serial polled before it.
I appreciate the suggestion though, I will check it again with a different instrument.
03-26-2015 05:01 PM
03-27-2015 03:02 PM
Haha I'll keep that in mind.
Strangely, the error seems to have fixed itself overnight. I cannot begin to guess what changed, but I suppose maybe it has something to do with our extended gpib system rather than the individual instrument.
Thank you for your help!