• NI Alliance Partner

    Mainline Test & Integration, Inc. is proud to announce that we are... More

  • Diligent Automation

    Our experience has shown that test teams can fall into several pitfalls... More

  • From the Blog

    Check out our blog as we discuss the latest tips/tricks/trends in the... More

Beware of FileGlobals

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.

No Comments Yet.

Leave a Reply

Prove your non-robot existence by filling in the blank: