Thread.ExternallySuspended method with asychronous vi

[david_jenkinson]

Hi,

My sequence launches a labview queued state machine using the "launch vi asynchronously" step type in teststand.  The vi runs for the duration of my sequence, waiting and acting upon queue messages, initiated by certain teststand steps that call an "enqueue" labview vi.  I want teststand to pause while work is being done in the vi, until the vi finishes and waits for another queue message.  From what I gather reading on page 3-7 in the teststand reference manual, using the "Testand - Set thread externally suspeded.vi" in teststand palette should accomplish this.  Based on reading this, I am thinking, once a queued string is recieved in the vi, set Thread.ExternallySuspended true, and after the work in the vi, set it false again to let the sequence resume.  But on first experimentation, behavior did not seem to be according to this.  The seqeunce continued anyway regardless of setting Thread.ExternallySuspended true.  The help file says "to allow TestStand to suspend the parent execution thread while still executing code in the code module."  The "allow" word implies I need to do something on the teststand side in addition, to get it to pause?  If so, what?

Thanks

David J.

[Scott-M]

Hi David,

To use the set Thread.ExternallySuspended VI in LabVIEW you would have to pass a "This Context" reference to the VI, however one of the requirements while using the asychronous mode is that you won't be able to pass references. How were you running this?

Thanks

Scott M.

[david_jenkinson]

I am passing ThisContext to the SequenceContext context control in my vi, when launching the vi using "Run VI Asynchronously".  I'm am not sure what requirement you are referring to, because it seems to work fine.  In some cases of the state machine, I am writing data back to step properties, and merely putting post delay in the step to ensure teststand doesn't move on to the next step before the labview has a chance to write to the step property.  The property values write fine so I know a valid sequence context is being passed. 

I wanted a more robust way to do have teststand wait a time determined by the asynchronous vi, which is sounded like this tool might offer?

David J.

[Snowman 6008]

David,

The best way to pause the execution is through lock steps after you've called your VI in a sequence in a new thread. Check out this example on how to do this. If you like you can even change the status of your lock inside of LabVIEW. Though this violates the modularity (the code you call in TestStand ideally should be able to be called without TestStand), though this example may require you to change your LabVIEW code, it will be more manageable and more debuggable if you ever have to pass the project off to someone else.

http://decibel.ni.com/content/docs/DOC-8028

[dug9000]

David,

It sounds like you are trying to use Thread.ExternallySuspend as a synchronization mechanism. That is not its purpose. The purpose of Thread.ExternallySuspended is to let TestStand know it can treat your thread as suspended when determining whether all threads are suspended for a breakpoint. Normally, all threads within an execution must be suspended before a breakpoint can be shown.

Also, trying to synchronize things by telling teststand to suspend an execution is not likely to be the correct approach because all of the threads in TestStand are running asynchronously so by the time you tell teststand to suspend it might have already run any number of steps in other threads after you wanted it to stop, but before it got your command.

Instead, what it sounds like you are trying to do is a classic handshaking synchronization of passing some work off to a worker thread and waiting until it's done, but you are missing part of that synchronization. What I would suggest is that when you enqueue a message to the asynchronously running VI, that you should also enqueue (perhaps as part of an enqueued cluster) a labview notification as well. Then your enqueuing VI can simply wait on that notification after it does the enqueue and the asynchronous VI can simply set the notification when it is done with the work. Basically, rather than thinking about the problem from the idea of stopping the TestStand execution you can think about it from the idea of the enqueing VI needs to wait until the enqueued work is done.

If I am misunderstanding what you are trying to do and the solution I proposed is not sufficient. Please let me know in more detail what you are trying to do and perhaps I can come up with a better solution.

Hope this helps,

-Doug

[david_jenkinson · Accepted solution]

Doug,

I think you hit the nail on the head and that sounds like something that would actually work.  I have been tossing around something like that around in my head but wasn't quite seeing where teststand would "listen" for the vi to be done, but an additional queue message back from the worker vi is the perfect solution.   It would just require me to add a 'dequeue" after "enqueue" in the vi which sends the queue message, which is actually a vi attached to a step type.  By waiting to recieve a "done" queue message back, teststand is effectively paused.  This is brilliant.  This one is a definite head slapper, should have thought of that myself. 

Thanks very much

Regards

David J.