Data Management Recommendations (TSM)
- Updated2025-04-10
- 7 minute(s) read
The following table summarizes available data mechanisms in TestStand, in the TestStand Semiconductor Module (TSM), and in the programming environment you use. Refer to the following Data Mechanisms Selection section for more information about issues to resolve before selecting a data mechanism.
Type of Data | Used Only in TestStand | Used Only in Code Modules | Used in TestStand and in Code Modules |
---|---|---|---|
Per-site | Sequence local variables and parameters TSM executes a unique run-time sequence for each site. Use the TestStand sequence local variables and parameters to create per-site variables in TestStand. |
Site Data API (TSM Code Module API) Because TSM can execute a code module on multiple sites in parallel, managing per-site data in a code module can be complex. Use the use the Set Site Data VI or SetSiteData .NET method and the Get Site Data VI or GetSiteData .NET method in the TSM Code Module API to get and set arbitrary per-site data in a code module. With the site data API, you associate each per-site data value with a data ID at run time to uniquely identify the data with a name. |
Because TestStand and TSM code modules use different data mechanisms for storing per-site data, you must pass the data between TestStand and each code module to share data. To pass per-site data stored in a TestStand variable into a code module, use the Set Site Data VI or SetSiteData .NET method and the Get Site Data VI or GetSiteData .NET method in the TSM Code Module API to create a separate code module to store the data and call the code module from a Semiconductor Action step configured to use the One thread per site value in the Multisite Option control. Pass the unique data ID and the TestStand variable as an array of one element into the code module to store the variable value in per-site data for code modules to use. To pass per-site data stored in a code module into TestStand, use the Set Site Data VI or SetSiteData .NET method and the Get Site Data VI or GetSiteData .NET method in the TSM Code Module API to create a separate code module to get the data and call the code module from a Semiconductor Action step configured to use the One thread per site value in the Multisite Option control. The code module must extract the data from the first element of the array the set data API in the TSM Code Module API returns. Pass the unique data ID and the TestStand variable to receive the data in the code module. |
Global | Sequence file global variable (after changing Sequence File
Globals option to All Executions Share the Same File
Globals) You can use sequence file global variables to manage global data in TestStand, but you must change the default value of the Sequence File Globals option on the General tab of the Sequence File Properties dialog box from Separate File Globals for Each Execution to All Executions Share the Same File Globals to ensure that the sequence file global variables are shared for all sites. If you do not change the value of this option in the Sequence File Properties dialog box, the sequence file global variables store per-site data only. |
Language specific data, Global Data API (TSM Code Module API) For global data used only in code modules, use the data mechanism that the language the code module uses to achieve the best performance. For example, use LabVIEW global variables or functional global variables to share global data among LabVIEW code modules. You can also use the Set Global Data VI or SetGlobalData .NET method and the Get Global Data VI or GetGlobalData .NET method in the TSM Code Module API. |
To use global data in code modules and in TestStand, use sequence file global variables to manage the data in TestStand. You must change the default value of the Sequence File Globals option on the General tab of the Sequence File Properties dialog box from Separate File Globals for Each Execution to All Executions Share the Same File Globals to ensure that the sequence file global variables are shared for all sites. If you do not change the value of this option in the Sequence File Properties dialog box, the sequence file global variables store per-site data only. Within the code modules, use the data mechanism that the language the code module uses to achieve the best performance. For example, use LabVIEW global variables or functional global variables to share global data among LabVIEW code modules. You can also use the Set Global Data VI or SetGlobalData .NET method and the Get Global Data VI or GetGlobalData .NET method in the TSM Code Module API. Pass the global data into and out of code modules using parameters to the code modules. |
Global constants | Test conditions You can use the same mechanism described in the table cell. Alternatively, you can define test conditions in the Test Program Editor. You can use the Get Test Information step to reference the test conditions in a sequence. You can create multiple test program configurations that use different values for each test condition that you define. Test conditions support only numbers, strings, and Boolean values. |
Specifications You can use the same data mechanism described in the table cell. Alternatively, you can use a specifications file to define named expressions that evaluate to constants at run time. Use the Digital Pattern Editor to edit specifications files. Use the TSM Code Module API to get the value of a specification. Specifications support only numbers. |
To use global constants in code modules and in TestStand, use test conditions or a sequence file global variable to define and access the constant in TestStand. Pass the global constant into a code module using parameters to the code modules. |
TSM site numbers do not always directly correspond to test socket indexes. Use the Get Site Runtime Data VI or the GetSiteRuntimeData .NET method of the TSM Application API or use the Get Test Information step to obtain specific site numbers.
Data Mechanisms Selection
Before selecting a data mechanism to use, you must understand how and where the test program uses the data. Consider the following questions as you select a data mechanism:
- How should the test program access the data? Some data mechanisms work best in code modules, and others work best in TestStand. Sharing data between code modules and TestStand is more complicated than using the data in only one environment or the other. Refer to the Accessible Locations column in the following table.
- Where should the test program define the data? Some data mechanisms define the data in an external file that you access from TestStand or from code modules. Some data mechanisms define the data while editing the test program, and others create the data at run time. Refer to the Defined Location column in the following table.
- What type of data does the test program use? Some data mechanisms are limited to specific types of data, such as numbers, strings, and Boolean values. Refer to the Data Types column in the following table.
- Does the data remain constant throughout testing or does the test program modify the data? Refer to the Constant or Dynamic column in the following table.
- Does each site use unique data values or do all sites share the same data values? Refer to the Per-Site or Global column in the following table.
Data Mechanisms Table
The following table outlines the different mechanisms for managing data in TestStand, in TSM, and in the programming environment you use.
Data Mechanism | Purpose | Accessible Locations | Defined Location | Data Types | Constant or Dynamic | Per-Site or Global | Limitations |
---|---|---|---|---|---|---|---|
Language specific data (LabVIEW global variables or .NET variables) | Manage per-site or global data in code modules | Code modules | Code module | Any language-specific type | Dynamic | Per-site or global | Difficult to manage per-site data efficiently |
Site Data API (TSM Code Module API) | Manage per-site data in code modules | Code modules | Code module | Any language-specific type, except LabVIEW classes | Dynamic | Per-site | Does not support LabVIEW classes |
Global Data API (TSM Code Module API) | Manage global data in code modules | Code modules | Code module | Any language-specific type, except LabVIEW classes | Dynamic | Global | Does not support LabVIEW classes; potentially slower than language-specific data |
Step Input Data API (TSM Code Module API) | Pass per-site data from TestStand into a code module | TSM steps, code modules | TestStand variable | Numbers, strings, and Boolean values | Dynamic | Per-site | Supports only numbers, strings, and Boolean values |
Step module parameters | Pass global data from TestStand into a code module | TSM steps, code modules | TestStand variable | Any TestStand type | Dynamic | Global | — |
Sequence local variables and parameters | Manage per-site data in TestStand | TestStand | TestStand variable | Any TestStand type | Dynamic | Per-site | — |
Sequence file global variables | Manage per-site data or global data in TestStand | TestStand | TestStand variable | Any TestStand type | Dynamic | Per-site or global, depending on a sequence file setting | Supports per-site or global data but not both; requires changing a sequence file setting to support global data instead of per-site data |
Specifications | Specify constant expressions that code modules and digital timing and levels sheets use | Digital Pattern Editor, code modules | Specifications file | Numbers | Constant | Global | Supports only numbers |
Test Conditions | Specify constant test conditions associated with current test configuration | Test Program Editor, TSM Operator Interface | Test Program Editor | Numbers, strings, and Boolean values | Constant | Global | Supports only numbers, strings, and Boolean values |
Station and Lot Settings | Specifies settings associated with station or current lot | TSM Operator Interface | TestStand type | Any TestStand type | Constant | Global | — |