How can we avoid RunState.Engine.UnloadAllModules()?

[Foreshadow20]

How can we avoid uning RunState.Engine.UnloadAllModules()?

Right now I have this in my ProcessCleanup Callback of my MainSequence. However I feel like this is cheating and to me it seems like opening hardware without ever calling the close.

Can this cause issues with threads, references and hardware to hang?

How can VIs be unloaded without issues?

It seems that TestStand have major issues with this one. I would prefer clean code.

Thanks

[RaviShrigiri]

Hi,

Not sure why are you calling the unload modules.

If you are using a process model to run your test sequence ( Single pass or Test UUT) :

You can add a Process Setup call back for your test sequence  which initialises the instruments (create handles and set default output).

You need to add a process cleanup call back where you close the handles.

When execution is completed the VIs will be unloaded automatically.

In short you call the VI which initialises the instruments in the start of your testing and in the end call a vi which closes the instruments.

Hope this helps,

Ravi

[Foreshadow20]

For some reason TestStand is not closing my VIs at all when the sequence unloads.

I do numerous Open + ReadAI/WriteAO + Close without any issues. But when my sequence ends and I open the VIs, they are still in Run Mode. Unless if I do UnloadAllModules() or via the File Menu.

It also does that for many other VIs.

[Mathis_B]

In the step properties (Step settings | properties) under "run options" you can select the "unload option" "unload after sequence executes".

Is that what you were looking for?

Best Regards

Mathis

[dug9000]

VIs are kept loaded until you close the sequence files containing them by default. That can be changed on a per step or per sequence file basis, but in general there isn't much down side to leaving the default setting. It saves you the time of reloading everything again on the next run. You might need to do unloadallmodules if you want to edit a VI before running again though.

-Doug

[Foreshadow20]

It works to unload, but calls to DAQmx don't work after the Open has been unloaded.

[Foreshadow20]

---

@dug9000 wrote:

VIs are kept loaded until you close the sequence files containing them by default. That can be changed on a per step or per sequence file basis, but in general there isn't much down side to leaving the default setting. It saves you the time of reloading everything again on the next run. You might need to do unloadallmodules if you want to edit a VI before running again though.

-Doug

---

I closed my Sequence file with my DAQs Drivers and ran a sequence in another directory calling the DAQmx and the DAQmx VIs were still loaded when the test was complete.

I guess there's no issues if code remains opened. My serial VIs were still opened and I was able to use another serial software to open a serial port was was used.

Basically the unload when sequence file unloads is broken. So why is it the default option?

[~jiggawax~]

Did you still have an execution or other sequence file open with those same code modules?  I have a hard time believing they were still open.  What version of TestStand are you using?

How did you verify they were still open?

[Scott_Richardson]

We are not aware of any issue with the unloading of modules when file is unloaded. What is likely happening is that there is an unreleased reference to the file.

One thing to investigate is whether your VIs are not properly releasing TestStand references, such as those to a SequenceContext objects. If the VI does not release a context object, the VI holds on to that reference until the VI is closed. As such the context cannot fully cleanup, and the context could have a reference to the sequence file of concern, and that file cannot be completely unload. Although you might have closed the file, the file is still in the engine cache and its VIs are not automatically unloaded yet.

The engine does not report these types of "reference leaks" on shutdown because once VIs are unloaded, LabVIEW releases the reference to the context and thus to the file, and then during shutdown, the engine looks for leaked references.

One quick thought would be to create a unload callback sequence in the file. It might be interesting to see when this callback is called, either when you close the file or when  you unload all modules. If when you unload all modules, it might support my theory. If it is called when unloading the file, it might be just that the engine calls it and the file could still have a leaked reference.