Parallel Process Model vs Asynchronous Sequence

[GSinMN]

I've been studying the features of TestStand, and learning how to use it for about a month, so still very new to the environment (although I have been using Labview and Veristand pretty heavily for about a year).  I wanted to get a little clarification on the use of the different process models, because I think I may be misunderstanding some of the terminology.  

Here is a little background of my project:

I have a Labview VI that I created to interface with a remote target (emulator).  I previously used the VI to run tests manually, and would like to use it as a code module in TestStand so that I can run automated tests.  I intend to use the same VI repeatedly throughout the test sequence.  The functionality of the system is dependent on maintaining constant communication with the emulator, so I can't be opening and closing the code module repeatedly.  Once it is open, it has to stay open and continually communicate  (I'm hoping I will not have to create "wrapper" code modules to be the go-between with my current VI).  Breaking communication would cause most of the test results to become invalid.  For these reasons, I had chosen to call the VI as a code module in a sub sequence so that it can be run asynchronously, outside of the main sequence.

Now, as I learn more about the details of TestStand, I am introduced to the concept of "Process Models".  I had initially been using the default Sequential Process model, but would like to know if I should switch to the Parallel Process model.  From what I can tell, the parallel process model is used when testing multiple UUTs, or running tests in parallel.  Is this correct?  To clarify my situation, I will only be testing 1 UUT, I will only be using 1 code module, and I will be running several test steps with that 1 code module.  I will need to continually pass data back and forth with the code module as it runs in parallel to the main sequence, and there will likely be several sub sequences called during the process, so that I can maintain modularity with my testing.

So the question is, do I switch to the Parallel Process Model, or should I continue with the Sequential Process Model and the asynchronous sequence to run my code module in parallel?  Thanks much.

GSinMN          

[Daniel-E]

Hey GSinMN,

Are you wanting to run your test steps in parallel with each other, or will that need to be a sequential process? The Parallel model is probably not the right choice for this application. The purpose of the Parallel model is to run the same test program on multiple UUT's at once, as you mentioned. Since you are just testing with a single UUT, the best approach would be to run the emulator communication module asynchronously, as you mentioned. You can easily pass data to this code module using a TestStand queue or a similar synchronization object.

[GSinMN]

Hello Daniel,

  Thanks for the quick response.  For the most part, the steps will indeed be run as a sequential process.  In fact some of the test cases are dependent on results from previous steps (which is why the code module has to be running continuously).  Steps may be run in subsequences, but they won't really be run in parallel.  There are a few test cases that require me to "interrupt" what my remote target is doing, but in those cases, the step/command will have already been issued from TestStand, and the step will have been completed (it's just a matter of careful timing at that point).

Thanks again.

GSinMN   

[Daniel-E · Accepted solution]

I'd definitely recommend using the Sequential model with an asynchronously running sequence for the special code module, in that case. Let us know if you have any more questions about how to architect the system! It's definitely a good idea to plan these kinds of things out before you get too deep in the development.

[GSinMN]

Thanks Daniel.  I've already started down the path of deciding what kind of queue to use.  Looks like a global queue might work best, that way I can control the loops in Labview and TestStand separately, and not need to worry about reassigning parameters.  As I understand it, TestStand wouldn't even need to call the VI directly, so it would truly be "asynchronous".  

GSinMN