Simultaneous access to different VISA resources from LabView

[Eric L]

Hello,

I am trying to debug a problem that I am seeing. 

Basically, we have a system with a number of gpib instruments on it, that are being controlled thru LabView and TestStand. 

We have drivers up and running for all the instruments, and they work okay in isolation, but when we try to run everything together we are seeing VISA hang.

The basic goal is to have a LabView Vi that runs in a loop to monitor an array of power supplies. 

Simultaneously, other LabView vi's (controlled by TestStand) will read and write various instruments. 

We implemented semaphores for the power supply drivers, so only one program at a time can have access to them (LabView monitor program, or TestStand) and this seems to work well.

However, it seems that whenever I do a VISA close of another instrument, while simultaneously doing VISA io to the power supplies, and the system will hang (I need to kill the LabView process to regain control). 

I understand that only one program/thread should control a specific instrument at a time, but I had thought that as long as different threads were using different instruments, that they could open, read, write, and close independently (i.e. I shouldn't have to lock all gpib access when doing any gpib transactions).  That appears to be the only way to prevent it from hanging, however.  I am hoping to avoid adding semaphores for ~20 vi's. 

So, my basic question is whether I can access different instruments from different vi's simultaneously. 

I have done some reasearch, but seem to have found conflicting info. 

http://zone.ni.com/devzone/conceptd.nsf/webmain/6b896f37c2d2cc5686256804006875dc

This shows a multithreaded example, where different threads use the same interface

to talk to different instruments, it appears.  This seems to indicate that

simultaneous access to the same controller is okay?  They do use thread specific

gpib status indicators, though. 

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=F20C6F004FFD4AD8E

0340003BA7CCD71
This also suggests simultaneous visa is okay in labwindows.

http://digital.ni.com/public.nsf/allkb/C42CDC77C00E0B8086256E9B0078F887

This mentions that if you are using the same gpib card (which I am) then you can not do simultaneous IO to different instruments with LabView.

http://digital.ni.com/public.nsf/allkb/ECCAC3C8B9A2A31186256F0B005EEEF7
This mentions that LabView has 4 threads to use for LabView processes, perhaps  this is not enough to deal with the different instruments?

"As a specific example, the LabVIEW Runtime Engine has 4 threads to use to

distribute LabVIEW parallel processes by default."

I am usings LabView 7.1, VISA 3.3.1, TestStand 3.1 (but I can reproduce this using just LabView). 

Thanks in advance.

Eric

[LuI]

Eric,

there are _some_ implicite and explicite Qs in your posting. I can't answer 'em all, but here's my Euro 0.02:
* In a test system of my own, I have (in fact _had_) two dual-powersupplies (PSP) running on the very same GPIB controller.. There had been different scenarios when one of those PSP was set once while the other had a series of states to reach. This worked quite well when running just one process (either using TS or LV). But I had problems when trying to run several independent processes in parallel, despite using Semaphores and global adresses etc.
So the main A shall be YES, it works.
* I did not find the reason why I had those problems with independent processes. FInally I changed the setup to 1:1, meaning 1 PC and 1 Test setup testing 1 UUT. This works now.
* AFAIK each of LVs execution systems (UI, standard, Instrument I/O, DAQ, other1 and other2) can have up to four threads running in parallel. This does not really provide much more threads to execute in parallel, but ...
* I'd suggest using NI-Spy to detect what happens before youir sessions are locked. Maybe a bug in VISA or the drivers?

As I mentioned, just my Euro 0.02!

Greetings from Germany!<br>-- <br>Uwe

[JoshuaP]

If you are using an NI GPIB interface, please upgrade to NI-488.2 version 2.4 or higher.

-Josh

[Eric L]

Thanks for the comments.

For the GPIB driver, we did upgrade to v2.4, but saw the same behavior.


In the NI Spy, the issue appears to be the viclose. 
If one vi finishes it's transaction and closes it's visa reference while the other vi is still doing a transaction (i.e. it sends a query and then reads the response) then both vi's will hang.  The last line in the NI Spy is always the viclose statement.

NOTE: when LabView hangs it is not entirely frozen, I can still open new LabView windows, etc, but I have to kill LabView to stop the vi's that are running (it appears to be stuck in the viclose call).  It won't timeout and return control, it just gets hung up. 

Regards,
Eric

[Travis_W]

Eric,

Are you writing sychronously or asynchronously?  Try switching to a synchronous write if you are not currently doing so.

Also, make sure that none of your VISA resources are the same, as this is one possible cause of the problem you are seeing.  If you are communicating with the same resource with multiple VISA sessions, try writing synchronously and setting the "Duplicate Sesison" input on the VISA Open VI to TRUE.

Travis W
VISA Enthusiast

[Eric L]

Travis,

We are doing async writes.  We will try out sync writes. 

I am pretty sure that visa resources are different, but I will double check that.  We do have an array of identical power supplies that is being scanned so it is possible.  I do remember checking that before, but it has been awhile.  The power supply scanner vi does work fine by itself, though, it's only when I run another vi to talk to other equipment (like a frequency counter) that issues come up (when a viclose is done while the power supply scanner is in the middle of a query).

Eric

[bfarley]

Eric,

I am having the exact same problem.  Did you ever get a solution?  Did changing to synch work?

Bill F

[Eric L]

Bill,

My recollection is that we did not find a "good" solution (i.e. we don't understand why it is happening). 
What we did do was use vi's to get exclusive locks to the gpib card, etc. so only one device could be talked to at a time (i.e. lock the gpib card, do some reads and writes to an instrument, then unlock the gpib card). 
It seems kind of clumsy, but it works.

Eric

[bfarley]

Eric,

When you say "lock the gpib card", do you mean use the VISA Lock Asych vi?

Bill F

[Eric L]

I'm not in front of the system now, but my memory is that it was a VISA lock vi that we were using,
which lets you set an exclusive lock on the gpib0 card, as well as a specific instrument (gpib0::7::instr) 

Eric