Can two different module adaptors control same device?

[WillJazz]

In TestStand, can two different module adaptors be used to control the same device? For my application, the UUT is a receiver that communicates via a serial port. I might desire to send setup commands to the receiver with LabVIEW but use C routines to process the message stream coming back from the receiver. Can this be done or must I stick to one module adaptor type to intialize the comm port, setup the receiver and process the messages from the receiver?

[SachaE]

Hi,
I can't see you doing this using VISA, as in CVI, it requires a handle to the instrument, which isn't used by LabVIEW. You should be able to do this through the plain RS-232 settings though. (In LabVIEW you need the compatibility .vi's for serial)

Another option is to handle the hardware interface in one layer (i.e. pick either LV or CVI), and then handle the data manipulation in the other.

Hope this works out. (I tried this on my PC, but my serial ports are a bit screwy (had problems before), but it didn't throw up any errors)

S.

[Jason F.]

You can actually do this quite easily with NI Session Manager. Basically, Session Manager allows you to "share" instrument sessions between loosely coupled code modules as the following excerpt from the Session Manager help indicates in its description of what an "instrument session" actually is:

Instrument sessions are ActiveX objects that enable software modules to share instrument I/O API handles easily. An instrument API handle is:

· An instance handle for an instrument driver such as an IVI or VXIplug&play driver
· An ActiveX reference for an instrument driver such as an IVI driver
· An instance handle or ActiveX reference for an I/O library object such as a VISA session

Use an instrument session to obtain an instrument API handle. You can obtain t
he same API handle multiple times in different software components. The session initializes the API handle when you first request the handle. The session closes the handle when you release the last reference to the session. Typically, you do not explicitly initialize or explicitly close the instrument API handle.
Each instrument session has a unique name that you assign at configuration time. To reference an instrument session, specify the name of the session.

To use the Session Manager in TestStand directly, you can use the ActiveX Automation Adapter to invoke methods and set/get properties on session objects exposed by the server. If you want to access them in LabVIEW you must use Invoke and Property nodes in the same fashion, and with LabWindows/CVI you can simply create an ActiveX Automation Controller library that exposes functions for manipulating Session Manager.

To find out more about Session Manager, open the C:\Program Files\National Instruments\Shared\Session Man
ager\Session Manager.hlp file and read it for a quick overview.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[SachaE]

Hi Jason,
I agree that the session manager is exceedingly useful if you want to not re-initialise instruments that have a handle returned, and share across multiple threads / sessions / module adapters, but I refer to my earlier comment - wrt VISA, LabVIEW uses the resource name, and CVI uses the handle to the instrument and the VISA session - so how, even with the aid of the session manager, can these be mixed? Can you do an example?

I'm going to try the mixed modules on another PC tonight. Will post results back later.

Thanks
S.

[Jason F.]

You absolutely can mix modules created in different IDEs to communicate with instruments using VISA and the Session Manager's facilities. This is a built in feature, allowing you to specifically select what API your communication will use (IVI, VISA, IVI class, IVI specific driver, VXIPlug&Play driver).

The Session Manager exposes interfaces for several different levels of driver interaction. Since IVI relies on VISA for its multi-bus support and Session Manager easily integrates with IVI control of instruments, it is understandable that it can do the same with VISA alone. I don't have a readily available example that illustrates the use of VXIPlug&Play drivers with Session Manager, but if you have TestStand 2.0.1 you can do a simple combinat
ion of two of the shipping examples to see the intermixing of CVI and LV modules that communicate with a single instrument using IVI and Session Manager.

To do this, simply open both of the following sequence files in the TS Sequence Editor:

C:\TestStand\Examples\SessionMgr\LV\LVDmm.seq
C:\TestStand\Examples\SessionMgr\CVI\CVIDmm.seq

Now, delete any of the steps in the LVDmm.seq MainSequence and replace them with the steps' of the same name in the CVIDmm.seq MainSequence with a simple copy and paste (make sure to put them in the same place as the steps you replaced and to resolve the paths for the modules of the steps). After you have done this, simply execute the edited sequence and you will see an example of mixing modules from different IDEs.

For more information on using VISA I/O API handles (this is a term used specifically by Session Manager), you should check out the section of the Session Manager help file I commented on before titled "InterfaceLevel Enumeration".


Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[SachaE]

Hi,
OK I get the idea now - the session manager is actually starting off the VISA session, and then you convert the number to a reference of the appropriate type.

Q. In the help on Sharing Instrument Sessions between Processes, it says "A limitation of cross-process sessions is that VISA, VXIplug&play, and IVI C-based instance handles are not valid across processes. "
When run from TestStand, you have to run CVI module adapters as In process, and LabVIEW through the TestSTandLVRTS???????

I've attached a couple of files, that I can't get working. The fourth (missing) file is the NISessionMgr.ini file, in which I added a copy of the example logical name Serial1 under the VISA logical names section.
What am I doing wrong
? I keep getting " 'IVI' is not a driver session category. in GetSession.vi->LV com1 write.vi->LV com1 write.vi.ProxyCaller".

Thanks

S.