How do I separate IVI channels from the particular instrument

[pblase]

Using LabWindows/CVI, and I'd like to make sure that I'm addressing this properly.

I have several functionally identical instruments (GPIB), each of which has several channels. I would like to separate the channel from the particular instrument that it is resident on. (The instruments are functionally similar, and have similar instrument drivers, but may be of different vendors). I don't think that I can realistically put the operations for each channel in its own thread. Does IVI handle this sort of thing? What happens if I try to open the same IVI driver for the same instrument twice without closing it first? Or is there a better way to handle this. I was thinking that I could write a channel class driver, which would in turn open the appropriate instrument driver.

Paul

[Makoto]

> What happens if I try to open the same IVI driver for the same instrument twice without closing it first?

No problem happens at all.  Every IVI instrument driver is designed as "thread-safe" as specified so in the IVI specs.  If your app opens 2 instances of instrument session using the same IVI driver and connecting to the same VISA address at a time, they will have different sessions (meant different IVI handles assigned) and both sessions will be active at the same time.  However, when accessing the instrument from multiple threads at the same time, some lock/unlock mechanism will be needed.  The locking method can be Win32 critical-section, semaphoe, mutex, or can be IVI driver's <prefix>_LockSession() function.  The <prefix>_LockSession()/UnlockSession() functions are normally wrapper functions that invoke VISA viLock()/viUnlock() inside.

As for driver DLL virtualization, the driver module that your app will use can be automatically switched by using IVI class driver (such as IviDCPwr class driver for power supply) and with IVI Configuration Server settings including LogicalName/DriverSession/SoftwareModule/HardwareAsset etc...  However it requires all the IVI drivers your app will use must be compliant with the same instrument class. 

As for channel name virtualization, PhyisicalName and VirtualName capability of IVI Configuration Server supports it.  If the IVI driver "A" supports the instrument trace channels as "Channel1".."Channel4", and the other driver "B" supports "Trace1".."Trace4" names, you can't embed these hard-coded channel names in the app to avoid driver-specific dependency.  Instead, you can configure your own channel names such as "MyTrack1".."MyTrack4" mapping to appopriate channel names as your need, you can virtualize these name in your app.  This virtualization can be managed in NI-MAX, once you have installed NI IVI Compliance Package 2.x.

[pblase]

Thanks much.

Paul

[z_haider]

Makoto wrote:

>"No problem happens at all.  Every IVI instrument driver is designed as "thread-safe" as specified so in the IVI specs.  If your app opens 2 instances of instrument session using the same IVI driver and connecting to the same VISA address at a time, they will have different sessions (meant different IVI handles assigned) and both sessions will be active at the same time.  However, when accessing the instrument from multiple threads at the same time, some lock/unlock mechanism will be needed.  The locking method can be Win32 critical-section, semaphoe, mutex, or can be IVI driver's <prefix>_LockSession() function.  The <prefix>_LockSession()/UnlockSession() functions are normally wrapper functions that invoke VISA viLock()/viUnlock() inside."

Thread safety is a completely different issue from using multiple IVI sessions in the same program.

IVI is thread safe in the sense that the *same* IVI session can be safely used from mutliple threads of execution. This is achieved by synchronizing IVI driver calls using the Ivi_Lock() and Ivi_unlock functions. These functions are *not* wrappers over VISA functions. They are implemented using operating system level synchronization primitives.

Using more than one IVI session to the same instrument is not recommended. Calls from one IVI session will invalidate the state of other IVI sessions. This is true regardless of if you are using the sessions from multiple threads or not.

z_haider

[Makoto]

> Using more than one IVI session to the same instrument is not recommended. Calls from one IVI session will invalidate the state of other IVI sessions. This is true regardless of if you are using the sessions from multiple threads or not.

This may be true for most IVI drivers.  But some good IVI drivers (especially for IVI-COM's) are well managed so that internal state can be shared between different IVI driver session by using Win32 memory mapped file, if the target VISA resource descriptor is the same.  For example, the "state cache" status for the driver session "A" can be shared by the driver session "B" if both sessions are from the same driver DLL and connecting the same VISA address.  But in many cases, IVI drivers are not designed so.

For actual system operations, running more than one program that have accesses to the same instrument with the same IVI driver is not a very rare case. 

[pblase]

Old thread, I know - new question. If I'm writing the driver, are the calls inherently thread safe through the NI facility that handles IVI drivers, or do I have to add all of the lock-unlock stuff myself?

[z_haider · Accepted solution]

Hello pblase,

Yes, all IVI Engine functions are thread safe. However, if you are implementing a driver, then you must make your driver functions thread safe by using the Ivi_Lock and Ivi_Unlock functions. If you are using LabWindows/CVI, the Instrument Driver Wizard (Tools >> Create IVI Specific Driver...) generated code will do this for you. Or you can download one of the existing drivers from idnet  and look at the source. 

[pblase]

Thank you. That's what I needed to know.