teststand breakpoint hangs in subsequence

[user50]

I'm fairly new to TestStand and running into a problem.  We're running LabVIEW 2010 VI's and TestStand 2010.

I can set breakpoints in my main sequence just fine, but as soon as I set a breakpoint in one of my subsequences TestStand hangs.  The yellow arrow appears over the breakpoint however the resume and step into/over/out buttons do NOT activate.  I'm just stuck and all I can do is terminate all. 

Is there an option I'm suppose to be setting?

Bryan

[RayFarmer]

Hi,

Does it occurr if you try with one of the teststand examples (Computer Motherboard example) that doesn't use labview?

[user50]

The Computer Motherboard Test works as expected.  I can set breakpoints in the subsequences and step through.

My sequence is set up so I run a CAN communications loop (send/receive/processing bus data) in a new thread.  This thread is always running in the background processing data which other steps/VI's interface with.

Breakpoints before my call to start CAN work as expected, but breakpoints after the CAN thread is up and running do not work.  I tried skipping the CAN thread and my subsequences debug successfully.  Can TestStand set a breakpoint in one thread while continuously running a different thread?  What might be happening?

Bryan

[dug9000]

You need to use the API Thread.ExternallySuspended inside of your VI that is constantly running in its own thread. This API tells teststand to treat that thread as suspended with respect to breakpoints. Normally, an execution cannot be suspended while a thread is inside of a code module, but with the Thread.ExternallySuspended API you can make an exception for specific cases you know are safe. You should also be using the TerminationStatusMonitor in the asynchronous VI so that your VI knows when the user has requested for the execution to terminate or abort. I believe there are wrapper VIs around both the ExternallySuspended and TerminationMonitor APIs in the TestStand LabVIEW palette inside of LabVIEW.

Hope this helps,

-Doug

[RayFarmer]

Not quite sure but breakpoint may be execution related and therefore any breakpoint set well suspect all threads within an execution.

Try setting your new thread to be a new execution instead.

[user50]

I built a quick demo of what is happening.

I launch a new thread that just runs, and then I have another sequence call that displays the iteration count.  You put a breakpoint in that subsequence where you display the count, and it does not work as expected.  I think your only option is to terminate the test.  Am I configuring this wrong?

[dug9000]

Please see the post I just made above. You need to use the TestStand palette VIs to set the thread as externally suspended, you should also be using the termination monitor VIs. These VIs use TestStand APIs to help make threads that run in code modules for long periods of time work better with TestStand.

You can also instead use a separate execution as Ray suggested since that will move the call to your asynchronous VI into a separate execution, but that separate execution will also have similar problems unless you add the calls to the APIs I mentioned above. Also it's nice to have all of your threads in one execution so that you can terminate everything by terminating that execution (if your async VI uses the termination status monitor is will know to exit when termination is requested).

-Doug

[user50]

The Set Thread Externally Suspended.vi worked in the demo.  Thanks for your help.

Bryan

[dug9000]

Just a reminder, you need to set it back to false before your VI returns back to TestStand (you're probably already doing this, just wanted to make sure you know about this requirement though).

-Doug