Large number of test steps - Sequencer / State machine

[Dwayne_Arxtron]

I have a program that I need to make that has 650+ steps. Each step needs to be logged individually as a test step. Most steps are repeats that have to do with timing and sending a few commands in-between. 

In LabWindows my company has made a sequencer which allows nearly automated logging and easy addition/removal of test steps. In LabVIEW it seems state machines are the way to go and when I created a program of 16steps everything was ok. Now I'm tasked with writing code for 650+ test steps and I'm unsure how to handle this.

Can you shed some light on how to handle such large sequences? Doing this through a state machine the way I'm thinking, where each step is a state, is unfeasible. In these scenarios do people turn to TestStand? 

Thanks in advance.

[RavensFan]

Do you truly need 650+ states?

When a step is a repeat, it sounds like it is just running a state that you have have already done multiple times before, maybe with different conditions.

Break down your steps into groups of different types of steps.  Then you only need a single state that will work for different steps.

The master test plan should be an array, where each element is probably a cluster.  with an enum telling what state to execute and elements that describe any parameters that are important for that particular step.  Then when you run the state machine, when you complete a step, you just tell it to index the next step out of the array and run that.  Perhaps if something happens like someone hitting an abort button or a step fails, the state machine might make a decision to go into some other states rather than execute the next step in the array.

I've never used Teststand so I can't comment much about it.  I believe it was designed for just the situation you have.  But you can certainly program LabVIEW to do a large program like you are describing without needing TestStand.   If you modularize your steps correctly, you won't need 650+ states, you can probably do it in perhaps a dozen.

[Dwayne_Arxtron]

The repeat steps, as you mentioned, are checking voltages/bits/etc. Each test step where we send a few commands will alter the DUTs output and we need to double check them.

Our customer gave us step-by-step instructions, which to measure first and so on, which sums up to 650+ steps. It makes sense to merge what we can and we will, I'm just afraid I can't reduce them too much. We have different stages in the test which might be useful in helping me condense these tests. 

The idea of using an array of clusters sounds like a good idea, I'll have to look into that. What we have setup in our LabWindows code is an XML that we can edit on the fly and accordingly our sequence will re-arrange without and code edits. This is the aim for LabVIEW to have something similar in fashion. The XML contains a test steps list which has a params child; this XML is editable and allows the software to dynamically build the sequence and pull the params to evaluate that test step.

No hard coding done between sequencer and test steps, which is the beauty of the code. Do you know if this is something people commonly do in LabVIEW?

[crossrulz · Accepted solution]

I recommend just using TestStand.  It does almost everything you are asking out of the box.

[Kyle97330]

Having a cluster that contains one item that defines the state in a state machine (string or enum) with a number of extra spots in it for parameters (channels, volts, whatever) is a pretty normal thing to do.  You do sometimes run into the problem where you either have a MegaCluster™ with dozens of slots for parameters, or you have a GenericCluster™ with a lot of slots named things like "Numeric parameter 1" or "String parameter 3" which are flexible but hard to keep track of what they all mean sometimes.

TestStand is built for this sort of thing if you're willing to use the TestStand editor itself as the editor for your sequence, i.e. instead of XML files. It's also an entirely different program and if you don't have experience with it, this might be a more complex program than I would recommend creating on your first try.

An alternate LabVIEW solution I might offer is to use LVOOP. Create a parent class called "Test Step" or something, and have 2 common methods, one called "Parse XML" and the other called "Run test".  Create a dozen or whatever child classes that implement overrides for these. You grab a chunk of XML and check the first node to find which child class to instantiate.  Pass the rest of the XML to the "Parse XML" function to get out the exact parameters needed for that test step.  Then call the "Run test" override on it to run with those parameters.  It solves the MegaCluster™ problem by making each class have its own small private cluster, and you avoid the GenericCluster™ problem in the same way, but you can make a ton of VIs that can handle your parent class so you don't need to worry about a dozen different data types either.

[Dwayne_Arxtron]

Looks I was able to get my hands on a TestStand license. 

Thanks all.