In TestStand, each sequence file has a setting that identifies a corresponding process model. TestStand comes with three default process models (Sequential, Batch, and Parallel) however you can custom home roll your own. A process model itself is a sequence file, however it contains all of the common code needed to run individual sequences and is not specific to any UUT. Think of it like this. Whenever you execute a sequence file, typically the process model sequence file is what executes first. The process model is smart enough to know when it needs to do stuff behind the scenes that you don’t need to worry about (i.e. report generation or database logging) and when it needs to tell the desired sequence file to start executing. In fact, the desired sequence file and the process model file can communicate with one another. It does so via Callbacks.
In TestStand, there are two kinds of Callbacks; Model Callbacks and Engine Callbacks. Callbacks, like process models, are sequences that either execute when certain points of the process model file are reached or when certain events occur in the TestStand Engine. Callback sequences are optional and a lot of times are empty and possess no code. However, you may find yourself at times needing to customize TestStand to your specific needs and Callbacks provide major flexibility when architecting a solution. One way to modify or add code in one of these predefined Callbacks is in a process called overriding the Callback. In this blog post, I am going to introduce you the world of Callbacks by walking you through an existing Callback and then we will override it to demonstrate the flexibility of TestStand.
First I am going to open up TestStand and start a new sequence file. Immediately in the lower left portion of TestStand you will be able to see what current process model file you are working with as shown in Figure 1.
Figure 1
As you can see, I am currently defaulted to use the SequentialModel.seq. I can get into process models in detail in another blog post, but for now lets (meaning me) stay on task and take a look at the process model code. In order to open this file, you can browse your explorer window searching for that specific file or you can simply double-click on the box show in Figure 1 and it will bring it up in the TestStand script editor. I choose to double-click. Now that we have pulled the process model up, take a look at the Sequence window as shown in Figure 2.
Figure 2
See all those sequences with the green boxes next to them? Those sequences are the process model Callbacks that can be overridden in your sequence file. Click on ‘PreUUTLoop’ and take a look at the code. Pretty disappointing huh? Like I said earlier, a lot of these Callback sequences contain no code. TestStand contains these bookmark sequences however to help you, the user, potentially customize or modify process models in a manner that won’t mess a lot of things up. Note that whenever you make a change to the process model, any sequence file that points to that process model file will now behave differently as you have defined. Therefore, sometimes it is best to make the modifications at a higher level and that is where overriding comes in.
Next I want you to scroll the Sequence scroll bar all the way down to the bottom as shown in Figure 3.
Figure 3
Notice the two sequences with the purple boxes next to them? These are actually Engine Callbacks that have already been overridden. How can you even know that you ask? Well right-click on a sequence and select ‘Sequence File Callbacks…”. You should get a window similar to that shown in Figure 4 below.
Figure 4
This window displays all of the current Callbacks that can be overridden. I want you to particularly notice two things. First of all, notice how all the Callbacks are of type ‘Engine’. Why don’t we have any Model Callbacks? The reason is because we are currently in a process model file and having a process model override it’s own Callbacks would be crazy and cause a black hole to open around the Earth. Secondly, notice under the ‘Present’ column that two Callbacks are set to ‘yes’. These happen to be the ones that have been overridden and thus have been modified for this specific process model. Pretty cool stuff! Now click ‘Cancel’ and lets select the ‘PreUUT’ sequence (not the ‘PreUUTLoop’ sequence). You should see code similar to that shown in Figure 5 below.
Figure 5
If you read the comment associated with this sequence it says the following: “Displays a dialog box in which the operator enters the UUTserial number. Override this in client file to change or replace this action.” So pretty straight forward here. If you have ever executed a script using the ‘Test UUTs’ button you would know that this is the code that pops up the dialog box prompting to either enter the Serial Number of the UUT to begin the next test or to stop testing altogether. Now imagine you have a specific UUT in which your manager wants you to add an additional pop-up message telling the operator to make sure all cell phones and electronic devices are turned off prior to beginning a test and that he wants this message to pop up prior to testing every unit.
While you could just add the code in the process model itself; other UUTs may use the same process model and that user message may not even apply or make sense in those cases. So we need to override the PreUUT Callback in our own sequence file. So now lets go back to our new blank sequence file but keep the process model open in another window. Before you add any code lets execute the script to get the general gist of how the ‘PreUUT’ sequence works. Select Execute>>Test UUTs and you should get a popup dialog as shown in Figure 6.
Figure 6
This is the popup dialog that takes in the Serial Number prior to execution. We are still going to want this in our new overridden Callback. Therefore, we need to copy the code from the ‘PreUUT’ sequence file, but before we can do this we need to override it first. Once again, right-click on a sequence and select ‘Sequence File Callbacks…” to get a window similar to that shown in Figure 7.
Figure 7
Now you should be able to see both Engine and Model Callbacks. Also, notice how ‘MainSequence’ itself is a Callback. I just blew your mind! So go ahead and select ‘PreUUT’ and hit the ADD button. Your sequence window should now look like that shown in Figure 8.
Figure 8
So now go ahead and copy the code from the process model to the ‘PreUUT’ Callback. You will have to declare Locals.SerialNumber as a string such that the script doesn’t generate an error. Now insert a ‘Message Popup’ step and configure it as shown in Figure 9 below.
Figure 9
Your Callback should now look like that shown in Figure 10.
Figure 10
Now one last time lets select Execute>>Test UUTs. BAM! Try it out by entering several different serial numbers. You have just overridden your first Callback. Well not really, cause you have been using ‘MainSequence’ for a while now. Either way, pat yourself on the back.
In conclusion, Callbacks are a very powerful tool and add to the flexibility and customizability of TestStand. Knowing when to override versus modifying in the process model is a big decision. Sequence files can override both Engine and Model Callbacks while process models can only override Engine Callbacks. Also note, that when both a sequence file and a process model override the same Engine Callback, the sequence file version takes precedence.