variables not accessible during debugging

[HansWi]

Since yesterday I have a strange problem:

When i set a breakpoint in my sequence and run it, I  can not access the variables pane (it is empty).

This happens also in an older version of the sequence.

I also am not able to resume the test (F5) or to step over (F10)

I installed the patch this morning to be sure that al known issues are fixed, but this did not help.

I use TS 2010 f1 (4.5.0.330)

[TSJim · Accepted solution]

Hi,

I've seen similar behavior when I launch a VI in a separate thread.  I have to close the VI and finish that thread in order to use the debugging features in the main sequence - there is a workaround for this.

Do you have a separate thread executing when your debugging?

Jim

[HansWi]

Yes,

I have a CallExecutable (.exe) step in a seperate sequence that is called as new thread.

This thread needs to be running during the whole test. (server program) the step itself has all the normal settings.

The sequence call has as extra setting only the "Use New thread"

Should I do something with the trace setting?

Would it help to turn off the record result? (Ichanged to another product, so I cant test it right now)

Do you also know this workaround by any chance?

[HansWi]

I found the solution: Problems Using the Debugging Tools When Multiple Threads Are Running in TestStand

***********

Solution:
The problem is that in order for an execution to break, all threads must be between steps. In other words, the execution cannot break while one of its threads is calling a module. It must wait for the module to return.

There is, however, a way around this. Using the TestStand API property Thread.ExternallySuspended, you can tell the TestStand engine to treat the thread that is running your code module as if it were an already suspended thread. When a thread is externally suspended, TestStand no longer requires it to be between steps in order for the execution to break.

The way you use the property, Thread.ExternallySuspended, is by setting it to True before the code in your module starts running and then set it to False immediately before returning from your module. You can get a reference to the Thread object from the Sequence Context (i.e. SequenceContext.Thread).

*********

NI advises to set this property IN the code module (at least that is what they do in the examples).

However I did it just by using the "statement" step before my .exe call: RunState.Thread.ExternallySuspended = True

and one after it: RunState.Thread.ExternallySuspended = False

And now i can indeed debug again. Thank you for the push in the right direction.