Design patterns for looping over multiple criteria in device test

[stephenb2]

Often in testing the device under test needs to be tested over multiple criteria (for example temperature, voltage, frequency, power, etc.).

The usual way to handle this is by nested for loops. This approach has its shortcomings, like complicated code and difficulty of adding a new loop into the nest.

Is there a better way, perhaps with a state machine implementation?

[altenbach]

Why would you need to add a new loop? Just iterate over an array of tests and add a new array element if needed.

Typically, we can give much better advice if we can see some code.

[crossrulz]

---

@stephenb2 wrote:

The usual way to handle this is by nested for loops. This approach has its shortcomings, like complicated code and difficulty of adding a new loop into the nest.

---

Complicated compared to what and for who?  Inherently, more parameters tend to more complication.  It is really just a matter of how you want to configure your test to which route you want to take.  As Altenbach stated, you could just put all of your parameters inside of an array of clusters (each array element being a cluster for a specific test step) and then you just need 1 loop.  But this can get really complicated/tedious as a user to configure.

[altenbach]

---

@crossrulz wrote:
But this can get really complicated/tedious as a user to configure.

---

Since the OP was talking about "adding loops", I assumes the number (and order) of tests is a compile time decisions.

If these should be a runtime decision, things get a bit more complicated. You need to design a intuitive UI and scalable code (state machine), but that's certainly doable.

[crossrulz]

---

@altenbach wrote:

Since the OP was talking about "adding loops", I assumes the number (and order) of tests is a compile time decisions.

---

It may be, but then the "user" configuring the tests is the OP.  And making arrays of clusters can get very tedious (been there).  Personally, I have never had an issue with nested loops, even when looping over several parameters.  Good use of subVIs alleviates most of the issues.

[stephenb2]

Here is a picture describing the same thing.

Say I next find out that I need to add a loop for testing over voltage, keeping power as the innermost loop. I would need to create a new for loop and insert it at the correct nesting level.

What if there was a later requirement for additional loops (channel, modulation, bandwidth)?

I personally find this cumbersome and was wondering if there was a better solution.

[RavensFan]

You are basically creating multiple degree of freedom testing plan.  It will grow exponentially larger.

I assume that if you have 5 temps, 4 frequencies, 3 powers, you want a combination of all those, so 5x4x3 tests = 60.   If you had another parameter like 4 channels, then it multiplies by 4 and now you are at 260.  If for some reason you say you only want to test 3 or 2 channels for some combinations of the original 3, the multi-loop idea will fall apart.

If you are the programmer and the test configuration person, then going to 6 or 7 or 8 loops like you showed won't be that hard.

If you want to flatten it to a single loop, then you need to create a flatter structure where you keep your various arrays, and pointers as to what the current test is.  As you increment through power, you increase the index by 1.  If you increment past the end of the array, then you reset it to 0 and increment frequencies by 1.   Likewise for the next level when going from frequency to temperature.   If you add a forth parameter, you don't need to add a loop, but you will need to add logic for how to increment through that new 4th array.

It might be just a bit easier to go to N test with that structure than the nested For Loops, but still may be tough.

You may just want to create a recipe of tests in an external application such as Excel where you quickly tabulate all combinations in a list, export it to a CSV file, and let LabVIEW read it in.  Just iterate through the list line by line feeding the various parameters into the center subVI.

[RTSLVU]

---

@stephenb2 wrote:

Often in testing the device under test needs to be tested over multiple criteria (for example temperature, voltage, frequency, power, etc.).

The usual way to handle this is by nested for loops. This approach has its shortcomings, like complicated code and difficulty of adding a new loop into the nest.

Is there a better way, perhaps with a state machine implementation?

---

Yes there is a better way and you answered your own question. (State Machine)

[altenbach]

---

@stephenb2 wrote:

Say I next find out that I need to add a loop for testing over voltage, keeping power as the innermost loop.

---

All you need is a single FOR loop with N wired as the product of all array input sizes. From [i], you can easily calculate the unique indices for each (now no longer autoidenxing) arrays to do your test.

[stephenb2]

Here is a single loop implementation. I need to think about a state machine some more ...