Changing the Execution Speed in TestStand

Updated Oct 30, 2024

Environment

Software

  • TestStand

  • How can I see the execution steps in TestStand?
  • How can I change the execution speed in TestStand?

If you enable tracing you will be able to see the execution steps. To enable tracing, select Configure»Station Options and click the Execution tab. Enable the Enable Tracing option.

You can control the execution speed only when tracing is enabled. To change execution speed, move the Speed slider control from left to right (see figure below). The execution speed controls how fast (or slow) the TestStand Engine will start executing the next step in a sequence.  If the execution speed is fast, then the TestStand Engine will not wait very long in between each step. Conversely, the TestStand Engine will put a larger delay in between each step if the execution speed is slower. Note that changing the execution speed in the Station Options will affect all sequences running on that test station.
 

You can also programmatically configure the tracing options by changing the values of these properties. Below are the properties and example figures. Engine.StationOptions.TracingEnabled determines whether tracing is enabled.
 

Engine.StationOptions.UIMessageDelay  determines the tracing speed.  The delay is in milliseconds and represents the amount of time to wait for each step. A value of 0 corresponds to the fast setting in the Station Options window, and a value of 1000 corresponds to the slow setting.
 

Modifying these properties can be useful when you want to be sure that a certain sequence is running at a specific speed.  Also, specifying these properties in your sequence ensures that the tracing settings will persist when the sequence is deployed to another system.

Additional Information

Slowing down the execution of the sequence might lead to unexpected errors or behaviors when steps rely on the execution time to function poperly. For example, if a sequence has one step that sends a command to a device and receives the reply message in the subsequent step, it may timeout in the last step because of the large delay between those steps. In this case, the step that waits for the device to reply woud start executing in a moment when the device had sent all the message packages, or a considerable part of them, resulting in a timeout error.