Using Labview "Session to RefNum" with Teststand

[bilby42]

I'm trying to use share a common GPIB IVI scope session between Teststand steps that call various Labview Vis. I've created the initial IVI session in a Labview steptype, then stored this successfully in a Teststand local variable using "RefNumtoSession" and a Teststand "Set" property.

In the next Teststand step I use a second Labview VI and use a Teststand "Get" property. I pass the results of this successfully to a "SessiontoRefnum" to get my IVI session handle back.

However, when I try to use this recovered handle in a Labview IVI step I get a broken wire with a class conflict error. Strangely, if I probe the data I'm getting out of the "SessiontoRefnum", it appears to refer to correct IVI session. 

Any ideas would be appreciated. I've enclosed both labview VIs that I used.

Regards,

Tom Rolfe.

[JonathanN]

Howdy Tom,

You are doing a lot of extra type casting in your LabVIEW VIs that you do not need to.  In TestStand, some of the LabVIEW I/O controls are represented as clusters with two elements, Device Name and Session Number. You can specify either a device name or a session number. The session number will always be used if it is not zero. The session number can be used in other development environments, such as LabWindows/CVI, as long as they are in the same process. You can use the TestStand data type, LabVIEWIOControl, to create variables for I/O controls.  The I/O control references that are represented this way are VISA, IVI, FieldPoint, Motion, DAQmx Task Name, and DAQmx Channel Name.

To insert this variable, go to your Locals tab, right-click and select Insert Local >> Types >> LabVIEW >> LabVIEWIOControl.   Then you can pass this variable in and out of LabVIEW without doing any typecasting. See the attached screenshots. 

Anyway, this is the best approach and architecture design you want to concentrate on.

Hope this helps!

Best Regards,

[bilby42]

Hi Jonathan,

Thankyou for your reply to my query. I had already been using your method of passing my instrument handles between LV and Teststand using a LabviewIOControl. However I was experimenting with the typecasting method I described as I wanted to try to connect LV to the IVI instrument handle that Teststand automatically opens on startup.

Hence my question is.....

I'm a little confused about how many IVI handles should be opened at once when working with Teststand and LV together. I know that Teststand automatically opens an IVI handle at startup for each instrument, which can be used in subsequent native Teststand IVI steps.

However, should you open an additional IVI handle for LV to use in LV VIs, or can you simply connect to the IVI handle that Teststand automatically opened????????

If you can connect LV to the already opened Teststand IVI handle how is this done? I've tried to use session manager, and the Teststand IVI Tools step to get instrument sessions, but cannot get LV to share this common resource.

I greatly appreciate your help with this confusing issue,

Regards,

Tom  

[JonathanN]

Howdy Tom,

The instrument handles created by TestStand IVI step types cannot be used within LabVIEW VIs that execute using the LabVIEW development environment. The underlying C-based handle can only be used within the TestStand process. If your LabVIEW code modules invoke IVI class- and driver-specific VIs, we DO NOT recommend using the TestStand IVI step types at the same time.  Hence you will need to decide which one to use.

IVI step types complement, but do not replace, the instrument configuration and measurement operations you perform in code modules that you write using LabVIEW, Measurement Studio, Microsoft Visual Basic, or other tools. Those IVI step types in TestStand were designed for ease of use but of course you do sacrifice performance using these steps.  Although IVI step types are the easiest way to configure and acquire data from IVI class instruments, you must use code modules to control instruments under the following circumstances:

• When you need to precisely specify the instrument driver calls to ensure optimal performance.
• When you need to call specific driver functions that an IVI class does not support.
• When your instrument does not conform to an IVI class or does not have an IVI driver.
• When you need to interleave your instrument control operations with other code that must reside in a single code module.

If you are using the IVI step types, TestStand automatically initializes the instrument session when the instrument is first configured and automatically closes the instrument session when the execution is closed. 

Hope this helps!

Best Regards,

[bilby42]

Hi again Jonathan,

Thankyou for the instantaneous reply.

Your reply was clearly explained. I'll use only LV IVI steps in future.

Are there the same limitations when using Switchexecutive in both Teststand and LV?

I've found an example on ni.com that passes a Switchexecutive session between subsequent LV steps in a Teststand sequence. They did this by passing a NISE Session variable (Number U32), between different VIs called by Teststand. If I do call Switchexecutive steps from inside LV VIs, this does this mean I shouldn't use the Teststand Switchexecutive steps in Teststand?

Regards,

Tom

[JonathanN]

Howdy Tom,

The example you were referring to was not using Switch Executive inside of TestStand but rather using Switch Executive in LabVIEW.  TestStand was just passing a switch reference in and out of its steps.

We recommend using Switch Executive inside of TestStand unless you plan on switching routes in the middle of a test. Using it inside of TestStand allows for great organization, easier dealings with multithreading, ability to use pre and post expressions with switches, etc. Its a good idea to keep your switching at the top level generally. 

There is also a good discussion forum on this topic located here that will also give some insight. 

Hope this helps!

Best Regards,

[bilby42]

Hi Jonathan,

After writing my last post I spent time experimenting using Switchexecutive inside Teststand, and I take your point - The Switchexecutive engine is well supported/integrated into Teststand steps. I'll try to structure my code to only utilise Switchexecutive inside Teststand in future.

Thanks for all your advice.

Regards,

Tom