Sharing VISA Resources With Multiple Application Instances

Question

I have noticed a strange behavior when attempting to communicate with a
slow, single shared VISA resource (GPIB device) from multiple
stand-alone LabView 5 applications.
Initially, I developed some code which first attempts to acquire
exclusive access to the device using VISA lock with a reasonably large
timeout. After the lock is acquired, the code performs its IO, then
releases the lock.
I then wrote some wrapper code which basically tries to enter the (lock,
IO, unlock) code as fast as possible. I built a stand-alone application,
and ran 3 seperate instances. Basically, I could see that each
instance would eventually acquire a lock, perform its IO, and unlock.
However, some of the instances "starved" for access to the device,
enough so that the timeout was sometime reached (each IO would take
perhaps 2 seconds, and I set the lock timeout to say 10 seconds).
Ideally, each instance should receive the lock in the order by which the
lock was requested. It appears that VISA is doing something else.
I've verified that this issue also exists with "faster" GPIB devices
(say 200ms IO turnaround), but is less noticable because the
communications are faster.
To get around this, I wrote another application which basically acts as
a resource server. Using VI server, each instance which wants access to
the resource sends a "lock" request to the server. Specifically, the
"client" calls a re-entrant "Interface" VI via VI Server. The
"interface" VI then adds the "lock" request to the queue, and then waits
for "Notification" from the server process. The server parses the
request queue, and when the resource is available, it sends a
notification to the appropriate "interface" VI. This whole time, the
client is waiting for the interface VI to return, just like when it's
waiting for a normal lock. When the client is done with the device, it
sends an "unlock" message to the interface VI. The server then gives
the resource to the next item in the queue.
To me, this is a bit kludgey. My solution requires that this "server"
application is running at all times, and it is a bit slower than the
usual manner. Has anyone come up with a better solution?
Thanks,
Andy

Answer 1

My answer depends how stand alone your applications are. I don't know what happens if you have several independant executable files but the simplest solution in the development environment is to have one vi that handles all send/receive requests to the instrument. In this way, without extra overhead, you guarantee single parts of each program access too your instrument. (don't make this vi reentrant naturally)
This approach has another advantage. You separate in a better way the instrument and your aplication, so changing to another instrument is easier to do.
greetings from the Netherlands