Dynamically calling a daemon or actor VI in TestStand

[Mr._Jim]

Hi all,

The context:

• I have a non-reentrant VI that needs to run in parallel of a sequence
• This VI is opened and closed several times during testing.
• I'm closing the VI by sending it a queued request such that it closes itself.

It seems to me that there are a couple of ways to launch the VI:

• Have TestStand call a LabVIEW VI that launches the dynamic VI. This could be via the ACBR node or an invoke node using a static VI ref.
• Use the "Run VI Asynchronously" step type in TestStand.

Right now I'm using the "Run VI Asynchronously" step. I'm not using the "Reserve Loaded VIs for Execution" option, and every once in a while I get the "TestStand Sequence Editor has stopped working" crash.

My questions:

1. With respect to memory management, what's the best way to implement my use case? Is it better to have LabVIEW make the dynamic call, or have TestStand make the dynamic call?
2. What's the difference in how the memory management works between these two methods?

Thanks a lot - any suggestions are much appreciated.

Mr. Jim

[~jiggawax~]

Personally I wouldn't use either of those methods.  I would create a subsequence and place my VI call in there.  Then call the subsequence in a new thread or execution (depending on what I was trying to accomplish).  I've had nothing but issues with the Run VI Asynchronously step.  Plus you have more control with the subsequence because you can add other steps to the asynchronous thread.  Also, in this case TestStand controls the memory space more.

Are you sure it is this step that is causing the editor to crash?  Or is it something inside of the VI that you are doing?

So I'm a bit confused here.  You are talking about asynchronous calls and then you switch to talking about dynamic calls.  Is the VI both asynchronous and dynamic?  There is a difference.

Regards,

[Mr._Jim]

Hi Jiggawax,


Awesome - I was hoping you'd respond, and thanks for the input.

>Is the VI both asynchronous and dynamic?

Indeed it is. The VI is called dynamically and runs asynchronously in parallel with a batch model test sequence. The VI services requests from all test sockets.

> I would create a subsequence and place my VI call in there.  Then call the subsequence in a new thread or execution

Okay, good - I'm using a subsequence already. I will certainly experiment with running in a new thread.

>  Are you sure it is this step that is causing the editor to crash?  Or is it something inside of the VI that you are doing?

(sigh) It's a long story.

So here's a bit more background - we never used to see the sequence editor crash until I recently changed to the "Run VI Asynchronously" step. Now granted, I also drastically simplified the architecture of the VI that's being called, which should in theory make things more stable. However, when the VI had issues with stability in the past (before I worked on it), the LabVIEW environment would crash and the sequence editor would carry on, albeit with complaints about the LabVIEW adapter being hosed.

This is why I suspected that "Run VI Asynchronously" is probably not the best way to go.

>I've had nothing but issues with the Run VI Asynchronously step.

...so it's not just me.  That's reassuring! 

I also fully recognize that, even in its simplified state, this architecture is probably not optimal. In the future I'd like to offload more of the functionality that's being implemented in LabVIEW onto TestStand, but alas, that change is a ways away.

Thanks again, Jiggawax. I truly appreciate your advice.

[~jiggawax~ · Accepted solution]

Let us know how it goes with moving to the subsequence.

Basically the Run VI Asynch call is just creating a subsequence dynamically and calling it in a new thread.  You can view this in the Step Type definition in one of the PreSteps.  But by using the subsequence you are eliminating that dynamic generation portion of it (which I have seen issues with, similar to what you are describing).

Good luck,

[Mr._Jim]

Jiggawax, the method of using a new TestStand thread works astonishingly well!  Once I figured out the synchronization aspects of it I had no problems.

You were right - the best method seems to be "neither."  Now I also understand the full context of what you meany by dynamic and asynchronous in terms of executing the VI.

This seems so much better - it's exactly what I was looking for.

[Mr._Jim]

If you don't mind - I've got another question about how to implement this.

When I'm launching the subsequence in a new thread, I store the object reference in a variable. Later on I use a wait step to watch for the thread to end.

Even after the thread has ended, the thread reference in the variable appears to be valid. Should I do anything additional (i.e. close the thread reference somehow) or will TestStand take care of garbage collection for the thread automatically?

If this is too far off topic, I can start another "thread" and ask the question there.

[~jiggawax~]

TestStand will clean it up for you.  You won't need to kill anything.

If you feel uneasy about that you can always set it to Nothing.  (e.g. Locals.MyObjRef = Nothing) but this is not necessary.

Hope this helps,

[Mr._Jim]

> If you feel uneasy about that you can always set it to Nothing

I'm paranoid and I'm used to being explicit about this kind of thing! 

Thanks again, and enjoy the weekend.