Accessing properties like "Runstate.LoopIndex" in sub-sequences...

[Jed_Davidow]

OK.  I know you can grab individual properties and pass them as parameters (which is what I am doing), but I was wondering how I might do it more elegantly...

I have a Top level sequence that calls a Test routine, and I set the Looping property of that routine.  This in turn calls a sequnce "Report" that passes the loop status back to the Interface.

I tries to pass the RunState object down to my sub-sequence.  But there is no "AsRunState" function, so I can't seem to access it's properties.

Looks like I am passing down the 4-5 properties individually.

Anyway, is there a way to do this? 

[Captain_Jack]

Hi Jed,

Not sure what you mean by elegant. Passing values via parameters is considered to be good practice. Is there some specific reason that you don't want to pass the input values as parameters?

-Jack

[Jed_Davidow]

Not to argue style points with you (because you are right about parameters!) but I would like to know if this is possible.

For example, I wrote a sequence that calls postUIMessageEx and sends loop info to the GUI, as well as passing the some current hardware states for display.

I want to call this sequence whenever the HW state is read.  This means it's buried 2 or 3 sequences down from the top-level sequence that's being called with the loop property.

I tried to pass the top level Runstate down as a reference so I could peer at the loop indexes, but there is no way to cast it to a Runstate.  MAybe I need "ThisContext"?

Am I thinking about the object incorrectly?

[Captain_Jack · Accepted solution]

Well, in that case there are a couple options.

You could use RunState.Caller.Runstate.Caller.Runstate.LoopIndex, where you reference "Runstate.Caller" for as many levels back up the list you need to go. This is somewhat kludgey if you don't know how many levels you need to traverse.

If you know that you're starting from the MainSequence, then Runstate.Main.LoopIndex will give you what you want - you should be able to see almost everything in the runtime of the MainSequence from here.

Passing ThisContext as a parameter also worked - I experimented with both methods and got the same results for the LoopIndex value.

The above being possible, it remains to be seen whether or not this is a good idea to implement... use at your own risk!

Is this what you're looking for?

-Jack

[Jed_Davidow]

YES!  Thank you.

Question:  RunState.Main.LoopIndex will give me the current index for whatever loop happens to be running at the Main level at that time?  Does it reset to zero as soon as that loop is over, or only when it encounters another loop?

While I've got you on the line, this is (hopefully) my last question...

During that loop, I was using Runstate.LoopNumPassed and Runstate.LoopNumFailed to pass to my UI.  The problem is that these are not updated until the loop is over, and then it's too late to send these.

Can I retrieve the final values of those properties so that after the loop is done I can update my UI one last time?

[Jed_Davidow]

AND!  Is there a good resource for becoming more familiar with the API, especially some of the more contextual issues?

[Captain_Jack]

OK,

The last one first:

The TestStand help is going to be the best bet for getting information about the API, it does take some digging but once you get a feel for it, it's not too hard to find what you need. At least that plus some judicious searches of the forum!

As for the status of the LoopIndex and Num Passing and Failing Loops, the LoopIndex is reset after the step completes, but the RunState.LoopNumPassed, RunState.LoopNumFailed & RunState.LoopNumIterations appears to be maintained after the current looping step completes and are only reset after another looping step is called.

Not sure how you'd go about doing this outside of the loop, but they are there after the step complete.

-Jack

[Jed_Davidow]

Now that you say this, digging around the API isn't the biggest problem.  It's undertanding all the architecture necessary for customization in general...

Some examples:

• To disable the Report at runtime, you override the Report callback and set the Disable property True.
• To disable the login, you edit the "FrontEndCallbacks.SEQ" and place this in the Public (Users) TS folder (This one is ESPECIALLY unhelpful when dealing with a general development machine Vs an installation)
• To change the names of the GUI buttons handled by the ApplicationMger (in a custome interface), you mess with the language file settings.

I took the TSI&II courses, but this is the kind of "basic" stuff that was not mentioned.