Keep vis from a dynamicaly called sequence in memory

[JÞB]

In a nut shell, LabVIEW 2012, TestStand 2012.

I have a functional test solution to provide that invloves a common test platform and several mateable "Fixtures" that expose the "Platform" resources in simillar ways for the specific UUT and have some common fixture resources but several fixture unique features.

So, of course, I created a a LabVIEW project template that can re-create the "Common" functions in a project that each Test sequence can call into.  Essentially Model determines UUT type and calls InitAllHw.seq by expression.  Basic! "InitAllHw.seq" needs to load several resource modules From "UUT specific *.lvproj" (Action Engines) in PreUUTLoop.  Easy Right?   Call "MainSequence" in "xxx"+Right(Station.Globals.FixtureType,y)+."init.seq" 

Sadly, the resouces go bye-bye when the callback for InitAllHw.seq leaves and the USR's in my AEs blank out.

So, when the Test.vis in "UUT specific*.lvproj" are called the AE's have ZIP in their USRs.

There has got to be a way to do this! 

What did I miss?

[DowNow_]

Hi,

Yes, the PreUUTLoop is only in memory while it is executing, then it leaves memory. This is the same with all TestStand sequences. I think you will have to dynamically open/launch your LV2 Global/USR VIs with VI server or asynch call node in PreUUTLoop. You could pass a reference to each back up to some variables Runstate.Root.Locals if desired. Another thought, TestStand 1.0 had a LabVIEW "daemon" VI that launched when the process model sequence executed, and just stayed in memory for the purpose of keeping file references and VI SErver references, etc. alive. So, you could put all your USR VIs in a VI, have the process model launch them (asynchronously) so they would stay in memory, and then in the cleanup of the process model sequence close/destroy the VI. (Launch them in a SeqCall in separate thread or with VI server or with the Asynchronous Call step. You could do this in PreUUTLoop or ProcessSetup...)

Of course, the mention of TestStand 1.0 should set off some alarm bells. I'm don't know the details of your project, but I'll bet there is a more TestStand-centric, and thus more scalable design that will meet your requirements. For example you could use TestStand variables instead of USRs. 🙂

cc

[JÞB]

Thanks for the advice.  It at least got me thinking allong the right lines.

"For example you could use TestStand variables instead of USRs. :-)"  is exactly the behavior I do not wish for.  I've never understood why people require TestStand to know about hardware resources much less let TestStand be the only access to hardware and thereby make debug and station maintainence a total nightmare.  Perhaps thats just my personal issue but it seams counter to every best practice about good data hiding when encapsulating a set of related functions.

The Async call would have been a player if the silly async call launched the vi's in the context of the *.lvproj (Where all the DAQmx Tasks are stored) so I get to resort to calling Init All HW.vi on xyz.lvproj with show front panel when called (minimized if in a teststand context) and close that FP only when I want the resources released.  (A silly work around that shouldn't need to be invented IMHO)

Again, Kudos for the help.

[bruno_p]

Hi,

I'm an experimented TestStand user but i'm a LabView beginner.

I think I understand your problem but I'm not sure if the following solution is a good programming way :

Maybe you could create a vi with a while loop and a shift register. The loop contains only a case structure with 2 cases, Initialise and Get.

The Initialise case will initialise the shift register and will be called by your Init All HW.vi.

The Get case return the valueof the shift register when you want to use it.

As the loop is running, you don't loose your value.