Proper steps when shutting down TestStand

[pinguu]

Hi, 

I just want to discuss about like what's the proper procedure on how to close TestStand properly.

I initially found 2 relative post of closing/shutting down here and here, but it wasn't what I was looking for exactly.

I want to know how to shut down your engine/execution when exiting.

Currently I'm using the Process Cleanup CB to like power down the unit, close dlls/hw, etc, etc. however, I used to click File > Unload Modules every time before I start the software again.

I added the ActiveX/Com step to do the Unload Modules at the very end, but I'm asking if we need to like ShutDown first or Terminate, Close All Sequence, ..., etc.

Basically what's the chronological order that TestStand should take from when you exit the application.

Shutdown > Unload Modules

Terminate > Unload Modules

Abort ... ? can we even add a step to unload modules since it does not go to cleanup?

If anyone can chime in. I'm still fairly new in TestStand and want to find the best method.

[~jiggawax~]

Why do you need to unload all modules?  I've never had to do that and I've created hundreds of automations.  Are you seeing a certain error if you don't?  If so what error?

[pinguu]

when I load a library that uses DAQmx, it wouldn't work. Creating a task wouldn't work.

I just assumed that the dll is still in memory and when I unload the modules, it's able to work again. 

Like I stop and clear task for the TaskHandles, but I suppose that doesn't fully reset the device?

DAQmxStopTask();
DAQmxClearTask();

[kosist90]

If so, it means that you do not clear DAQmx tasks properly. It's not because dll is still in memory - when you unload it, all tasks are cleared.

I'd recommend to debug clean up section, and be sure, that all DAQmx tasks are stopped and cleared.

Sincerely, kosist90

Caraya test framework for LabVIEW – convert your VIs to test code!

[~jiggawax~]

There's a simple example linked in a post I put here: https://forums.ni.com/t5/NI-TestStand/Issues-with-DAQmx/td-p/3332628

If you run that example do you see the same issues?

Regards,

[pinguu]

But why would it not clear the task properly.

I basically went through my array and if there is a task handle, to do the following:

1. stop the task

2. clear the task

3. set the taskhandle = 0

So technically, it should have cleared all the issues.

Right now I think the reset work and I don't need to add an ActiveX call to unload all modules. Also, if you're saying that if unload modules is not needed, then when do you recommend on using unload modules from the file menu option?

[kosist90]

---

@b1ack1otus wrote:

But why would it not clear the task properly. 

---

Did you debug this part of code under the lamp, to be sure that really your array has all tasks, and all of them are cleared? It can be silly question, but even such small bugs really happen - is some place of sequence, your task value is reset to zero, and you do not close it at the very end. Especially, I can imagine it with arrays - where do you write your tasks to that array? Are you sure that array is not cleared somewhere? If you have debugged that code module, which clears the tasks in the array, from LabVIEW via lamp - then no question. If you didn't debug it, then you can't be sure, that tasks are really cleared.

---

---

Also, if you're saying that if unload modules is not needed, then when do you recommend on using unload modules from the file menu option?

If you run the sequence/run sequence analysys, and then stopped it, your code modules will be loaded to memory (of course, it depends also on the Load Option properties; b/c code modules could be loaded while sequence open, while sequence execution started, etc.). And then, you'd like to modify some code modules. But - they are locked, b/c they are loaded to TestStand. And in this case, when module is locked/loaded, you can use Unload Modules option to "release" them from memory.

But all reference-related processing inside of code modules must be processed by code modules; and option Unload Modules has nothing to do with this.

Sincerely, kosist90

Caraya test framework for LabVIEW – convert your VIs to test code!

[pinguu]

The .seq file based on VI ... won't run, but I don't think clearing the tasks is the issue.

Like you mentioned in that thread forum, I have no issues running it in CVI as an executable, but running it from TestStand would fail at creating tasks unless I unload the module.

If for example I don't unload module I get a Non-Fatal Run-Time error with status code -200012.

I seem to have a misunderstanding, but when I unloaded module and it worked, I just assumed that I had to unload it from memory before starting the program again.

[pinguu]

Thanks for the clarification.

I am using CVI not LabView, and when I ran it to double check to see if the TaskHandle is being cleared when I do Stop/Clear/Set to 0, the TaskHandle does become NULL.

Well I'm loading the Code Modules at the beginning before the Sequence starts. So it will do analysis if no modules are loaded. However, after running once, it doesn't do another analysis because the modules are already loaded. That's when I thought that I would have to unload the modules to make it work since using CVI, memory is unloaded when execution has finished.

[WireWeaver]

Did you check the return value from DAQmxClearTask? If its not 0 then it probably didn't actually clear the task, which would explain why the device is still reserved.

You can attach the CVI debugger to SeqEdit.exe and throw a breakpoint in your CVI code to see what's going on at runtime. Also useful is the resource tracking window, which should let you know if any of the handles were leaked (you'll have to rebuild the dll with extended debugging level).

Hope this helps!

Trent