Prevent TestStand from closing LabVIEW FrontPanels after execution completes

[joshua.l.guthrie2.civ]

Thanks!  Well said.  Guessing there was never a way around this?  I'm not missing some setting, or something.

I even created another packed library that calls a VI, that opens another VI asynch and populates the other VI with front panel manipulations, and it managed to nuke that one too.  Got to give it to TestStand, they took memory cleanup seriously.  

I'm ultimately going to solve this by doing my channel creations via a consumer/producer loop where the producer loop sends commands over TCP to the always running consumer.  At this point, i'm just sending asci text and can't imagine TestStand being able to nuke that.  It was a feature I had planned to add in the future, I just get to do it now.

It's just klunky to me that TestStand don't give us any more control on this kinda thing.

[joshua.l.guthrie2.civ]

Shoot, I was suppressed when this didn't even work..

 

[stefanha]

The behavior definitely wasn't that way with TestStand 2016.

We changed our architecture so all references are created in the beginning of the main execution which lives as long as the application.

But this behavior makes debugging quite a bit more difficult, as we cannot simply run parts one after the other without keeping the main execution running waiting at a breakpoint.

[joshua.l.guthrie2.civ]

Yea, I don't think I can cleanly do that for my purpose.

Do you reckon that TestStand is using a segregated portion of memory in the runtime engine, and when it closes the execution it nukes it.?. thus taking out the notifiers/references..  if it did that, I could see the VI I open a-synch being nuked and taking out the notifiers with it?  I didn't expect it being able to into the a-sycnh opened VI and kill stuff created in that..  but if the called VI, and the VIs created from that were all in a memory sandbox, it kinda makes sense..

I'm going to end up getting around this by sending ASCI text commands via TCP loopback.  I needed to add TCP comm functionality anyway, just didn't think I'd end up needing it for something this simple.  

Long-term, I'd love to dump TestStand in favor of a homegrown sequencer.  But that's a feature for future me.   But making a TCP API should make that easier in the future.. so I guess that's a plus.  IMHO, TestStand tries to do too much, and it really doesn't really play all that well with LabVIEW.  Wish there was a TestStand lite.  All I need it for is to call VI's and do some basic math.  Just a sequencer. </rant>

Thanks for your help.  Sorry I wasn't alone in this.

-josh

[joshua.l.guthrie2.civ]

surprised..  I might feel suppressed, but I meant surprised.

---

@joshua.l.guthrie2.civ wrote:

Shoot, I was suppressed when this didn't even work..

 

---

[stefanha]

Going that deep into workarounds, I have implemented something similar as a workaround which does actually work.

Asynchronously spawned VIs which are still running do not get dumped. And if this VI keeps the reference, neither does the ref. (Edit: Important to note these VIs do run in the LV Development System App. I don't know if the behavior is the same when everything runs in the LV Runtime inside TestStand) 

It is a few layers which makes it kind of ugly but it works.

Regular VI which gets called normally in TestStand:

Asynchronously spawned "keep alive" VI:

As long as the loop loops, the reference (in our case a DVR inside the LV object) is alive. 

By the way, we did the exact opposite migration. We used to have our own sequencer, but it simply could not keep up with the complexity of our projects regarding parallelism, multi-instance capabilites etc. 

Which is why we moved to TestStand. The out-of-the-box process models never worked for us, but you can manage pretty big projects with your own process models, as the TestStand engine offers a lot.