When to Run a Sequence in a New Execution versus in a New Thread

Publish Date: Dec 18, 2017 | 6 Ratings | 4.50 out of 5 | Print

Overview

When running a sequence asynchronously in TestStand you have two options.

  • Run the sequence in a new execution object.
  • Run the sequence in a new thread.
    The remainder of this document compares these options.

    Table of Contents

    1. Running a Sequence in a New Execution vs. a New Thread
    2. Reasons Why You Would Want to run a Sequence in a New Execution
    3. Collecting Result Information from a Sequence Run in a New Execution or in a New Thread
    4. Related Resources

    1. Running a Sequence in a New Execution vs. a New Thread

    New Execution

    When you run a sequence in a new execution, TestStand creates a brand new Execution object. Inside the Execution object a thread is created in order to run the sequence. If the execution only has one thread, this thread is usually the foreground thread. The foreground thread is the thread that the sequence editor or run-time operator interface displays as active for the execution. Along with a foreground thread, the Execution object has an Execution window, a report object, and it can also contain more threads. Thus, you can have a unique report for each execution.

    In addition, you can access any method or property in the Execution class, such as BreakOnEntry and DisableResults. However the methods and properties of the Execution object class apply to every thread inside this execution. Therefore a call such as Execution.Break()will effectively pause all threads running inside the Execution object.

    When your run a sequence in a new execution, the sequence can be run with an execution entry point of a process model, such as Test UUTs or Single Pass. Thus, running your sequence in this manner is similar to selecting Execute»TestUUTs or Execute»Single Pass when your Sequence File window is active.


    New Thread

    When you run a sequence in a new thread you cannot run the sequence with a process model entry point. In this case TestStand creates a thread inside the current Execution object. Thus, threads are elements of an execution. You can obtain a thread of an execution by calling the Execution.GetThread method. You can have several threads running in a single Execution object. Threads do not have report objects or Execution windows therefore, you can retain the result information from a thread in the current execution only.

    In both instances, new thread and new execution, you achieve parallel execution of your sequence.

    Back to Top

    2. Reasons Why You Would Want to run a Sequence in a New Execution


    • If you want to run your sequence with a particular process model entry point such as, TestUUTs or Singles Pass; or if you want to use a particular process model file.
    • If you want your sequence to have its own report object or report file.
    • If you want to have autonomy between your sequences. In other words, if an execution hangs, then all threads within that execution object will hang as well. Launching a new execution ensures that if one execution hangs, the other may still keep running.
    • If you are doing MultiUUT testing. If you are conducting multiUUT testing, you can use the Parallel and Batch process models that ship with TestStand, these models automatically run several instances of a sequence file, each in a new execution.
    • Remote executions automatically run a sequence in a new execution.

      Back to Top

      3. Collecting Result Information from a Sequence Run in a New Execution or in a New Thread

    Ensure the settings of the Sequence call step are configured to not wait for the thread or execution object to complete. Instead, you must manually wait for the completion of the execution or thread object by including a Wait step in your sequence. The results of the execution or thread will be collected at the Wait step and inserted into the report at the step's relative location.

    If you are running a sequence in a new thread and wish to collect the results of the sequence, you must disable the Automatically Wait for the Thread to Complete at the End of the Current Sequence option. Figure 1-1 shows the "Automatically Wait for the Thread to Complete at the End of the Current Sequence" option disabled. You may need to store the ActiveX reference to the thread depending on how you will configure your wait step (discussed later). To do this enter the property path of the variable (type ActiveX reference) that will store the reference to the new thread into the "Store an ActiveX reference to the New Thread in:" control.

    Figure 1-1. Thread Settings Dialog Box


    If you are running a sequence in a new execution and wish to collect the results of the sequence, you must select the Do not wait option within the Wait for Execution to Complete control. Figure 1-2 shows the Do not wait option selected. You may need to store the ActiveX reference to the execution depending on how you will configure your wait step (discussed later). To do this enter the property path of the variable (type ActiveX reference) that will store the reference to the new execution into the "Store an ActiveX reference to the New Execution in:" control.

    Figure 1-2. Execution Settings Dialog Box


    Once you have set the options above, you must insert a Wait step and configure it wait on the thread or execution whose results you want to collect. After inserting the Wait step, right-click on the step and select Configure Wait from the context menu. You will then need to select whether you will be waiting on an execution or a thread using the "Wait for:" control. There are two different ways in which you can specify the thread or execution to wait on. The first involves directly selecting the sequence call step that is configured to run a sequence in a new execution/thread using the "Specify by Sequence Call" control. The sequence call must be located in the current sequence in order for this option to work. The second method involves using an ActiveX reference to specify the execution/thread to wait on. If you select this option, then you must store an ActiveX reference to the new execution/thread as mentioned above. You may then specify the execution/thread to wait on by entering the variable that holds this reference into the "Specify by ActiveX Reference to the Thread/Execution" control. Note that the options will change depending on the type of object you have selected to wait for. Figure 1-3 shows the Wait Step Configuration dialog, that is configured to wait on thread launched by a sequence call step.

    Figure 1-3. Wait Step Configuration Dialog


    Figure 1-4 shows the Wait step at the end of the MainSequence. Here we run a sequence in a new thread and explicitly wait for the thread to finish by adding the Wait step at the end of current sequence. When execution flow reaches this Wait step, TestStand will automatically collect the result information from the CPU sequence call and insert it at the end of the report of the calling sequence.

    Figure 1-4. Sequence with Wait Step

    Back to Top

    4. Related Resources

     

    Back to Top

    Bookmark & Share


    Ratings

    Rate this document

    Answered Your Question?
    Yes No

    Submit