Critical Security Update

To help protect your systems, customers using NI driver software 2026 Q2 or earlier should visit ni.com/ni-pal-update and follow the recommended actions.

Considerations for TestStand Semiconductor Module Custom Step Types in TestStand

Updated Sep 8, 2025

Overview

The TestStand Semiconductor Module extends the TestStand environment to help you develop, debug, deploy, and maintain semiconductor test systems. This article offers some considerations to keep in mind when creating a TestStand Semiconductor Module (TSM) custom step type.

Considerations

A custom step type’s pre-step substep cannot access any information from Step.SemiconductorModuleContext until after the default TSM pre-step substep executes. Additionally, any information relating to Step.SemiconductorModuleContext that a custom pre-step substep would like to change, in the hopes that you can affect a set of tests or per-site data stored in the step, will not take effect after the default TSM pre-step substep has executed (as the SemiconductorModuleContext is created, and the information relating to a particular step instance is cached by TSM, at the moment the default TSM pre-step substep executes). Thus, any desire to affect Step.SemiconductorModuleContext properties can only happen at edit time and can only affect step properties stored in the edit context of a step.
If you would like to ensure that a custom step type’s Default LabVIEW module is revision controlled, you must not modify the prototype of the VI in any way, unless you are intent on updating your custom step type definition each time a change is made to the VI’s prototype (and subsequently update all previously written user Sequence Files using the built-in Update VI Calls… tool). There are a few ways to ensure that this does not happen: for example, you could only pass the SemiconductorModuleContext and a SequenceContext into your default module and use the TestStand API to retrieve the values stored in your step. You could also ensure that the VI called by any of your steps has the latest prototype by force reloading the module anytime your Edit Panel detects that the module’s prototype is incompatible.
It is not a problem to use the default module. You could make it more difficult for a user to change the default module by hiding the Module tab on all of your step types. In order for TSM to correctly synchronize a given step and to ensure that a pre-step substep module does not unintentionally execute on blocked sites, use of the default module may be required.
Accessing the Evaluations step property of a TSM Semiconductor Multi Test Step Type does not have an official API. Thus, any custom step that implements an edit substep for modifying these properties must use the PropertyObject API from TestStand to make programmatic changes to the tests, which are stored in the Result.Evaluations step property. Just be aware that any development effort made now to enable a set of custom tools may need later updating to accommodate any new APIs made available by new features of future releases of TSM.
Accessing the Pin Map information at edit time cannot be accomplished through the usual runtime methodology (LabVIEW PinMap API VIs) due to the fact that Step.SemiconductorModuleContext is not valid at edit time. Also, the NationalInstruments.TestStand.SemiconductorModule.PinMapAPI.dll does not currently have official documentation on how to access Pin Map File information programmatically at edit time.
In versions of TSM prior to 2016, TSM uses the step type name to determine if it is a semiconductor test step. As a result, the TSM report generators (STDF and Test Results Log) and the test limit loader do not treat instances of custom step types the same as Semiconductor Multi Test steps. The report generators do not include the results of instances of custom step types, and the test limit loader does not import or export test limits from instances of custom step types. In TSM 2016 and greater, TSM identifies semiconductor test steps by the existence of a step property Result.Evaluations that is an array of NI_SemiconductorModule_Evaluation data type. The TSM report generators and test limit loader work with any step that meets that criteria.

Additional Resources

Was this information helpful?

Yes