Tracing into PostStep-Callback

[CKone]

Hello,

I use the EngineCallback SequenceFilePostStep to write data from each step in a file. The problem is that the callback contains a SequenceCall. If I trace with "Step into" (F8) through the sequence, I trace every time in the Sequence called from the SequenceCall in the Callback, although the StationOption "Allow Tracing into Pre-/Post Step-Callbacks" is disabled. That isn't very nice and in my opinion not right, because the StationOption only effects to Pre-/PostStep-Callbacks without SequenceCalls, or is it a correct  behavior?
Thanks in advance....

Regards
Carsten

I added a simple sequence to show the behavior.

[AllenP]

What you are seeing is normal behavior.  During normal execution, notice that you never see the PreStepCallback execute.  It only happens when you are debugging, set a breakpoint, and step into the code.  Tracing only refers to what is visible during a normal execution without debugging.

Hope this helps!

Allen P.

NI

[CKone]

Hi Allen,

thank you for the reply. Nevertheless I don't quite understand. The SequenceCall is part of the Pre/PostStep Callback and therefore, in my opinion, it should not be visible during a normal execution, too. Is there a mechanism (flag or something like that) to give the called sequence from the callback the characteristics that it isn't a normal sequence and therefore it should not be visible in tracing mode?

Regards

Carsten

[AllenP]

Tracing is different than debugging.  As far as I can tell, whenever you leave the sequence alone and run an execution, you never see the execution of the subsequence or the callback.  If you enable tracing through Station Options, you will notice the difference in behavior.

However, if you are debugging code, you will see a different behavior.  You will always have full control of where to debug, and can use this by stepping into, stepping out of, and stepping over segments of code.

If you are noticing something different than what I am describing, please let me know.

Allen P.

NI

[CKone]

ok now I understand the difference between debugging and tracing. Maybe I was a little bit incautious with the word 'trace' in my problem description, too. But I think we come closer to the point of my problem. You wrote I have full control where to debug with the functions Step Into (F8), Step Over (F10) and so on. But I think it is only partly correct. You can see it in the example sequence "Tracing into PostStep-Callback. Set a Breakpoint at the first Step "MainStep1" and then StepInto F8) through the MainSequence. In my opinion the next step should be "MainStep2". But the next step is "Tracing into PostStep-Callback" which is called from a SequenceCall inside the PostStep-Callback. The PostCallback itself (Label "PostStep-Callback and SequenceCall "SubSequence") is not visible during debugging code (I would like to have that nothing is visible during debugging which has something to do with the PostStep-Callback).

Do you think that is a normal behavior, or I still think in a wrong way? 

Regards

Carsten

[AllenP]

Carsten,

The debugging of an execution does not care what tracing options you have selected.  The next step that executes after the execution of your code module is the Post-Step Callback.  Tracing is a different concept than debugging.  Even if you have tracing completely disabled, if you set a breakpoint, the code will stop at that point and give you full access to the sequence (including all engine callbacks).

Allen P.

NI

[Vincent Hotchamps]

This is a common problem encountered by a lot of TestStand users. Test operators generally need to place breakpoints in their sequences in order to test, investigate or repair a d.u.t but they don't want to see the details of the sequences (pre-substeps, post-substeps, process models steps, etc...). The only solution available now is to build a custom runtime operator interface and with the low level functions of the Teststand API catch and filter the steps that will be displayed to the operator. This is a complicated task but there is no other solutions now because TestStand don't offer any standard mechanism to solve it.

[Scott_Richardson]

Carsten -

At first pass review, I do think that TestStand could and should try to prevent the step into that you are seeing.  I will write an internal report on this behavior to get looked at for a future release.

[CKone]

@All
ok,  thank you for your trouble.
@Scott
It is good to know that the behavior is on your "ToDo-List" 😉
I am anxious to see future releases.

Carsten