VISA read & write takes ~4.5s each for GPIB instrument

[Brooks_LV]

Hi,

I have a large application that handles communication with 5 devices.  Three of these devices communicate using telnet via a terminal server.  The other two devices are on a GPIB bus.  The two GPIB devices are an Agilent 34970 data recorder, and a Chroma 61605 AC source.  I am having problems reading data quickly from the Chroma 61605 AC source in the large application.  The read time for 5 measurements (AC Voltage, Frequency, etc.) is ~45 seconds when in the large application.  Each measurement consists of a VISA write and a corresponding VISA read.  Both the VISA write & VISA read take ~4.5s to execute when in the large application.  So, 4.5 seconds for each read & write for five measurements gives the 45s read time (4.5s*2*5=45s).

However, when I pull the measurement functionality out and put it into simplified code, taking all 5 AC source measurements takes ~ 90 ms.  This is more along the time I was expecting for the read.  I have tried setting all VISA reads & writes to asynchronous which didn’t resolve the delays.

A few more details that may or may not be important:

1. I am dynamically calling the Vis that communicate with all the instruments
2. I am reading from & writing to some of the instruments.  When I do this I use a semaphore to ensure that I am not doing both at the same time
3. The Vis that I call dynamically for communicating with Agilent recorders are reentrant because I spawn 1-4 instances depending on how many recorders I am communicating with

Thanks in advance for your help!

B

[johnsold]

Brooks_LV,

Without seeing your code it is hard to tell what might be happening.

Sometimes GPIB instruments can be slow, but you seem to have ruled that our with your simplified test VI.

My suggestion would be to change the architecture to something like a Producer/Consumer. Place the GPIB communication in the Producer loop with nothing else except the queues to pass data.  Assuming that all the devices are one one GPIB bus, just pass the GPIB address (or a string which uniquely maps to the address as a parameter when calling for a read or write. Use that same ID to returnt the data to the correct "channel" in the processing VI. The idea is that there is only one VI which does all the GPIB communication, and it does nothing else. If necessary spawn additional named queues for each added device.

Lynn

[Brooks_LV]

Hi Lynn,

Thanks for your reply.  My architecture is set up such that each dynamic process I spawn is simply reading from or writing to the GPIB instrument with little else happening.  In the case of the read, I simply read and then put the data in a memory space (FGV).  I have verified that the FGV is not causing the latency.  It happens at the VISA write & VISA read.

However, I can try your suggestion of having one VI that does all the communication with the GPIB bus.  I will simply wrap a VISA write & VISA read in another VI and make it non-reentrant to ensure that only one instrument can access the bus at a time.  I would assume that the VISA driver would handle this for me but maybe not...

Thanks for your suggestions and let me know if you have any other ideas.

B

[EricBehrs · Accepted solution]

Brooks_LV-

Any time I am dealing with IO timing issues, the first thing I look at is the IO Trace log.  You can find out the source of most timing problems from studying the timing info. (Time and Duration columns) in the log (note: I don't think Duration is viewed by default.  You need to go into the Tools->Options menu and under View Selection tab, make sure both Time and Duration are checked).  You should be able to glean from studying the trace whether you are looking at Bus Timeouts (the most common source of delays) or whether the problem is in your App. code.  First off, if you see any red lines (other than the Asynchronous Wait on Event calls) on the Write/Read calls (especially the Reads), then check the error code and see if the call is timing out (to do this double click the log entry, switch to Output and read the Status Description).  If you see Read timeout errors, and call durations on the order of 4-5 sec, then you are dealing with bus timeouts.  If the call durations are small (ms range), but consecutive call start times are long (look at the Time column to see start times), then you are probably looking at a problem in your code.  Either way, if you get more information and are still having trouble, report the results back here and we can figure out how to solve it.  You might even attach your log file directly.

If you aren't familiar with the basics of IO Trace capture, here is a good starting point:

http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

-Eric

[Brooks_LV]

Hi Eric,

Thanks for your reply!  I used the old NI Spy tool years ago and wondered where that functionality had gone.  From looking at the NI IO Trace data, I found that I was sending an ill formed message to one of the devices on the bus which caused the time delays.  Problem solved.  Thanks so much for your post!

B