With any program you develop it is always considered best practice to limit the scope of your variables. In TestStand, I often come across sequences that violate this principle. Specifically, it is very common for developers to use FileGlobals where they should be using Local variables. In this blog post, I am going to demonstrate a pitfall of FileGlobals that one can encounter when executing a test sequence.
To start out I am going to create two variables; a Local variable creatively called ‘LocalVariable and a FileGlobal variable called ‘FileGlobalVariable’ as shown in the figure below. Note that both variables are strings defaulted to an empty string value (“”).
Figure 1: Variable Creation
Next I am going create a small sequence consisting of two Message Popup boxes and a statement setting the strings to a value other than the default empty string. The configured Message Popup box and simple sequence are shown in the figures below.
Figure 2: Message Box Configuration
Figure 3: Simple Sequence
As you can see, this script simply pops up a Message Box showing the values of my two variables, sets them to something else, and pops up a second Message Box to confirm that they have indeed changed. The desired expectation here is that I should expect my two variables to be set to empty strings every time the script reaches the first Message Box and set to something else whenever the second Message Box pops up. As in any script, prior to a sequence actually performing any task, it should be a reasonable assumption that my variables are all set to their initial default values. However, I am going to show you how there actually exists a case in which FileGlobals prevents this from happening.
For this script I am using the SequentialModel.seq process model. As you may or may not be aware of, this process model comes with two entry points; ‘Single Pass’ and ‘Test UUTs’. The ‘Single Pass’ entry point allows the user to run a sequence all the way through one time, generating a test report at the end. This entry point is commonly used in initial script creation. I am first going to execute my script using this entry point and will execute the script two separate times. The figures below are my results.
Figure 4: Single Pass – First Run – Initial
Figure 5: Single Pass – First Run – Final
Figure 6: Single Pass – Second Run – Initial
Figure 7: Single Pass – Second Run – Final
Pretty anti-climatic considering this ran exactly as I had suspected. Whenever I start the second pass both variables were reinitialized and the script ran both times successfully giving me the expected results. Compare this to somebody developing a script in their office who now believes there script is ready to be released to the manufacturing floor. After all, you’ve ran it multiple times and it appears to be very repeatable in behavior.
One interesting twist however is that the manufacturing floor doesn’t use the ‘Single Pass’ entry point. Instead it prefers to use the ‘Test UUTs’ entry point which provides test operators a prompt to enter a serial number of the UUT and doesn’t output a test report until an entire batch has been tested. So let me rerun my script two more times using this entry point and see what I come up with.
Figure 8: Test UUTs – First Run – Initial
Figure 9: Test UUTs – First Run – Final
Figure 10: Test UUTs – Second Run – Initial
Figure 11: Test UUTs – Second Run – Final
The big glaring issue here is shown in Figure 10. Whenever I go to execute my script for a second time the variables are not set to the empty strings as anticipated. In fact, the FileGlobals variable stored the last value it received from the previous run. Imagine the issues something like this could introduce into a script. On top of that, this issue is very hard to debug whenever one encounters it. The natural tendency is to troubleshoot it by taking it offline and executing it via the ‘Single Pass’ entry point; something that would make it very hard to reproduce. Now going back to the manufacturing example, imagine that you officially released your script and and the test operators are experiencing random failures. Mass quantities of donuts would now need to be purchased over the next few weeks in order to repair your status as a reputable engineer.
In conclusion, limit the scope of your variables. FileGlobals should be used sparingly (i.e. for constants). The above example is something that could cause a lot of heartache and could have been easily avoided.