Best Practices for Using TestStand for the Battery Test System

Refer to the topics on this page and the following additional topics while configuring and developing tests in TestStand.

Additionally, follow the naming conventions established in any .vsaliases files in use to define the aliases for the battery test implementation.

Use the Batch Process Model

TestStand includes multiple process models that control how the software handles operations before and after a test sequence. The Battery Test System requires use of the batch process model.

Depending on the purpose of your Engineering PC, you can apply the batch process model to the entire machine or to specific sequences.
Apply the batch process model:
ScopeDescription
Entire development environment Select Configure » Station Options... » Model. Click the Model tab. In the Station Model field, enter BatchModel.seq.
Individual sequence Select Edit » Sequence File Properties.... Click the Advanced tab. Populate the following fields:
  • Model Option: Require Specific Model
  • Model File: BatchModel.seq

Architect for Multi-Socket Tests with a Shared Resource

Many battery test setups involve, or may grow to involve, a shared resource such as an environmental chamber that contains multiple test sockets to test multiple DUTs simultaneously. Follow development guidelines to ensure your Battery Test System implementation is set up to accommodate—or to scale to accommodate—this arrangement.

A shared resource can constitute any peripheral that is shared among two or more DUT sockets.

For example, consider an environmental chamber that contains several sockets to test multiple battery packs in parallel, where the packs are undergoing a simulated drive profile that involves multiple temperature setpoints. In order to minimize test time and to make most efficient use of the chamber, any battery pack that happens to complete operations during the drive profile test at a given temperature setpoint before another pack should wait until all packs are ready to move to the next setpoint; individual DUTs should not be allowed to request a new state from the chamber before all are ready to operate within that new state.

Even if your present-day Battery Test System implementation involves a single socket, you should develop that implementation to account for expansion of your battery testing needs. Developing your implementation to accommodate expansion from the start makes expansion much simpler than having to rearchitect your software later to enable expansion when you need it.

The Battery Test System must make use of the Batch process model in TestStand, and as a result, you have the option to share resources between sockets using certain techniques. To prevent competition among DUTs for shared resources in multi-socket implementations and, for smaller implementations, to enable the simplest path for expansion of your test system, NI strongly recommends developing test sequences that abide by the following guidelines:

Use batch synchronization steps to prevent competition between DUTs for shared resources

A batch synchronization step defines a section of a sequence in which to synchronize multiple threads that belong to one batch. For purposes of the Battery Test System, the batch synchronization step is the mechanism that ensures all sockets complete a given operation and are ready to move on before the shared resource itself moves on to the next phase of the test.

A batch synchronization step comprises an enter step and an exit step. These steps gate changes to the shared resource until each member of the batch—the sockets sharing the resource—reach that point. Configure the enter step as One Thread Only; this setting specifies an operation that applies to the batch as a whole. Search the TestStand User Manual for synchronized sections for more information.

Place this batch synchronization step after the PreUUTLoop and before the PostUUTLoop. You can call batch synchronization from the main sequence whenever you need multiple sockets to coordinate use of a shared resource. If you require synchronization in a test callback, search the TestStand User Manual for batch model callbacks to see the full set of operations to which you can apply synchronization in this manner.

Note Batch synchronization ensures only that all sockets complete an operation before the state of a shared resource is changed; batch synchronization does not guarantee that sockets always operate in a particular order.

Refer to the TestStand User Manual for more information on creating batch synchronization steps.

Print the outcome of batch synchronization steps

To facilitate debugging in multi-socket test setups, include a print strategy, such as including the new setpoints as additional results in an statement step, within the sequence step that implements batch synchronization to ensure that test reports include what the batch synchronization accomplished.

Use TestStand subsequences to facilitate code reuse

A subsequence is a sequence that another sequence calls as a step. Instead of writing individual sequences from scratch, use subsequences to package common functionality together so you can apply it easily across sockets.

You can also include batch synchronization within subsequences to simplify synchronization in your application.

Refer to the TestStand User Manual for more information.

Make use of the aliases defined in the .vsaliases file for the Battery Test System

Before test sequences for DUTs are in development, aliases should have been defined in the .vsaliases in a way that facilitates the use of shared resources that test multiple DUTs. Use these aliases as they have been defined.

Implement Custom Parameters

You can add user-configurable settings to your Battery Test System Web UI implementation by adding parameters in TestStand. User-configurable settings in the Web UI help make your test sequences input-agnostic by removing the need to hard-code values in the sequences themselves.

TestStand itself can configure only certain aspects of custom parameters:

  • Battery Test System supports the TestStand parameter types of string, numeric, and Boolean.
  • You can configure default values for the supported types within TestStand.
  • Further customize your parameters for use in the Web UI using Tools » Edit BTS Test Definition XML for Sequence. For example, you can specify minimum and maximum values in a numeric parameter or a selection of profile files to offer as selection options in a string parameter.

Refer to Test Package XML Conventions for more information about customizing parameters for the Web UI.

Complete the following steps to implement custom parameters for the Battery Test System:

  1. In TestStand, with the MainSequence selected and within the Variables tab in the right rail, add the custom parameters you want to implement under the Parameters section.
    Note Use the string type within TestStand to represent enums or profile parameters you intend to implement.
  2. Create or edit a .testdef file that incorporates your custom parameters with Tools » Edit BTS Test Definition XML for Sequence.
  3. Further customize your parameters for use in the Web UI using Tools » Edit BTS Test Definition XML for Sequence. For example, you can specify minimum and maximum values in a numeric parameter or a selection of profile files to offer as selection options in a string parameter.
    Note Refer to Test Package XML Conventions for more information on conventions for .testdef files.
  4. Within TestStand, add a BTS Update Parameters for Automated Testing step as the first step of the Setup section of the MainSequence of your test.
    Adding this Action step is required to update your custom parameters with parameter values that are configured at runtime.
You can now surface end user–configurable parameters for the Battery Test System through the Battery Test System Web UI.

Setting Decimation When Data Logging

You can set the decimation of data logged from the Battery Test System programmatically through TestStand. Altering the decimation allows you to collect less data during periods of the test during which less valuable data would be generated.

The decimation value is the divisor for the proportion of collected data samples the logger writes to logfiles. For example, decimation of 1 means all collected data samples are logged; decimation of 5 means one of every five collected data samples is logged.

Complete the following steps to control the decimation of data logged from the Battery Test System into a log file channel group named Test Station:

  1. Add a Read/Write Channels step to your test sequence.
  2. For the CHANNEL entry, provide the following:
    "Custom Devices/Embedded Data Logger/File %SOCKET%/TestStation/Decimation"
  3. Set the ACTION for the step to Write.
  4. Define the decimation value for the step.
The change in decimation value takes effect the next time a new logfile is created. For finer control, close the open logfile before changing the decimation, then open a new logfile. You can control closing and opening log files using the Embedded Data Logger File Command channel.

Using Triggers to Move Log Files to SystemLink

Completed log files move to SystemLink while a test sequence is running in TestStand. When a test sequence completes, use triggers to ensure logging has stopped and all log files associated with the test are moved to SystemLink.

In the Cleanup section of the TestStand test sequence, use the VeriStand Write Channel custom step to set the value of the Trigger channels, ensuring all log files associated with a test are moved to SystemLink.
Figure 20. TestStand Sequence Cleanup Section


Waits are inserted in between the different triggers to ensure files are moved from one stage to the next before beginning the next move sequence. Wait times are dependent on the anticipated log file count and sizes.

If the log files are large and the network speed is unpredictable, you can use the SystemLink File Transferring channel to monitor when files are actively transferred to SystemLink. For example, in the example shown in the previous figure, replace the TimeInterval for Wait to transfer files to SystemLink with a wait for the Custom Devices/SystemLink/Files/Commands/Transferring channel to change from 1 (which means the log files are still being transferred to SystemLink) to 0 (which means the files have been transferred).

Avoid Dialog Boxes in Remotely Executed Tests

Avoid using dialog boxes for tests that run without user intervention or visibility. Dialog boxes can pause or stop tests without user intervention. If dialog boxes are needed during development or debugging, surround the dialog call with the RunState.IsEditor property in TestStand, so that your remote execution is not impacted by the dialog box displaying.

Set Report Options for Long-Duration Tests

Use Report Options in TestStand to improve performance for long duration tests.

Note The BTS installer configures TestStand with these recommended settings. In the event that settings are changed, they can be reset by running Restore TestStand Result Processing Configuration.bat in %Public%\Documents\National Instruments\Battery Test System Toolkit\LabPC Configurations.
  1. In TestStand, select Configure » Result Processing to launch the Result Processing window.
  2. In the Report row, enable Show More Options and then click the Options button () to launch the Report Options window.
  3. Configure the following options on the Contents tab as required for your tests:
    • Enable Append if File Already Exists to append to an existing test report file in the event of system reboot during a test. Note that you must also configure report file settings on the Report File Pathname tab.
    • Enable On-The-Fly Reporting to generate TestStand reports concurrently with execution. The process model uses Post Result callback sequences to append new formatted results to the report. You can further configure On-The-Fly settings by clicking Advanced in the Result Processing window, available after selecting Show More Options. Refer to the TestStand Help for information about advanced On-The-Fly options.
    • Enable Only Display Latest Results so the report generator periodically purges results maintained in memory while generating the On-The-Fly Reports. This option can only be enabled after selecting On-The-Fly Reporting. The displayed report only contains results that have not been previously purged. The purged results are appended to the report file saved to disk, limiting the size of the report in memory.
  4. Configure the following settings on the Report File Pathname tab for best results using the Batch process model.
    1. Select Batch in the type of model drop-down list.
    2. Select Specify Report File Patch by Expression in the File Directory Options drop down list.
    3. Enter the following in Report File Patch (Batch Model) field:$(ClientFileDir)\..\\Report[$(UUT)][$(FileDate)][$(FileTime)].$(FileExtension)
    4. Enter the following in Report File Patch (Batch Model) field:$(ClientFileDir)\..\\Report[Batch][$(FileDate)][$(FileTime)].$(FileExtension)
    These settings will provide one report file per UUT. NI recommends using these settings to preserve memory and disk space as well as to minimize the file path length of the report files.