Moving vi to faster computer throws VISA async queue error (-1073807303)

[tkott]

First off, let me apologize for posting again - for some reason I didn't find the Instrument Control board the first time around. Originally posted in the general forums, where it is down to page 3 and I doubt will ever see the light of day: http://forums.ni.com/t5/LabVIEW/Moving-vi-to-faster-computer-throws-VISA-async-queue-error/td-p/1767...

Our group recently bought a new quad-core computer with plenty of RAM. We've had LabView under version control, so we simply installed the same version of LabView on the new computer, checked out all the newest code, hooked up our GPIB cards, and started running the same programs as before. However, during a program run, I can easily overload VISA's async queue for a particular session, throwing error -1073807303. Here are (I think) the relevant bits (the code is too convoluted to paste in a single vi):

1. The particular program makes sessions for about 7 or 8 instruments. 5 of those instruments are at the same GPIB address (these are Stanford Research Systems Small Instrumentation Modules).
2. I use duplicate sessions for VISA, combined with ASYNC locks / unlocks to control access to each VISA session (hence the async queue error, most likely)
3. Sessions are created once in the class constructor, and destroyed once in the class destructor
4. After each VISA write or read, I try to delete all remaining events in the queue
5. The setup stages of this vi are run in parallel, and hence the vi might attempt to contact 4 or 5 instruments 'at the same time'. The lock mechanism stops this from causing havoc as intended.

Now here comes the fun part. The same code, running on a 32-bit XP-SP3 (LabView 2009), dual core, 2 GB RAM computer doesn't throw any errors. Running on a 64-bit Windows 7 + LV2009 + 24GB RAM throws the following error:  (-1073807303). 

I have read the following posts:

• http://forums.ni.com/t5/LabVIEW/VISA-Error-1073807303-Unable-to-queue-the-asynchronous-operation/td-...
• http://digital.ni.com/public.nsf/websearch/AC1DB4A19F08157E86256E130064C463?OpenDocument
• http://digital.ni.com/public.nsf/websearch/DB91703C3BAB8DA6862569AB006137D4?OpenDocument

According to the third link, deleting the events manually is not good enough - instead the recommendation is to close the VISA session.

Now for the questions:

1. Any idea why this would be a problem on a newer machine? My gut tells me that essentially the computer is now fast enough to load up the async queue faster than the GPIB card can handle the requests. On the older computer, the processor itself was the slowdown.
2. Which is the solution that will ensure the fastest operation:
1. Open (and lock), then close a session at each and every need for communication with an instrument (does this come with a performance penalty over keeping a session open, because I need this program to consistently query the seven instruments usually 2-3 times each as fast as possible, since my data runs already take hours and the defining time limit is labview currently)
2. Increase the ASYNC queue size until I no longer see the error.

Memory shouldn't be an issue, since I'm only using 8 / 24 GB (even with a 64-bit virtual machine running at the same time). My biggest worry is that open/lock/close session will give even more overhead. (even 20ms of overhead, when there are about 20-25 calls "per step" would increase the overall time fo the data run significantly).

Sorry if this is a bit rambling without a definitive VI to show.

Thanks in advance,

Tomek

[tkott]

Our group recently bought a new quad-core computer with plenty of RAM. We've had LabView under version control, so we simply installed the same version of LabView on the new computer, checked out all the newest code, hooked up our GPIB cards, and started running the same programs as before. However, during a program run, I can easily overload VISA's async queue for a particular session, throwing error -1073807303. Here are (I think) the relevant bits (the code is too convoluted to paste in a single vi):

1. The particular program makes sessions for about 7 or 8 instruments. 5 of those instruments are at the same GPIB address (these are Stanford Research Systems Small Instrumentation Modules).
2. I use duplicate sessions for VISA, combined with ASYNC locks / unlocks to control access to each VISA session (hence the async queue error, most likely)
3. Sessions are created once in the class constructor, and destroyed once in the class destructor
4. After each VISA write or read, I try to delete all remaining events in the queue
5. The setup stages of this vi are run in parallel, and hence the vi might attempt to contact 4 or 5 instruments 'at the same time'. The lock mechanism stops this from causing havoc as intended.

Now here comes the fun part. The same code, running on a 32-bit XP-SP3 (LabView 2009), dual core, 2 GB RAM computer doesn't throw any errors. Running on a 64-bit Windows 7 + LV2009 + 24GB RAM throws the following error:  (-1073807303). 

I have read the following posts:

• http://forums.ni.com/t5/LabVIEW/VISA-Error-1073807303-Unable-to-queue-the-asynchronous-operation/td-...
• http://digital.ni.com/public.nsf/websearch/AC1DB4A19F08157E86256E130064C463?OpenDocument
• http://digital.ni.com/public.nsf/websearch/DB91703C3BAB8DA6862569AB006137D4?OpenDocument

According to the third link, deleting the events manually is not good enough - instead the recommendation is to close the VISA session.

Now for the questions:

1. Any idea why this would be a problem on a newer machine? My gut tells me that essentially the computer is now fast enough to load up the async queue faster than the GPIB card can handle the requests. On the older computer, the processor itself was the slowdown.
2. Which is the solution that will ensure the fastest operation:
1. Open (and lock), then close a session at each and every need for communication with an instrument (does this come with a performance penalty over keeping a session open, because I need this program to consistently query the seven instruments usually 2-3 times each as fast as possible, since my data runs already take hours and the defining time limit is labview currently)
2. Increase the ASYNC queue size until I no longer see the error.

Memory shouldn't be an issue, since I'm only using 8 / 24 GB (even with a 64-bit virtual machine running at the same time). My biggest worry is that open/lock/close session will give even more overhead. (even 20ms of overhead, when there are about 20-25 calls "per step" would increase the overall time fo the data run significantly).

Sorry if this is a bit rambling without a definitive VI to show.

Thanks in advance,

Tomek

[A_Donfigulation_Error_Has]

Hi Tomek,

Just to reiterate, you have been receiving error -1073807303 (Unable to queue the asynchronous operation because there is already an operation in progress). I find this highly unlikley because you seem to be thorough person, but I would verify that your drivers are the same on both computer setups.

Regarding your questions, yes this is probably happening because your newer computer setup queues commands too fast. Like you said a possible option would be to increase the buffer sizes. I'm specifically thinking the UART FIFO buffers, more information can be found about them in these links: http://digital.ni.com/public.nsf/allkb/ECCAC3C8B9A2A31186256F0B005EEEF7?OpenDocument and http://digital.ni.com/public.nsf/websearch/2D5F972CD550BBC386256F0B005E9A63?OpenDocument .

As to say which one of these two options will be better performance-wise is hard to say. The only way to really verify this is to run NI Spy or NI IO Trace to determine how fast the "Close VISA Event Session" compared to the "Discard Event" will take. Of course, increasing the buffer would be the easiest solution, but you run the risk of overflowing the queue again because you know for sure that you are queuing up items faster than you are dequeuing.

Jason L

[tkott]

Hi Jason,

Thanks for the two links. I'm not quite clear how to change the buffers you mention. I only see the following visa option under "General Settings":

I had a response on the other thread as well, and it seems that the following are things to try:

1. Make the communication vi's reentrant
2. Increase async queue
3. Use synchronous read/write calls
4. Try out open/closing sessions (with appropriate locking)

Thanks,

Tomek