Resource Reserved

[Zuc_Lab]

Goodmorning,

I’m using the USB-6211 device for some tests in generating and measuring tones for electroacoustic devices. The USB-6211 actions are controlled by different Vis which are called by a TestStand sequence which can run them also in different threads. Sometimes, since the test went wrong, I need to stop the sequence even if some threads are still open and are working. I receive the pop-up advice with the option to abort the execution with the option “kill all thread”, but after that if I run again the sequence the Labview steps don’t run correctly giving the warning attached here. So, my questions are what kind of resource is blocked? How I can programmatically free it maybe in the clean-up part?

If you have any information to better undersdtand how teststand and Labview work fell free do share the links with m, I will be glad to read them!

Thank you for the attention!

Best Regard,

Zuc

[billko]

Unloading all modules might work.  Shutting down TestStand AND LabVIEW should work.

[Zuc_Lab]

Hi Bill,

I kown it, if I unload all modules and reboot the USB-6211 by removing the cable which connects it to the PC, all start to work perfectly. But my will is to try to understand why the resources remains reserved.

Thank you for the help!

Zuc

[billko]

---

@Zuc_Lab wrote:

Hi Bill,

I kown it, if I unload all modules and reboot the USB-6211 by removing the cable which connects it to the PC, all start to work perfectly. But my will is to try to understand why the resources remains reserved.

Thank you for the help!

Zuc

---

When you stop TestStand by terminating, it stops in its tracks, and whatever resources it is using don't get released.

[JÞB]

Super DAQmx Ninja to the Rescue!

First I'll reiterate a maxim that I keep trying to get across to the uninitiated.   DAQmx Tasks, Scales, Channels, etc...should only be created once.  Preferably by the developer and seldom if ever at runtime.  This means you have to STORE them somewhere and embedding them in your LabVIEW Project is a really good idea. 

Now, since those definitions are in the *.lvproj file you will need to call the DAQmx dependant vis through the project context by specifying the lvproj file in TestStand (or it won't find the definitions in the lvproj. )

This get you a whole bunch of wonderful things but, in your special case, one is very convenient.   Aborting a TS execution and unloading all modules destroys the LabVIEW Proxy caller owning the lvproj target contexts and the OS garbage collector sees all those VISA resources that the destroyed context had reserved and shreds them.  Whereas, if you do the insane thing of creating those same DAQmx (VISA underneath) and storing them in TestStand as DAQmx objects in a variable, the resources now have a scope of the Main TestStand application instance and you suffer from exactly what you have done wrong.

[Zuc_Lab]

Hi JPB,

thank you for your replay. Let me sum up for understanding if I get your point: you are suggesting to insert in the TS sequence not a single vi but a project complete of preconfigured task with an already chosen channel. But since in my sequence its possible that the user changes the channel on which the actions are performed, for me it’ easier to pass the channel as a string to the vi-call step. If I am not wrong in your method all the channel is fixed by project and so the user has to modify it from the project, is it correct?

Best Regards,

Zuc

[JÞB]

---

@Zuc_Lab wrote:

Hi JPB,

thank you for your replay. Let me sum up for understanding if I get your point: you are suggesting to insert in the TS sequence not a single vi but a project complete of preconfigured task with an already chosen channel. But since in my sequence its possible that the user changes the channel on which the actions are performed, for me it’ easier to pass the channel as a string to the vi-call step. If I am not wrong in your method all the channel is fixed by project and so the user has to modify it from the project, is it correct?

Best Regards,

Zuc

---

You seem to have understood about half of that.

Let's define the problem you are having as:" TestStand does not release resources store in TestStand Variables unless the resources are properly closed or the owning context is closed."

This means when you abort execution any resources reserved by the TestStand application do not magically release.

You, of course, have the option of writing bug-free code so that aborting execution is not required.  This is not a path you chose.

Tests are a matter of scientific inquiry based on exact intentions and should never be based on a user's whimsical adjustments of the stimulus or response.  You have not produced a test.  It's more akin to a plaything than a means to obtain evidence disproving the null hypothesis. 

Give your user's only what they need per requirements.

In any case, the DAQmx stuff is stored somewhere.  Having them embedded within the xml file with a lvproj extension is very convenient and DAQmx knows to do really cool things like creating ini files for executables and limiting the scope of those resources to a project context.  They become "Protected" in scope.  Whereas stuffing them into TestStand permits everyone and his brother to grab onto those resources with a simple ActiveX call.  That is poorly designed resource management. 

[santo_13]

 "Abort" in TestStand is the same as "Abort" in LabVIEW, ideally, you never have to use it as long as you've written the software properly. This is for the worst-case backup if things get out of control. One would not expect a car to start and run properly after stopping by ramming into a wall.

A better way is to put all the DAQmx stop and clear in the cleanup section of the sequence and you ONLY use Terminate and NOT Abort.

https://forums.ni.com/t5/NI-TestStand/Difference-between-Abort-and-Terminate/td-p/2398316