TestStand 4.1 threading bugs

[SPM]

Hi, all,

I'm starting a thread in TestStand at the setup of a test to monitor messages arriving at an RS-232 input port as the test progresses. This is causing some bad behavior in TestStand:

• When a breakpoint in the main sequence is hit, the Variables tab is empty. (if I disable the start of the thread, it shows up fine.)
  
• Only the Main Sequence thread shows up in the threads list.
  
• If there is an error in the main sequence, TestStand locks up while trying to display a popup. (A workaround is to select Configure->Station Options->Execution->On Run-Time Error: Run Cleanup, but the default option is "Show Dialog," and it had us floored for a while.)

The problems persist if I start the thread in the main sequence rather than the setup.

These are fairly serious problems, IMHO.

Is there something I can set, patch, or otherwise fix to get past these problems?

Thanks,
- Steve.




Message Edited by SPM on 06-17-2008 09:36 AM

Message Edited by SPM on 06-17-2008 09:38 AM

[MartyMcDAX]

Hello Steve,

In TestStand, you can't use the debugging tools for a multithreaded application unless all threads are suspended, as desribed here.  So, if you RS-232 sequence is still running, then the debugging tools will not be available to you in your main sequence when a breakpoint is hit.  This is most likely why your variables are not populated once you hit the breakpoint.

I am a little puzzled the error popup would lock up, however.  Are you doing any UI work in your RS-232 sequence?  What kind of code modules are you calling?  It could be that this RS-232 thread needs to "Use Single-threaded Apartment" under the sequence call options.

Can you reproduce this issue without communicating with any hardware?  I would recommend setting all the RS-232 steps to Run Mode -> Skip and see if you still experience this problem.

[SPM]

Hi, Marty,

Thanks for your help. Some further complications:

• I'm using LabVIEW.
• The examples that are given for setting Thread.ExternallySuspended are for CVI, so they don't help.
  
• Trying to set property "Thread.ExternallySuspended" resulted in an error message "Unknown variable or property name 'Thread'."
• I took a look at the structure of the SequenceContext parameter in TestStand, and it didn't help.
  
• I searched the docs for about an hour and didn't find any way to do what's needed.
  

How can I set Thread.ExternallySuspended in LabVIEW?

I'm not doing any UI work in the RS-232 sequence. I'm just trying to read input lines, calling VISA open, read, and close.

I'll try to cook up a brief example.

Thanks,
- Steve.





Message Edited by SPM on 06-18-2008 01:34 PM

[SPM]

Hi, Marty,

Here is a project that shows both problems without any RS-232 stuff.

Set a breakpoint on the "Cause Error" step in the main sequence to see the breakpoint bug.

Clear the breakpoint and run with the "Show Dialog" station option on run-time error to see the popup bug.

Hope this helps,
- Steve.

[MartyMcDAX]

Hello Steve,

If you are looking at this Developer Zone article that describes setting this value of Thread.Externally Suspended, you can find the LabVIEW code in the second zip file, 202809.zip.

I've tested this example and it should work.  If you want to get the CVI code running as well, let me know and I'll investigate that too.

[SPM]

Hi, Marty,

OK, that solves both the popup and breakpoint problems.  (I must have seen that file yesterday... DUH!)

But why isn't the Externally Suspended option set by default?

Thanks for all,
- Steve.

[MartyMcDAX]

Hi Steve,

I'm glad that solved your problems.  This is the expected behavior in TestStand.  If multiple threads are running, you are not able to use the debugging tools, unless they are all suspended.