Will iblock work for GPIB-USB?

[bk1]

Hi All,

I will have two different applications running simultaneously on 1 PC  and  both

will be going after the same GPIB resources.

Does anyone know if "iblock" will work for GPIB-USB or if there is a different

mechanism for this situation?

Regards,

Bill

[Makoto]

iblock() and ibunlock() functions are specific to GPIB-ENET.  I believe they only work with GPIB-ENET.  One easy way to synchronize two apps is use Mutex - an NT kernel object of Windows. 

Alternatively, if you can use VISA library instead of NI-488.2M API, you can use viLock() and viUnlock().  These functions will work for any I/O interface types that VISA supports.  Mind that they synchronize VISA calls from multiple threads or processes at VISA's resource level, not at thread level.

[ScottieB]

The VISA suggestion is a good one, but iblck() (it's not iblock in current driver versions) does work for all interfaces.  This is only a board-level call, not a device-level call, so you can lock your HS but you cannot lock the devices you have attached to your HS.  See NI-488.2 help for more info.

Scott B.
GPIB Software

[bk1]

Makoto / Scott, Thanks for the replies.

More info:

I will be running  two seperate TestStand applications with each application

running multiple threads. Every thread in each application will access the

gpib instruments.

Please clarify the following for me:

If Application #1 calls iblck(), it will prevent Application #2 from accessing any

gpib instruments. However, the multiple threads that are running within

Application #1 still have access to the instruments.  

Regards, Bill

[ScottieB]

The help for iblck() appears to indicate that this is a process-level lock, not a thread-level lock.  Thus I believe other threads in the same process will be able to use the board.

Scott B.

[bk1]

Scott,

I couldn't find iblck in Labwindows 7.1 (only iblock). After a little digging, I found it in a dll in a windows system32

folder and then called it from TestStand. It appears to function as you have stated. Thanks much for your

replies.

Regards, Bill