04-28-2016 02:05 PM
I have an alternate idea that I think might work.
Basically, instead of using a FileGlobal, I create and use a variable in the Engine.TemporaryGlobals object with the following expression:
(Start of the entry point):
(End of the entry point):
The first expression creates the Boolean value if it does not exist and sets it to true, and the second expression sets it to False. Then I used this expression as the Entry Point Enabled expression:
This expression checks to make sure the temporary global exists; if so, it only enables the entry point if TestRunning is false. If the global doesn't exist, the entry point is enabled.
This expression works on my system, with oe caveat: If you abort an execution, the global variable will not be cleared, and the expression will cause the entry point to not be re-enabled. In a custom UI, you could handle an event to reset the global, but you won't be able to do that in the Sequence Editor. Restarting the Sequence Editor would be one way to reset the global, but another option would be to create a Tools menu item that a user could click to reset the variable. I'll leave it up to you how you want to solve that issue (if it's even a concern for you).
Hope this helps!
04-29-2016 01:58 AM
I'm using the Execution Entry Point enable expression with a StationGlobals and it works.
I thought it would be simple to use it with a FileGlobals... but you are right : It doesn't work. I tried with the boolean in the ProcessModel and with the boolean in the client file but none works.
I don't understand how TestStand evaluates this expression. What is the context used ? I don't find any information from the help file. Maybe there is a mistake because one of the 2 solutions should work.
I tried the workaround proposed by Daniel and it works.
Thank you Daniel.
04-29-2016 11:58 AM
Hi Daniel and bruno,
Thanks for the info. The TemporaryGlobals is a good solution for this. Here are a couple things observations from this:
1. TemporaryGlobals is not visibly accessible to the ClientModel author. While they technically have access to this variable, if they don't open up the ProcessModel, they will never know it's there.
2. Restarting the program will clear the variable, which is an advantage, but I'm unsure if there are other situations where the variable might be accidentally cleared or deleted.
3. Running multiple instances of the engine (as in multiple instances of UIs) will allow for multiple executions. I was hoping this would be solved by the "All Executions Share the Same File Globals", but FileGlobals is not working. This isn't as big of a problem for me as my use case will not really be allowing for multiple instances of the UI.
I agree with bruno that knowing the context for Execution Entry Point Enable would really be helpful. Could this please be included in the help file?
05-13-2016 09:18 AM
It works for me, perfectly... no real drawbacks...