Programmatically get sequence, sub-sequence and step name in LabVIEW

[dsan226]

I have to document the process on how we run tests on devices.  The current TestStand sequences are very “deep” with many sequences, sub-sequences and steps.  The underlying code that drives the DUT’s is written in LabVIEW.

Is there a way to programmatically (in LabVIEW) output the name of the sequence, sub-sequence and steps as TS runs through a routine?

I have to do this for several different sequences for different DUT’s.  I have searched the forums and I can't seem to get RunState.Caller.Step.Name to work using TestStand - GetPropertyValue.vi to work with the sequence context.

[~jiggawax~]

What do you want to output it to?  Ultimately what is your goal here?

Here are several options.  Not sure which one would fit your scenario the best:

1. Use the Sequence File Documentation tool.  Tools>>Sequence File Documentation...  It will output your sequence file in a readable format that you can then give to someone.  However, this does not tell the flow of execution, especially if you have GoTos and/or conditionals everywhere.
2. Use StationCallbacks.seq and put the StationPostStep callback in there.  Every time step completes execution this will trigger and you can grab the information and log it to whatever you'd like.  It also does process model steps so you might want to prefix to ignore those by looking at the type of sequence file.  I've done this before to troubleshoot issues on large systems.  It works great if you know what you are doing.  Also, this doesn't intrude on your automation and can be turned on and off easily by replacing the StationCallbacks.seq file with an empty one.
3. Use SequenceFilePostStep inside of your client sequence file.  Basically the same thing as #2 but only at the sequence level.

You can certainly get everything you need inside of LabVIEW.  The entire API is exposed.  What is triggering your LabVIEW code?  The trick with LabVIEW is that the sequence context is continually changing, especially when you have deep hierarchies.  So for you it is going to depend on where/when/how your underlying LabVIEW code is being called. 

RunState.Caller will return the sequence context of the previous sequence in the stack and not the caller that called the LabVIEw code.  So I'm not sure what you expected out of that?

Maybe a little more explanation will help us get you a better solution?

Cheers,

[dsan226]

Our devices are driven through an existing LabVIEW program, either as a stand-alone or through TestStand.  Within TestStand the settings for a particular test are setup by a custom step and these parameters are fed to a queue in LV which sends the parameters to the appropriate DUT.

We have inserted code into one of the LV VI’s that will record the setup data from the custom step every time it is called from the running sequence in TestStand.  It records various pieces of information about the particular step that is running (ex. parameters, requirements,etc.) into separate text files (hopefully, with what we want as the name of the step) as the filename.  These files will serve twofold: as a requirements verification for our customer and as a way to run a light weight LabVIEW sequencer.

Currently, I can only get the subsequence name to be output even though what was run was a step buried under the subsequence.

Example:

MainSequence (Sequence)

-PwrSupplies_ON(Sub-Sequence)

  - PwrUp_SelfTest(Sub-Sequence)

    - SendTurnOnMsg(Step)

    - Measure_V1(Step)

    - Measure_V2(Step)

  - CommTest(Sub-Sequence)

What we see is when “Measure_V1” is run what is output as a step name is “PwrUp_SelfTest”.  What we want would be something like “PwrSupplies_ON.PwrUp_SelfTest.Measure_V1” to be output as a filename.

I was hoping that RunState.Caller.Step.Name would give me the name of that STEP that was run buried under that subsequence.

Unfortunately, I cannot change the TestStand code but I am able to insert new code into LabVIEW.

(Sorry, I am new to TestStand and my terminology may be incorrect.)

[~jiggawax~]

Sorry, still trying to wrap my head around this because it is such a different way to use TestStand.  I understand your sequence hierarchy and I understand your goal.  How often and specifically where is the VI that is recording the setup data being called?  For example, is it being called in SequenceFilePostStep callback?  Or is it being called asynchronously at the beginning of your test and always running?  What is being passed to the VI that is recording the setup data? 

Are your subsequences in different sequence files?

[dsan226]

Yes, the TestStand implementation we have is not a typical (or optimal) use case.  This is one of the reasons why we are interested in creating a LV sequencer that will take these files generated from the TS sequences and perform the same test. 

The VI that is reading the custom step data and outputting to file (VI#3 in the example below) and is run in a LV loop and generates an output every time a step is performed. StationGlobals are loaded from a custom step that drives the underlying LV code.

Essentially this StationGlobal setup data is what is recorded to file.  The loop runs until the TS custom step pushes an EXIT to the StationGlobals which causes VI#5 to exit the loop.

All sequences are currently in one file.

This example is a simplistic view as to how the underlying LV works, either as a stand-alone or driven by TestStand.

[~jiggawax~]

So apparently you have access to RunState.  The problem I see is that RunState is constantly changing depending on where you are in your execution.  Because you are using Queues this way it doesn't seem that there is any sort of synchronization (correct me if I'm wrong?).  Because of that you can not guarantee the thread that RunState represents.  Or that the RunState you have will even be valid?  What happens when you call RunState.Step.Name?  Does it give you the correct step name?  If so you should be able to call RunState.Sequence.Name.

[dsan226]

I believe the RunState will be valid because when a Step is performed there is typically a value that is returned from the particular DUT.  This almost acts like a blocking mechanism as it waits for the return.

When I run either "RunState.Step.Name" or "RunState.Sequence.Name" from the sequence context reference they both just return an empty string.

[~jiggawax~]

How are you acquiring RunState?  Are you sure it is valid?  It doesn't sound like it is. 

You said earlier that you were able to get the subsequence name.  What are you using to get that?

[dsan226]

I run the Seq. Context into a property node and get the Seq. Ref. and Step Ref.  Then I run these Ref.'s into their own property nodes to get the Seq. Name and the Step Name.

I am running "RunState.Step.Name" or "RunState.Sequence.Name" into "TestStand - Get Property Value.vi" using the Seq. Context to get the return value.  Should I be using a different method to get the RunState parameters?

Thank you for your help!

[~jiggawax~]

So what is populating the Sequence Context initially?  In other words, how are you getting the sequence context from TestStand to LabVIEW?

Every time you call a new sequence in TestStand you get a new sequence context.  Basically, if you watch your stack (your sequence call hierarchy) for each line in the stack you have a different sequence context.  Each sequence context is completely different.  The goal for your application is to make sure that you have the correct sequence context at the right time.  Understanding when and how the sequence context is getting from TestStand to LabVIEW will aid in knowing what you actually have access to at that moment.  So you need to synchronize LabVIEW with the correct sequence context.