Teststand 4.1.1 Crashes when using two or more "run VI Asynchronously" at a time

[dug9000]

Make the data type in your VI parameters PropertyObject instead of SequenceContext. Use the PropertyObject API to set them. For example, if I have a variable that's a string called Locals.MyString in the main sequence and pass that into the asynchronous VI directly as a PropertyObject. Then inside the VI I can get and set the string value using SetValString and GetValString from the PropertyObject API with an empty string specified for the lookupstring.

Hope this helps,

-Doug

[glennjammin]

What about using the termination monitor in LV?  Don't I need the Sequence context for that or is the termination monitor necessary?

[glennjammin]

Doug

Thanks for all you help.  I now understand it a lot better.

I think what I am going to do instead of passing the data back and forth in a new thread. I am going to do all the testing in a single VI and when the test is done pass the data to teststand to evaluate the results.

I believe I am over complicating it by having teststand do too much of the work, where I can do it in LV.

Although I am still curious about my previous question on the Termination monitor.

[dug9000 · Accepted solution]

If you need the termination monitor then I'd recommend not using Run VI Asychronously and instead using the Sequence Call with the New Thread option. That way you can safely use the sequence context from the new thread rather than using the original thread's sequence context (which is unsafe). The reason it's bad to share sequence contexts between threads is that they represent the state of a particular sequence call in a particular thread so they are constantly changing while that thread is running which introduces race conditions if another thread tries to access it at the same time. This does bring up a good point in that the usefulness of the Run VI Asynchronously step type is somewhat limited given this issue. I will record this as something to investigate for a future version of teststand.

At any rate, I didn't mean to discourage you from using TestStand for this. I think it actually isn't as hard as I might have made it sound (I think there is an easier solution than I originally thought too) and I think I now understand your use case so, in summary, if you want to try it, I'd recommend the following:

1) From your original thread's sequence insert a sequence call configured to run a new sequence containing your VI in a New Thread. Look at the advanced subpanel for additional options available with the New Thread setting that you might want to use.

2) As parameters to the new sequence, pass the variables you want to directly modify in your VI. For example Pass Locals.myvar into the subsequence for Parameters.myvar (make sure you pass by reference, though that is the default). Do NOT pass the sequence context as you will just use the new thread's  ThisContext as the one to pass to your VI.

3) Pass ThisContext into your VI, in this case, ThisContext is the context of the new thread rather than the original thread.

4) You can simply update your code to use the lookup strings for the parameters rather than the locals in order to access the variables from the original threads sequence. For example use "Parameters.myvar" instead of "Locals.myvar" because you are accessing the versions of the variables in the new thread's context that were passed in to it by the sequence call.

Hope this helps,

-Doug

[hans17]

Doug, thank you for your 4 step solution.  I came across it in via a search on "TestStand crashes" and it solved the problem I had with TestStand 2010.

Here's my problem scenario:
I created a VI to show the value of 15 TestStand sequence variables such as UUT power on/off, DC voltage, and Pass/Fail status and also to chart a couple temperatures.
I called the VI from the sequence using a Run VI Asyncronously step and passed it the sequence context of the main sequence.  Since many of the TestStand variables were updated by several sequences in different sequnce files, they were stored as Station Globals.
In the VI, the TestStand Get Property Value VI was used to poll the 15 variables once a second.  This scheme worked well until I tried to run my sequence continuously for five hours.  After 4 hours, the sequence editor crashed with the Microsoft error message stating that SeqEdit.exe has detected a problem and needs to close.  The Windows Application Event Log showed an error with Event ID 1000 and indicated a possible problem with msvcr80.dll (which turned out to be a red herring).  When the long test was repeated, the same crash happened at random times which is indicative of a race condition as Doug states in this thread.  When a test case was created by modifying the sequence to write to the station globals in a tight loop and the status VI was modified to poll the TestStand variables continuously without a loop delay, the SeqEdit.exe crash happened in seconds.  Note that no Station Global variables were added or deleted during this test, TestStand just wrote to a couple Station Globals and LabVIEW read them.  It appears that if the TestStand main sequence thread writes to a Station Global variable at the same time that the LabVIEW VI's thread reads them from the same sequence context, TestStand's memory gets scrambled and crashola.

I modified my test case TestStand sequence per Doug's steps 1-3 and changed the VI per his Step 4, using locals and parameters instead of Station Globals.  Instead of crashing after several seconds, SeqEdit.exe ran for 20 minutes with no problem.  I then implemented Doug's steps 1-4 in my actual TestStand sequence and ran for 50 hours without a crash. Thanks again Doug!