NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Enforcing only one execution at a time

Solved!
Go to solution

What I'm trying to accomplish:  Enforcing that only one execution can be running at a time.  

 

Is there a TestStand setting that I'm not finding that would allow this?  

 

As a workaround, I would do something along the lines of greying out the run buttons in the OI at the begining of the Process Model and enable them at the end. 


Thanks,

Seth

0 Kudos
Message 1 of 14
(4,810 Views)

Using the Application Manager control, you can get a list of the executions. From here, you can check NumRunning.

 

NumberOfExecutions.png

 

From the help:

Count = Returns the number of items in the collection.

NumIncomplete =Returns the number of incomplete executions in the collection, which is the sum of paused and running executions.

NumPaused = Returns the number of paused executions in the collection.

NumRunning = Returns the number of running executions. Paused executions are not considered to be running.

Certified-LabVIEW-Architect_rgb.jpgCertified_TestStand_Architect_rgb.jpg


"I won't be wronged. I won't be insulted. I won't be laid a-hand on. I don't do these things to other people, and I require the same from them." John Bernard Books

0 Kudos
Message 2 of 14
(4,802 Views)

In an OI you could customize it to handle the start and end execution UI Messages and to dim commands as desired when an execution is running. Keep in mind many tool menu items also create executions. Also load and unload callbacks in sequence files create executions. So you might want to allow those, just not user initiated ones.

 

-Doug

0 Kudos
Message 3 of 14
(4,779 Views)

Thanks for the responses.  

 

 

I'm aware that there are other executions going on for things like SequenceFileLoad/Unload, but I'm looking to limit Process Model Entry Points, which seem like a special execution, even if it might not be that different from other executions.

 

Though from what it sounds like, there is no option for the TestStand Engine to limit that, correct?

 

I'll have to figure out if the best place is in the OI or the process model for my application.

0 Kudos
Message 4 of 14
(4,700 Views)

If you come up with a good solution on that issue, i would be interested in knowing what you did !

0 Kudos
Message 5 of 14
(4,636 Views)

So what I ended up doing is create a Boolean variablein FileGlobals for the ProcessModel, and had the Execution Entry Point sequence check for the boolean when it was run.  

 

Single Execution.JPG

 

If the Boolean is false, then the test runs as normal.  If it was true, then it pops up a message telling the user what happened.

And as you can see from the screenshot, the test running starts and ends with setting and clearing the boolean.

 

There are two caveats I found with this method:

1. You basically cannot use the Setup and Cleanup sections of the Execution Entry Point.  This is because you can't have an if statement span the sections.  You can use Preconditions or 2 more If statements to accomplish this, but you would end up in possible race conditions.  If I'm mistaken about this, please let me know, so I can improve my code.

2. You need to remember to set the Sequence File Properties > Sequence File Globals  to  "All Executions Share the Same File Globals".  Otherwise, it won't work.

 

Hope that helps,

Seth

0 Kudos
Message 6 of 14
(4,343 Views)

Maybe you can use a boolean which is set to True as soon as possible in the Execution Entry Point sequence (beginning of the setup).

And set it to False at the end of the sequence (cleanup).

 

But don't test it in the sequence.

Edit the Execution Entry Point sequence and open the Model tab, and use the Entry Point Enabled Expression to test the boolean value.

 

If the boolean is true (= an execution is running), the Execution Entry Point is disabled.

If the boolean is false, the Execution Entry Point is enabled.

 

Hope that helps,

Bruno

0 Kudos
Message 7 of 14
(4,281 Views)

Bruno,

 

That's a good suggestion, and playing around with hard coding the boolean has the results I would want both in Sequence Editor and in my UI.

 

However, I ran into a hiccup.  I used "FileGlobals.TestRunning" directly, and when I'm in the client file, it seems to be looking for the variable in the client file itself.  One solution would be to move the boolean into StationGlobals, but I would rather not do that because I generally like to keep the scope of variables as limited as is necessary.

 

Do you have any ideas on that?

 

Thanks,
Seth

0 Kudos
Message 8 of 14
(4,258 Views)

If "FileGlobals.TestRunning" is used in the Process Model there is no problem. --> It is the scope defined for the variable and that's what you said : " I generally like to keep the scope of variables as limited as is necessary."

 

But if you want to use the variable in the client file, the variable is out of scope.

 

If you always run the sequence with this ProcessModel, you can access the variable with an expression like "RunState.root.FileGlobals.TestRunning".

But I think it's quite tricky to use it in a client file.

 

You should still consider to use a StationGlobals in order to enlarge the scope of the variable --> You can use it in all client files you want.

 

Bruno

0 Kudos
Message 9 of 14
(4,247 Views)

So the problem is that I'm not certain what variables and things are available under RunState, and how to get to the FileGlobals.

 

I tried putting in "RunState.Root.FileGlobals.TestRunning" and got this error:

Root.JPG

Now, this error doesn't show up if I have the ProcessModel open and selected (as in, that's the sequence file that Sequence Editor is currently showing).   But this error does show up as soon as I click the tab for the client file.  

 

I truthfully don't need access to that variable from the client file, but because of that behavior, I'm assuming the evaluation of the variable is done starting at a different place when I switch from viewing the ProcessModel to the client file.  

 

As to the StationGlobals, I would still rather not put the boolean in there, because that would give the client files access to that variable, when they shouldn't have it.

 

0 Kudos
Message 10 of 14
(4,228 Views)