Problem with "Execute -> Break on First Step" option in TS2.0

[Bob Rafuse]

TestStand 2.0 running on Windows 2000 Pro SP2.

I have a large custom process model (~377KB). I have noticed some strange
TestStand behavior while attempting to run the sequence files that use my
custom process model.

If have no breakpoint, but I check "Execute -> Break on First Step" in the
Sequence Editor and press F5, TestStand stops, but NOT on the first step in
my process model's Setup step group, as I would expect. Instead it
curiously stops on something like to 20th step in the Setup step group. It
always stops on the same wrong step. There is no branching before this
step. This "wrong step" is set to Normal Run Mode and has no break point.
I am at a loss to understand why TestStand is stopping on this step and not
my first step.

I experimented by placing a real break point on the first step in my process
model's Setup step group, but left "Execute -> Break on First Step" enabled.
TestStand dutifully break points on this true first step. When I hit F5 to
continue, execution proceeds normally. It does NOT stop on the "wrong" step
that it stops on if no breakpoint is set (or any other non-breakpointed
step). Its as if TestStand thinks it has already broke on the first step.

Removing the breakpoint on the true first step, but leaving "Execute ->
Break on First Step" enabled, results in TestStand breaking on the "wrong"
step again.

It appears as though some internal step order data in TestStand is getting
confused and it somehow thinks by 20th step is my first step for the
purposes of "Execute -> Break on First Step".

This is more than a minor annoyance as I'm seeing intermittent,
non-reproducable bugs that indicate some of my Setup step groups may not be
getting called. If I set breakpoints on these steps, everything works fine
and I never see the problems. If I don't set breakpoints and use
"Execute -> Break on First Step", then one out of every thirty or so
executions, things act like my Setup code was skippped (as if TestStand were
really starting on the 20th or so step). I can't say for certain that this
is whats happening, but the fact that TestStand seems to be confused as to
the actual first step in my sequence in alarming.

Is this a known issue? If so, does 2.0.1 by any chance address this issue?
If not, are there any workarounds or solutions?

Any help is appreciated.

Bob Rafuse
Etec, Inc.

[Bob Rafuse]

More info:

> If have no breakpoint, but I check "Execute -> Break on First Step" in the
> Sequence Editor and press F5, TestStand stops, but NOT on the first step
in
> my process model's Setup step group, as I would expect. Instead it
> curiously stops on something like to 20th step in the Setup step group.
It
> always stops on the same wrong step. There is no branching before this
> step. This "wrong step" is set to Normal Run Mode and has no break point.
> I am at a loss to understand why TestStand is stopping on this step and
not
> my first step.

After further experimentation, I realized it doesn't stop on the 20th step
itself. The 20th step of my Setup step group is a sequence call to a
callback sequence defined in the process model. This callback sequence

calls a sequence in another sequence file. This external sequence has one
step. This is the step its actually stopping on (the step and the sequence
are named the same and this caused me to accidentally think it was stopping
on the sequence call).

So this is even more curious. When "Execute -> Break on First Step" is
enabled, instead of stopping on the wrong step in my Setup step group, it
appears as though TestStand is pausing on a step in a subsequcen call from
the 20th step in my Setup step group.

Bob.

[Bob Rafuse]

Some of my problem may be due to not understanding how "Execute -> Break on
First Step" is actually supposed to work.

When "Execute -> Break on First Step" is enabled, should execution break on
the first step in the process model or on the first step of the client
sequence file?

If in the process model, should it break on the first step in the entry
point Setup step group or the first step in the entry point Main step group?

If in the client sequence file, should it break on the first step of the
MainSequence Setup step group or on the first step of the MainSequence Main
step group?

Bob Rafuse
Etec, Inc.

[Ryan Ramcharan]

Hi Bob,

Do you have the "Allow Tracing into Setup/Cleanup" and "Trace into Entry Points" options enabled? These can be found from Configure>>Station Options and selecting the Execution tab. In addition to this, open the model file you are using in the sequence editor. Select "All Sequences" from the view ring. Right click on the entry point you are using and select properties. Click on the Model tab and note the selections at the bottom of this window. What options do you have selected? This may be one of the problems. Let me know what happens.

[Bob Rafuse]

"Bob Muppets" wrote in message
news:50650000000500000062620000-1012609683000@exchange.ni.com...
> Hi Bob,
>
> Do you have the "Allow Tracing into Setup/Cleanup" and "Trace into
> Entry Points" options enabled? These can be found from
> Configure>>Station Options and selecting the Execution tab. In
> addition to this, open the model file you are using in the sequence
> editor. Select "All Sequences" from the view ring. Right click on
> the entry point you are using and select properties. Click on the
> Model tab and note the selections at the bottom of this window. What
> options do you have selected? This may be one of the problems. Let
> me know what happens.

Bob,
Turns out I had three problems:

First, as you suggest, I did not have "Allow Tracing into Setup/Cleanup" or
"Trace into Entry Points" options enabled.

Second, my process model called sequences in another sequence file. This
other sequence file was not marked as a "Model" sequence file, but as a
"Normal" sequence file. I assume that "Break at First Step" stops by default
on the first "Normal" sequence file step it encounters. This jives with what
I saw...

Given this, the behavior I'm seeing from "Break at First Step" makes perfect
sense and does not explain why some of the my steps appear to not be getting
called sometimes.

My third problem... by adding trace statements to my DLLs, I found that some
of my steps actually were NOT getting called some of the times, even though
subsequence steps in the sequence were called. Given that the first two
problems above explained the "Break at First Step" behavior I was seeing, I
assumed my problem was no longer related to TestStand step sequencing.
Running disk utilities on the hard disk revealed corruption in the TestStand
and Measurement Studio folders (as well as some others not related to this
issue). I'm not sure what caused the corruption, but
uninstalling/reinstalling TestStand and Measurement Studio solved that
problem.

Thanks for your help,


Bob.