Behavior of VISA lock/unlock

[mjjohnson]

I'm redesigning the current VISA drivers for several instruments we use.  Since it's possible that several different VIs will want to access the same instrument at more or less the same time, I want to lock the instrument to ensure that certain operations happen uninterrupted.

I found VISA Lock Async and VISA Unlock and decided to use them, since they're built in and seem like they should do what I'm trying to accomplish.  ("Use this function to obtain an exclusive lock that guarantees sole access to a device or resource.")  However, when I send two commands to a device and deliberately delay unlocking after the first one, so that the second command should wait until the first has unlocked...I see the effects of both commands simultaneously.  Turning on highlight execution confirms that the second instance of VISA Lock Async executes successfully before the first lock has been released.  And they're configured for exclusive locks, not shared locks.

I've attached a screenshot of a sample VI that shows this behavior.  Am I doing something wrong, or am I somehow misinterpreting the fairly direct language in NI's documentation?  Do I need to resort to semaphores and abandon this tidier solution?

[Dennis_Knutson · Accepted solution]

I think your problem is that you are accessing the same resource. Look at the example program called 'Locking'. In there, there are two different resources created.

[Aaron_W.]

Pepper,

Thanks for posting on the forum. I believe that Dennis is correct in his suggestion. When looking at the Locking.VI from the NI Example finder it does use two VISA resources to the same resource and locks one when the other is in use. I would suggest looking through that example and see if you can build a program off of that. That specific example seems pretty close to what you are trying to do. Thanks!

[mjjohnson]

Ah, okay.  I didn't realize that it locked for the specific session.  That makes sense, though, now that I think about it.  We sometimes use the same session for concurrent operations, so I might end up using semaphores rather than the VISA lock/unlock VIs.  Thanks for the help!

[Stijn_Schacht]

Isn't it possible to start up a session for every use of the bus and then close this session again. Meanwhile, you can lock the session directly after opening it, or at least try to lock the session. After you have read/write whatever you needed, you can unlock the bus again and close the session so that another session somewhere else in the program can obtain the resource.

In your sample code you where fairly close to doing this. If you started two sessions instead pf one and then closed each session afterwards, it would have been fine.

I used to use semaphores for bus access exclusions, but now I tend to use this VISA locking mechanism more, since the semaphores introduce a lot of wiring clutter that does not belong in a VISA session VI.

best regards

[mjjohnson]

I don't know if that is possible or not, but it wouldn't work too well with the way we're doing things: we have a class for each instrument, and the VISA session is part of the class's private member data.  So we have the same VISA session for all of the class's methods, and I can't think of a cleaner way to do it.

However, locking and unlocking with semaphores really isn't that bad, depending on how you set up the drivers.  We have a couple of low-level private VIs: one that sends a command (the command string is passed to it), and one that sends and then reads back the result (used for queries).  All the other drivers then use these, so we only have to put the semaphores in a couple of places.