NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing references

Hey all,

 

I'm currently helping a customer out with their issues of keeping references alive in both Test Executive (TE) and TestStand (TS). I'm looking for a best practice on opening references, storing them, and passing them around in both TE and TS. They have been having issues with invalid refnum errors due to the refnum "magically" disappearing at random steps in a sequence (i.e. it was working for earlier steps then all of a sudden one step doesn't work).

 

My question to the community: has anyone seen this behavior before and, if so, what was the resolution? This customer uses the parallel process model in a lot of instances with auto-scheduling so the references to hardware will be passed to multiple processes. These multiple processes could be in different namespaces as well (i.e. reference to HW opened in A.lvproj/OpenRef.vi but needs to be accessed by both A.lvproj/A.vi and B.lvproj/B.vi in TestStand). All steps/sequences use LabVIEW and no other code module.

 

Thanks!



Tim Sileo
RF Applications Engineer
National Instruments



You don’t stop running because you get old. You get old because you stop running. -Jack Kirk, From "Born to Run" by Christopher McDougall.
0 Kudos
Message 1 of 4
(3,360 Views)

Hi,

 

This is how TestStand always worked in versions 1 and 2, very common. Make sure Reserved for Execution is checked in Configure>>Module Adaptors>> LabVIEW is checked. (added in version 3 or 3.5  think)

 

You may have a problem with the different projects. Consider LabVIEW alone. A que reference in one project context of LabVIEW does not exist in a different context. It'd be like trying to share a que between an embedded LVRT VI and a VI on the host PC. I had a bug like this in TestStand when some of my steps specified a .lvproj and others did not and I got errors becasue of dead refnums.

 

If you need to share a single instrument handle between executions like in the parallel model, check out Session Manager. You could also open the instrument in the parent execution entry point and pass the refnum down to all the executions. Or open it in one execution and copy it to a variable that the others have access to, in runstate.root.locals, or a file global or something. This is sort of what session manager does. 

 

They definitely should review how they plan to handle both of these issues and carefully check the code.

 

cc

0 Kudos
Message 2 of 4
(3,337 Views)

Thanks for the advice. I'll have to verify all of this with the customer. It could be that they are configuring one step to reference a VI by project where the step that opened the reference was referenced directly to the VI. From what I've read, that counts as different application instances like you mentioned.

 

I'm not sure if they are using session manager or not but I'll look into it. It doesn't appear that session manager would work with FPGA references which is a major downside (correct me if I'm wrong).

 

-Tim



Tim Sileo
RF Applications Engineer
National Instruments



You don’t stop running because you get old. You get old because you stop running. -Jack Kirk, From "Born to Run" by Christopher McDougall.
0 Kudos
Message 3 of 4
(3,296 Views)

Hi,

 

I would test it with the FPGA refs, or ask the TS AEs, I think Session Mgr is pretty generic, but it is old.

0 Kudos
Message 4 of 4
(3,283 Views)