Is there a way to NOT "Trace" into Subsequences?

Question

I have some "library" subsequences which is where most of the execution time is spent. These are what is called by my custom steps. Consequently, when I turn "Tracing" on, it is the execution in the "Library" subsequences that are seen the most, rather than the execution in my top level test.
I'd rather NOT see the tracing go into this "Library" sequence file. Considering that we don't see the tracing into the "ProcessModel", is there a way to tell TestStand NOT to trace into a specific file?
Mike

Answer 1

Scott,
This suggestion doesn't seem to work, because I need to implement it in my Custom Step Types.
In order to answer your question about whey I am using custom step types takes a bit of background.
I am doing Software Testing (as opposed to testing to verify that hardware off the production line is working correctly which is more the norm for TestStand).
I had a test scheme implemented in VB (quite extensive). I was asked to implement the testing using TestStand so that Technicians could write and verify the software. Basically I took some of my low level routines that were in VB and created an Active-X.exe which I call using the Active-X steps in Teststand. These are mostly all created using Custom Step types. Examples of these steps are:
Read a Parameter from the UUT.
Write a value to a Parameter in the UUT.
Set an Analog or Discrete Input Value
Read an Analog or Discrete Output Value
We have also implemented these steps using a "Library" of subsequences that are called by these custom step types. One of the neat features is that we "parse" a "constant" or a "Varaible" value from the Step Name, rather than having to open the "Specify Module" to enter the values (makes creating, reading and maintaining the sequences much faster). The values can be entered either through communications or by manipulating the keys and reading the Display (through comms).
Step examples:
Write:tag_INPUT_TYPE(1)=2 /Display
We write (through the display) the "tag", Instance (in parenthesis) and value (=2) to the UUT. The Tag, Instance and Value are all parsed from the Step Name in the library routine.
WriteFG.sInputTypeTag)((L.Instance))=(L.Value)
In this case, we also Parse to find the
"FG.InputTypeTag" and use the "EVALUATE()" function to get the value of the "FileGlobals.sInputType" from the StepName. Similarly we parse out the "Locals.Instance" and "Locals.Value".
Note that we have a convention to use "L." for Locals, "P." for Parameters, "FG." for FileGlobals and "SG." for StationGlobals to shorten the names on the Steps.
The biggest problem that we have is that everytime we have to change a variable or value, we have to terminate the execution and then restart and get to the test point again. But, that's TestStand I guess...
Mike