NI TestStand

Showing results for 
Search instead for 
Did you mean: 

Using TestStand 2017 TSM Module with a PNA-X: Saving SPAR Data using "Publish_Data.VI"


I am using TestStand 2017 with the TestStand Semiconductor Module. The goal of this post is for me to understand how to use the "" from TSM to record (and yield to limits) the results of a PNA-X test for various parameters vs. frequency or power. For now, I am focusing on just S21 data for MAG and PHASE but in the future I will need to create software for NF, Power Compression, Intermod results, and S11/S22/S12. 

I know that TestStand 2017 records its data in .STDF format, and I know that within the .STDF format (V4) itself the "Multiple-Result Parametric Record" is what I would most likely use to record the results of a single execution of a parametric test in the test program where that test returns multiple values e.g. a SPAR sweep over frequency. 

However, looking at the "2D Array" choice for the "" within TSM it looks like it only saves a single value for each parametric test for an array of channels and instruments for each channel, as opposed to an array of values for an array of channels and instruments of each channel.

My DUT is a MMIC with RF analog states controlled digitally via SPI. I am using NI-HSDIO for the digital control, NI-DCPower for DC/bias control, and a PNA-X using the Keysight LabVIEW Driver for RF Measurements. A pin map is definitely being used. There are multiple RF inputs and outputs to this MMIC and a special self-correcting switch is used that has its own driver and speaks both with the PNA-X and the computer itself. It's interesting stuff...

Here are some of my questions:
1) What does the STDF File Ordering look like when using the TSM "Publish_Data.VI"? An example of the file ordering I would use is in Page 70 of the STDF Specification V4 provided by Teredyne and attached to this post. I would like to know where the pin mapping records fit into the file ordering.
2) Is it possible with the current TSM VI's to save multiple values for each state defined by the channels for various instruments? E.g. Gain is set to one value, phase is set to another value, and an input/output switch is set to a specific path. I then measure S21 for each combination of gain/phase/path. How would this be recorded in the .STDF format that TSM uses?

3) How would I save, first, MAG, and then, PHASE, inside the STDF format for each S-PAR measurement if it all comes from a single channel? That would mean there are x8 arrays of data to save for a single digital state, and the states are a parametric combination of gain/phase/switch control all defined by channels defined in a pin map.

This gets more complicated as well but I'd figure I'd start with the basic thing I need to do which is just S21 mag/phase for now. There is also DC bias states (various VDD voltages to wiggle around +/- some %) that would be an outer loop while the digital control of the gain/phase/switch is looped inside of it. Temperature is even further out as an outer loop.

Perhaps I'll need to talk to an NI applications engineer on the phone.

I know how to control the digital, DC, and save individual results for testing things like the internal ADC/DAC, internal temperature sensor, and internal amplifiers for DC bias control on this MMIC, but when it comes to testing/storing/yielding to the results of a SPAR sweep using a PNA-X, I am at a loss. Will I have to just save this data in a .S2P file and do post-processing, and then convert to .STDF in the MPR record and add it into the STDF File Order appropriately? Sounds like a real pain.

Connor Pope

0 Kudos
Message 1 of 3

Hey Connor,


I'll start with question 1 and try to draw it out similarly to the PDF:


Initial Global Data

  • Global information for the file: FAR
  • Global information for the lot: MIR
  • Global site description: SDR
  • Wafer configuration: WCR [This is only written if you've configured wafer settings]

Test Data with Wafer Settings Configured

For each wafer

  • Information for first wafer: WIR
  • For each part
    • Information for the die overall: PIR
    • For each Semiconductor Multi Test step, including any in subsequences:
      • Results for parametric tests: PTR [One for each Numeric Limit test in your step]
      • Results for functional tests: FTR [One for each Pass/Fail test in your step]
      • Datalog Text from Additional results: DTR [Only inserted if you configure your Additional Results as described here]
    • Final result from die: PRR
  • Final results from wafer: WRR

Test Data without Wafer Settings Configured

For each part

  • Information for the part overall: PIR
  • For each Semiconductor Multi Test step, including any in subsequences:
    • Results for parametric tests: PTR [One for each Numeric Limit test in your step]
    • Results for functional tests: FTR [One for each Pass/Fail test in your step]
    • Datalog Text from Additional results: DTR [Only inserted if you configure your Additional Results as described here]
  • Final result from part: PRR

Final Global Data

  • Summary for each test in job planTSRs
  • Count of parts placed in each HW bin: HBRs
  • Count of parts placed in each SW bin: SBRs
  • Part count totals: PCR
  • Overall summaryMRR


All of this mapped out, I have a couple of other answers for you:

  • You will notice that we do not write an MPR as you mentioned in your second paragraph. TSM does not use MPR.
  • One option you have for saving MAG/PHASE data is to use the DTR in the Additional Results section. This is, however, global to a Semiconductor Multi Test step, so I am not sure if that will exactly fit what you want.


Now I'd like to address the larger question of how to configure the tests. You may need to create a separate tests for the different configurations of MAG and PHASE. With that, you can set a custom Published Data Id for each test configuration, which you can then associate with the particular tests so that you can interpret the results.


Let me know your thoughts on this data. I'd like to know your thoughts/concerns to understand how well this fits with what you need.




Product Support Engineer

0 Kudos
Message 2 of 3

Hi Ryan,

I appreciated the detailed response. Thank you for giving me the configuration of the STDF data format that TSM outputs as it is very helpful. Yes, I figured that the MPR record was not used by TSM. I am not sure if the DTR record and Publish Test ID method will work as wanted for our characterization because we will need to know the frequency, and whether it is magnitude or phase, associated with each test done. Another issue is there is a lot of other parametric information that needs to be saved with the frequency mag/phase information such as input power, amplifier gain settings inside the chip, signal path (there are multiple paths) etc. and the number of frequency points could be dynamic as well between tests. Because our frequency numbers could be dynamic throughout our testing, that would potentially require me to constantly change the TestStand tests. The key reason for this is that we are using this TestStand sequence and LabVIEW VI's to do both characterization and production test, all using the same NI test rack. The production test, I can certainly use the method you describe, but for characterization, it will be much more difficult due to having to save parametric results and knowing what state it was done in.

I've been talking with another software engineer coworker and we think we can probably do it using the "Value" in the Module tab where we set it such that it points to a variable in the "Locals --> ResultList" which would mean we point an output of the VI to a local variable in the Module tab. I've provided pictures showing the specific parts of TestStand I am referring to. I am still not sure how we will save the parametric results in those same variables, unless we pass them through each VI, or save an entire array of S2P information to a result in the result list, but it's a start. STDF formatting is not preferable for characterization, but is preferable for production results.

Very hard to explain over text, but luckily I have gotten into contact with an NI apps engineer who helps my company out and will be talking with him to figure this out!

Connor Pope

0 Kudos
Message 3 of 3