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

[Mikef]

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

[Scott_Richardson]

Mike -
There is no way to disable tracing for an entire sequence file. The caller must determine if tracing should occur. So for a Sequence Call step you can open the the Step Properties dialog box and change the Sequence Call Trace Setting control on the Run Options tab of to "Disable tracing in sequence".

Scott Richardson (NI)

[RayFarmer]

Hi Mikef,

I have attached a TS3.0 example which will switch off the tracing before a subsequence is called and restores the tracing on return. I change the state of RunState.Tracing in the pre-expression of the subsequence call step.

Regards
Ray Farmer

[Mikef]

Ray,

I'm a bit puzzled. I understand what you did in the example that you sent to me, Storing the tracing, then turning it off, running the step and then restoring the tracing.

However, Scott suggested setting the Run Options Tracing to Off, but I don't find that option on my Custom steps (which is where I would go to enable or disable tracing for any new steps that I create. (Yes, I could add the code you suggested, but the above options seems cleaner.)

Why isn't the option available on the custom steps?

Mike

[Scott_Richardson]

Mike -
When you say that you have custom steps calling the library sequences, are you talking about a custom step type? How are these steps calling your sequences. I assume that the steps are using the sequence call adapter in some way. Can you please clarify?

Scott Richardson (NI)

[Mikef]

Scott,
Correct, Custom Step Types (in "MyTypes.ini"). I have created custom steps that make calls to subsequences in my "Library" sequence file.

When I look at the configuration for the custom step types for the subsequence calls, the "Default Run Options" settings tab for the "Sequence Call Trace Setting" does not exist.

Mike

[RayFarmer]

Hi,

I believe this only becomes available when you insert your steptype into the sequence as a step. Then you can follow Scot's suggestion.

What you could do setup the pre and post expression as I suggested. Instead of using a local variable to hold the temp setting of tracing and a boolean property tracing to your steptype.

Regards
Ray Farmer

[Scott_Richardson]

Mike -
To recap, you are using a custom step type to define that step instances of the step type use the Sequence Call adapter.

To change the default tracing value for the step type and any steps in sequence files that are currently loaded in the sequence editor, you can:

1) Turn on hidden properties in Station Options.
2) View the subproperties of the type.
3) Find the "TS.SData.Trace property" in the type.
4) Change the value from "Don't Change" to "Off" and select the "Apply Value to All Loaded Instances of the Type".

This will update the type's default value and change any instance's value for this property.

By the way, why are you using a custom step type instead of using NI's Sequence Call step type?
Are you just doing this so that the insert list has a list of the "library steps" that your users would like to insert?

Scott Richardson (NI)

[Mikef]

Ray,

I don't understand your comment:
"Instead of using a local variable to hold the temp setting of tracing and a boolean property tracing to your steptype."

Your Pre and Post Expressions do require a temp variable.

It doesn't seem practical to add the Pre and Post Expression in the Custom Step Types because it would require that I declare a "Temporary Trace" variable for EVERY sequence that I use the steps in.

Mike

[Mikef]

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.

Write:(FG.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