Running parametrized sequences

[rolfk]

Is there an example how to do parametrized test sequences in Teststand?

The current setup is such that a number of tests should be performed with various power supply voltages and temperature conditions. For this there are remote controllable power supplies and a thermostreamer. The most direct approach would be to simply add looping inside the test sequence for these parameters but that feels pretty unelegant and also unscalable as well as cumbersome for quickly modifying the parameter test conditions independently from the rest of the test setup.

[JohanHoltby]

I don't quite get the question. Can you elaborate? Since you seam to be an expert I'm probably not posting the right awnser but if that is not hte case here is an example of  sequnce using parameters: <TestStand Public>\Examples\Demo\HTBasic\computer.seq on my computer: C:\Users\Public\Documents\National Instruments\TestStand 2012\Examples\Demo\HTBasic\computers.seq.

Hope that helps and if not I'm lookin forward to se your elaboration.

[JakeA]

Hello Rolf,

I don't know of any examples for this supplied directly by NI, but I had a quick search of the community examples and from what you've described, this example might be useful: http://www.ni.com/example/31247/en/. It is quite an old example, however, so I'm not sure how well it would work with newer versions of TestStand and LabVIEW. I haven't been able to find anything else that is similar to what you're looking to do, so let me know what you think of this example, and I'll see what further resources I can help you to find so that you can put together this sequence.

Best regards,

[~jiggawax~ · Accepted solution]

Rolf,

This is always an intriguing discussion.  The problem is that you need to define all of those values somewhere whether it be a databse, flatfile or in TestStand format itself.  Here is my take on it.

Databases and flatfiles have the same issue.  At some point you need to read in the values and map it to the steps they are being passed in to.  The mapper is the killer here. The reason is that it can be as simple as a PO file that maps to a local variable which is then used in the step parameters or quite complex where it iterates through the steps and injects the values into the calls.  The other MAIN issue with this is what if the datatype changes.  How do you roll that back to the database or flatfile while still retaining the 40 different sets of values already in there.

I've found that keeping the data in a native TestStand format is the simplest and easiest to maintain. Whether it is a local variable that you contain the data or an abstraction layer where the values are hardcoded in the steps the advantage to keeping it in TestStand is that when datatypes update they are automatically pushed and the values are retained.  The downside is editing the limits outside of the TestStand environment is not really available unless you want to build some kind of special editor.

Either way this is always a huge undertaking.  Personally I'm not a fan of the property loader because it is limited in the variables and parameters that it can export/import and also the files tend to get real icky after about 20 values.

Hope this helps,

[rolfk]

I'm not quite an expert in TestStand (yet). Really more trying to learn it while doing. jigg addressed one of the points I'm struggling with. Managing the parameters in an intuitive to control way for the test operator is one of the problems. The other is that I'm still trying to understand the different process models and when they are best used and how the various callbacks relate to each other. In a way I'm missing an easy way to get a global (and preferable graphical, yeah I know I'm LabVIEW spoiled ) overview of the relationship between sequences, sub-sequences, and callbacks and all the combinations thereof.

Also I'm coming here from a custom test executive implementation written entirely in LabVIEW, which seperates these test parameters from the actual sequence setup. This feels somehow more intuitive than starting to bake the handling of those parameters into every new main test sequence we may want to develop in the future. Sure this custom test executive has many deficiencies, which is the reason that the customer is even willing to look into TestStand, but this particular task seems pretty hard to implement in a simple and for the future reusable way without starting to create custom models with all kind of extra customizations. However I don't really have the time to start looking into doing this kind of customization now.

It would seem that this kind of requirement is pretty standard in any semiconductor related test setup, but maybe those tests get most of the times implemented on special purpose chip testers because of the execution time constraints. This is however in a development environment where the actual tests vary continously and developing a chip tester application is not very cost effective because of that.

[~jiggawax~]

Rolf,

I understand the frustration to wrap your head around the relationships in TestStand.  Not being connected by wires, it is hard to see the flow.  They do have some diagrams out there that kind of help out.  If you google TestStand Process Model you can read through some of the docs that have pictures.  Also, in the documentation that gets installed with TestStand there is the TestStandSystemandArchitectureOverviewCard.pdf that might help out.  I'm sure you can google that doc as well.

If you think of a sequence file as a collection of VIs (much like an llb in LV) and each sequence in the file is a VI.  Then the Parameter list for the sequence would be similar to the connector pane for the VI.  A sequence call is like calling a SubVI.  The tricky one is the callbacks.  This just comes with time and experience.  Usually if I'm unfamiliar I just look in the model and read the description for why the callback exists and when to use it.  Then I look in the Execution Entry Point and see where the callback is being called.  Also, pay close attention to the parameters of the callback.  They can tell you the purpose behind the callback as well.

Basically everything starts with the Execution Entry Point (the red sequences in the process models).  Just follow the flow sequentially and you should be able to figure out what will be called during execution and in which order.

Hope this helps some,