NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Where does logic for flow control step types live?

Solved!
Go to solution

For most step types, the step type's behavior is determined entirely by the configuration of the step--i.e., properties that can be configured in the type window, such as step properties, substeps, etc.  But as far as I can tell, the behavior of the flow control step types (e.g., jumping back to the beginning of a loop block after an End step) doesn't seem to be defined by a substep, flag, attribute, or any other configuration item--it seems to be something inherent to the TestStand engine.

 

If this is the case, how does the TestStand engine know to provide appropriate functionality for a particular flow control step type?  Does it execute the appropriate logic based on the name of the step type?  I suspect this may be the case, because if I create new step types by copying the ForEach and End step types without making any modifications other than specifying the new names for the block start and end step types, the new step types do not repeat loops as expected.

 

Can someone clear this up for me?  Do the flow control step types break the model of completely defining functionality by editing the step type, or am I just not finding the relevant configuration item(s)?  I was trying to create a new End step type that allows a pre expression, but it broke the looping functionality of my (new) ForEach step type.  Is it possible to do what I want?

0 Kudos
Message 1 of 8
(5,953 Views)

Hello jsiegel,

 

I understood that you need iterate a group of steps, if it is so, the step that you'll need is the For Step. The For Each Step is a step used for defining  a block of steps that execute once for each element in an array.

 

Carmen C.

 

0 Kudos
Message 2 of 8
(5,927 Views)
Solution
Accepted by topic author jsiegel

You are right that the engine treats flow control steps specially. It looks at the step type name. If you want the same runtime behavior, you must keep the original step type name as a prefix on your step type name, such as NI_Flow_End_CustomizedByMe.

 

Also, check out http://forums.ni.com/t5/NI-TestStand/copy-of-NI-Flow-End-does-not-work/m-p/290170/highlight/true#M88...

 

There is source code that is similar to what the engine does for flow control steps. It was the actual code before it was moved into the engine. It might be a little out of date now. I found it on my machine at C:\Program Files (x86)\National Instruments\TestStand 2010\Components\StepTypes\FlowControl\

Message 3 of 8
(5,925 Views)

Thanks for your response, James.  I understand what is happening now.  But what is the reason for having the the flow logic in the engine itself and not as part of a substep or some other step configuration or flag?  This is very inconsistent with all other step types, and with the entire concept of a step type in general.

 

So the C++ flow control code you mention (which is also in the TS 2013 directory) is the source code for substeps of the flow control step types for earlier versions of TestStand, and then was later moved into the engine?  If anything, I would have thought that early versions of the flow control step type logic would have been in the engine until later versions were able to add the appropriate new properties/flags/etc. to allow the code to be moved into the step types themselves.  What is the reason for taking the logic out of the step types and moving them into the engine?

 

0 Kudos
Message 4 of 8
(5,916 Views)

I think it was moved into the engine to maximize performance. Since these are primitives of TestStand itself and used frequently we want them to be as fast as possible. You can make custom step types which still get the flow control behavior from the engine code as long as you prefix the name with the name of the corresponding flow control step type.

 

-Doug

Message 5 of 8
(5,900 Views)

I guess it's reasonable to have that logic in the engine for speed purposes, but I don't like the fact that it is based on the name of the step type.  Wouldn't it be better to have some sort of step-type flag along the lines of "ImplementsForEachFlowBehavior"?  This would make it more consistent with other step type behavior too.  And then I can name my custom step type anything I want, like "My_Flow_ForEach" (removing the "NI" from the name and keeping it consistent with the nameing of my other custom types) instead of something like "NI_Flow_ForEach_My".  At first glance, this looks like a NI built-in type and not a custom type I created.

 

Also, do all the actions performed by the engine occur when the post-step substep calls should occur (presumably after any existing post-step substeps), as described in the documentation for step execution?  If not, is there any documenation for when they do occur?  Is it safe to assume that all other step actions occur as they would in any other step type, or are some actions overridden/ignored/reordered?

Message 6 of 8
(5,894 Views)

The special behavior for flow control step types (based on step type name prefix) is executed right before the postsubsteps of the step type. No other actions of the step type should be affected (unless a runtime error occurs in the flow control action of course).

 

-Doug

0 Kudos
Message 7 of 8
(5,859 Views)

Thanks - this discussion was exactly about what drove me mad yesterday.

Hopefully it saves my day today...

 

Attaching functionality to a name? Really? You (NI) cannot be serious!

Anyway- whatever the reason for the inconsistency is: It would be great to have the behaviour better documented.

Message 8 of 8
(4,651 Views)