Property path to current step being executed

[david_jenkinson]

Hello,
I am seeing a "error accessing item" for a step property path, only when the step lies in a sequence which is a subsequence call.  When these step properties are access from the top level sequence (one which is open when single pass is initiated), then I do not get the error.  They are identical steps, copy/pasted.  The code module of the step is actually labview, writing values to teststand using the "set property value" tool.  The property path I am using is:

ThisContext.RunState.Sequence.Main["<Step Name>"].<Step Property>

When executing the step from a subsequence called from the top level sequence, I can put a breakpoint on the step, right-click and browse to the property of the step, and copy/paste the above path.  So the property does seem to exist regardless of whether it is in the top level or a subsequence.  When breakpointing in labvew on the error, I can simulaneously browse the property above that I am getting the error on also.  I see that it does exist, but yet I get an error. 
I guess my question is, is there a property path which can always reliably reference the current step, no matter where it is in the sequence heirarchy?  I have browsed and all I can find is the property path above.

Thanks
David Jenkinson

[RayFarmer]

Hi David,

If its the currently executing Step properties you are after to use in the Code Module, then use

ThisContext.RunState.Step

The error message you are seeing should identify the Property you are trying to access is this correct item?

Regards

Ray Farmer

[david_jenkinson]

Hi Ray,

I get an error when trying to access  ThisContext.RunState.Step, using "set property" wired with sequence context in my vi.  I can put a breakpoint in the sequence, and browse the variables tree, but do not see the property  "ThisContext.RunState.Step".  I do see ThisContext.RunState.Main.Step, but that references the step in the calling sequence.  Is there perhaps another property somewhere?

Dave

[david_jenkinson]

I think I may  have a little bit of clue what is going on.  I am trying to write data back to teststand from a vi, which is a queued state machine, executing waiting for commands while teststand is executing.  It is launched in the parent sequence, with the sequence context of the parent sequence passed in.  This is the sequence context which is referenced in the code of labview vi.  So when I reference this sequence context, while executing a step that is in a subsequence, sequence context might still reflect the parent sequence, and not the subsequence?  If so, how do I use the parent sequences "sequence context" to get at my the currently executing subsequences context?  Or is there a property which always holds the currently executing "step" context, no matter where you are querying from?

Thanks

Dave

[RayFarmer]

Hi David,

Checkout the following example, this may help you.

http://zone.ni.com/devzone/cda/epd/p/id/5838

Regards

Ray Farmer

[Eric_B. · Accepted solution]

Hi Dave,

After speaking with a co-worker of mine, we came up with a way to get the current sequence context in your code module.  Basically, we have the sequence context from when the code module was called initially.  Then you can use the sequence context to get the execution, which you can use to get the current thread.  From that, you can get the sequence context from that thread and have access to whatever you need from there.  We created an example program that has a sequence that launches a VI that just runs a while loop and shows the current sequence name.  Here is a screenshot of the code module:

Message Edited by Eric B. on 05-29-2009 02:31 PM

[david_jenkinson]

Ray,

This is very interesting and pertinent to a couple of our projects.  Unfortunately our company blocks ftp access, so I can't get at the example file linked to in this article.  Can you possible post that to this forum?  I'd appreciate it.  thanks

[david_jenkinson]

Eric,

Your solution works great.  I knew there had to be a way, I just couldn't find the trick.  Thanks

Dave