Prevent TestStand from closing LabVIEW FrontPanels after execution completes

[stefanha]

Our test engineers often debug by opening a VI's front panel from a sequence during edit time, then running that sequence and inspecting the VI's input and output parameters afterwards.

At least that's what they often did in TestStand 2016.

In TestStand 2020, after the sequence completes, the VI front panel automatically closes.

(Running in LabVIEW Development System with a non-reentrant VI)

After reopening the front panel, the values are still there (so the VIs do not get completely unloaded), but reopening gets rather annoying when you have a setup of multiple VIs you want to compare.

In TestStand 2016 the VI front panels stayed open during and after execution.

Did this behavior change or did we accidentally change a configuration for TestStand 2020?
Is there a way to change this behavior?

Thanks.

Stefan

[GD_Scott]

I am experiencing the same issue and would like to know how to prevent an asynchronously called .vi from closing when stopping it from running.

[Anand_Jain]

Hi, 

If you are referring to this issue 1498966 from TestStand 2020 Bug Fixes - NI, it has been fixed in TestStand 2020 f1 patch. 

Regards, 

Anand Jain

NI

[Greil]

Now I have installed "TestStand 2020 f1".

The problem still exists:

After the TestStand execution stops (=background is getting grey) all the LabVIEW Frontpanel window were closed by TestStand.

[Greil]

Detail: TestStand 2020 f1 closes only that Vis which were called during the execution.

Not called Vis will stay open.

[Greil]

Here is a Workaround 🙂

Part 1: Put this into 'Cleanup' of all your sequences and add a precondition:

RunState.CallStackDepth == 0

Part 2: SubVI will do the "re-open".

The small delay is needed to wait until TestStand has finished closing windows.

Thank You for Kudos.

[joshua.l.guthrie2.civ]

I'm seeing something similar and am at a loss.  Figured I'd post here, as I think it's the same topic.

I have a LabVIEW application that I'm embedding TestStand into.  I use TestStand to run test sequences and configure the test benches.

One such sequence creates channels that make LabVIEW calls to a singleton pattern method from a packed library.

Which calls..

The create channel singleton looks like:

Everything runs just fine as long as the sequence is running.  I can put a while loop at the end, and let it loop and it's great.  But if I don't force the sequence to keep running, and allow it to finish execution, it appears the notifier I use as a shutdown notifier gets nuked (see comment "5" in the block diagram above). 

 The keep-alive that I run as-sych:

I get this error, when apparently the notifier I create in the first block diagram gets nuked and the "wait on notification" in the 2nd block diagram see's the reference is now invalid.

Again, these are singleton calls from within packed libraries.  

How do I keep this from happening?  How do I keep TestStand from Nuking my notifier and data structures running from w/in the larger application?   Anyone seen anything similar?

[Anand_Jain]

Hi, 

Can you clarify what do you mean by - "Everything runs just fine as long as the sequence is running. "? Do you release the reference to the TS execution?

Regards, 

Anand Jain

NI

[stefanha]

The experience we made is that when you create any LabVIEW native references (queue, notifier, TCP handle, ...) from within a parallel execution, as soon as this execution completes, the references become invalid even if you had stored them e.g. in a StationGlobal. No matter how you set the unload options or whether you store and keep a reference to that parallel execution.

Stefan

[joshua.l.guthrie2.civ]

No.  I'm the TestStand reference is always fine.  When the sequence stops executing, TestStand seems to be nuking the channels created by that sequence.