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

[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

[KHartley]

Tomek,

Question 1:

You could be correct in assuming the new machine is faster but it also might be better predicting where the thread can be split while running. I'm wondering if maybe two different processes try to lock down the same session at the same time/to close to each other. A way you might beable to get around this by creating a Reentrant vi. Maybe writing a sub vi to control the locking and unlocking of sessions. Which only 1 instance can be used so it would force the other threads to wait.  Also you could try just posting a small wait in each communications after the locks so a specific GPIB loop doesn't starve the other loops. Maybe just a several (ms) wait might help things.

Question 2:

Opening and closing sessions does add a potential overhead to your operations. I can't say for sure how much but it would slow things down a little. Depending on your devices and the amount of data, Synchronous calls might be better. Asynchronous will be faster for large data but if you need things to happen in order and its only smaller data amounts synchronous might save you some headache.

The easiest proposed work around are probably increasing the queue size and seeing what happens. Then maybe open/closing sessions and seeing if performance suffers too much because of it.

Please let us know what you try and how it works out for you.

[tkott]

Kyle,

Thanks for the response. I had actually reposted the question on the GPIB / VISA forums (http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Moving-vi-to-faster-computer-throws-VISA-asyn... since this topic had gone down to the 3rd page by then - I hadn't actually expected a response at this point...

If I understand you correctly, you're saying that the operating system / processor predicts where it can split the application flow, and when it comes to the communications bit, it tries to duplicate / use that simultaneously, which throws the error. I can see how switching the vi to reentrant form would help solve that, since then at least it would be clear that each copy is in it's own memory space, regardless of thread switching.

As for your second suggestion, that was also mentioned on the others. All of my communication in this application is cerainly of the write "volt?", read "9.22e-3" type, so really short strings. I think synchronous write/read might be okay in this respect.

I've currently de-parallelized some things which also solves the problem, and I'm in the middle of a data set. When I get a moment, I think I'll try the following remedies in order:

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

[KHartley]

Tomek,

Yep, Labview will spin off a bunch of threads when it compiles. So you could probably assume that each of your loops gets its own thread at least. So The processor might switch cores for whatever reason when it is executing your code. 

So small data values like that might be better with Synchronous calls. Where it wouldn't take long to prepare the data for transmission or where it would have to continuously fetch data for an extended period of type. Asynchronous was meant for large transfers like acquiring the image off of a scope. Where if it took awhile to prepare that data it allows other calls to take over the bus and write and read smaller packets while the first(larger transfer) was waiting to be filled.

No problem on the double post. Sorry about the long wait time I was just trying to figure out the best way to reply to your questions. Hopefully the reentrant documents will get you up and running soon. The mod's will probably move the thread so if it disappears from the LabVIEW board you'll know why.