Suggested configuration method for advanced tests?

[LDBM]

This is a general questions to help me, and probably others in the Veristand boat: What is the best approach to programmatically set some tests parameters? Should a LabVIEW app be used, or should most of the parameters be set via config files?

More specifically,  let's assume one has a system with n I/O channels. A core-test would consists of a Stimulus, Channels, and Test Criteria.

• a  Stimulus would have parameters encapsulated in, for instance, : one or two SGL, one or two Strings, maybe a couple of channels, which can be defined in the Veristand framework for each test.
• Channels: a subset of the AI or DI channels from the main channel list
• Test Criteria: a few SGLs 

From one test to antoher the parameters would change, but the test would remain the same. So what's the best way to implement this? Use a set of config files or use the Versitand API in LabVIEW? 

Thx.

L.

[Jarrod_S.]

What is the nature of the stimulus you are using in your test? Have you already defined these? Is it a file to play back, or a stimulus profile from 2010?

NI VeriStand 2011 has a new stimulus profile system that may have some answers to provide here, but it would help to know what you are currently doing.

[LDBM]

Thx for following up.  

Yes I realize the question is very general, and I will try to refine as I move forward. The intend was to start on the right direction given I am learning Veristand (using 2011 now).  The Stimulus would be basic, such as a ramp, or one cycle of a square pulse. The parameters of these may change (such as level, duration), and the channels it is applied to, as well as the  channels set up as AIs will change from one test to the other. These are the kind of parameters I want to change without having to going in VersiStand GUI every time.

Does it make more sense now?

L

[Jarrod_S.]

Yes, that makes sense. Thanks for the details. I think the new stimulus profile features in 2011 would fit your needs if you want to go that direction. It would be worth looking into.

The new stimulus profile feature allows you to define Real-Time Sequence files. These real-time sequences define the test code that runs in the VeriStand Engine on your target. They would define, for instance, the square wave or pulse to play. The great thing is that these real-time sequences have parameters that you can map at run-time. So you could have a parameter that defines the duration of the pulse. You could then set that at run-time from a LabVIEW application using the execution API for real-time sequences before you run the sequence. You can also map parameters to system definition channels. That helps you define at run-time where to map the output of your stimulus. So you could pass in different DAQ channels for each test on different test systems. But the real-time sequence itself can stay the same.

If you have LabVIEW on your machine that has NI VeriStand 2011 on it, you might check out the example called Waveform Player Example.vi located here:

<LabVIEW 2011>\examples\NI VeriStand\API\Execution API\Sequences\Play Waveforms

This example shows how to run a generic real-time sequence using the execution API from LabVIEW and map different values to its parameters. This maps not only the output channel to play the waveform onto, but the values of the waveform itself (Y Values, dt, t0, etc.). Your test situation would be similar.

[Jarrod_S.]

Here's a quick example you can look at, too. I have a Ramp real-time sequence defined (I just copied this one from the standard library). At run-time from the example LabVIEW VI I can map its parameters and run it. Not shown in this example is that you can also grab the return variable value for the real-time sequence when it has completed. This can help you evaluate the result of the test and perhaps assign some custom pass/fail result to it.

[LDBM]

FYI:

<LabVIEW 2011>\examples\NI VeriStand\API\Execution API\Sequences\Play Waveforms has a broken arrow. so the target is not passed anywhere. Not sure if it is an issue or not, but once the broken wire is removed, the VI through a .net exception 1172.

L.

PS: Just saw your Ramp example - it looks like we posted at the same time - . Thx. I am going to look at it before getting back to you.

[Jarrod_S.]

Thanks for the note. The Play Waveforms VI that's broken is not actually used. The top level vi to look at is Waveform Player Example.vi.

We'll look into getting that fixed.

[rajamodol]

Hi Jarrod_S,

I have downloaded your example and tried it. Unfortunately, it generated error as screenshot below:

I am using NIVS 2012 and LV 2012. Shall I adjust something according to my NIVS/LV version?

Thanks,

Rajamodol