RFC: Request for Criticism

Question

Greetings,
I'm not entirely a teststand beginner as I have helped to maintain and fix bugs in several teststand systems over the last couple of years, but this is my first time programming a teststand system from the ground up.  What I would like to do here is to present the basic architecture that I've come up with and humbly request any critiques, caveats, potential pitfalls, or comments about the implementation.  Gory technical details follow:
 This application needs to test multiple different model types through, for the moment, two different test routines that use different parameters per model.  It would be nice to have the ability to add or modify the basic sequence in the future though all initial units will use one or both of the two test routines.
My current design plan is to use a custom Teststand OI programmed in Labview to interface to the sequence files in Teststand.  In the relatively rare case that a sequence file needs to be modified or copied, that will be done in Seqedit itself.  I considered doing a custom editor in the OI to limit the number of controls available and to steer the sequence development, but given the frequency with which that feature will be used (as in possibly never), that's been relegated to the back burner for now.  All data about the model numbers, the test limits, and the test parameters will be stored in an Access database file with a front-end Access "view" written for the end-user to add new models and test specifications.
The basic program flow is as follows:
The program launches and runs through the Teststand initialization and launches a DAQ controller VI in a parallel loop to control the various solenoids and read the transducers, etc...
The user logs in through the Teststand OI.
Depending on their permission levels, certain controls are made available or disabled (i.e. calibration screen access, manual control mode, most of the default Teststand Menu Items).
Labview queries the database for a list of models and populates a combobox with the results.
When the user selects a model, Labview will look up the test sequences that are linked to that model and load them into memory with the Application Manager's OpenSequenceFile method (so the ListBar from the Full OI is populated with the currently available tests for that part).  It will also unload any sequences that are not available for that part.
The user selects a sequence from the list and hits TestUUT's which runs an overridden PreUUT to prompt for custom information relevant to the test.  The sequence executes with calls to custom VI's and step tests and loads the test parameters from the database from within Teststand itself.  The report is generated within this sequence since it will be formatted differently for each test routine.
So, my basic question is to those with TestStand experience as to whether this sounds like a decent architecture for a test system?  How would you do things differently or better?
Just a few more notes: I want the flexibility of a custom OI since I want to be able to hide the complexity of TestStand from the operators, but I also want to lean on the Teststand engine as much as possible to cut down on coding time.  I had thought about trying to make the model selection and test-sequence selection all as a part of a master sequence that called the other test sequences dynamically, but I couldn't figure out how to do that easily as I think it would require changing the process model.  I'm pretty sure I could figure it out, but I'm not convinced it's worth the time trade-off.
Thanks for your time,
Mike

Answer 1

Mike,
I have a couple comments, first is everything looks reasonable. There are many ways to do each item and I am just saying what I would do, not what you should do.
The program launches and runs through the Teststand initialization and launches a DAQ controller VI in a parallel loop to control the various solenoids and read the transducers, etc...
[cc] All code that talks to DAQ should be in TestStand sequences, never in the OI. You should be able to run your tests in the Sequence Editor and the OI interchangeably, easily. This is really the only thing I would insist on.
Also it sounds complicated with a parallel loop. I would strip this loop down to just the functions you really need to be running in the background all the time. Launch the parallel loop from the Test UUTs Execution Entry point of the process model, maybe in Setup Group, so that the parallel loop is only running while you are actively testing stuff. Or you could launch from Front End Callback when TestStand starts up, less simple.
The user logs in through the Teststand OI.
Depending on their permission levels, certain controls are made available or disabled (i.e. calibration screen access, manual control mode, most of the default Teststand Menu Items).
[cc] You can put your screens in the Process Model Configuration Menu as a Configuration Entry Point or in the Tools menu. Think about where it belongs. These should not be only visible in the OI and not the Sequence Editor.
Labview queries the database for a list of models and populates a combobox with the results.
[cc] This could be in the Front End callback sequence with some logic to fire only when TestStand starts up.
When the user selects a model, Labview will look up the test sequences that are linked to that model and load them into memory with the Application Manager's OpenSequenceFile method (so the ListBar from the Full OI is populated with the currently available tests for that part).  It will also unload any sequences that are not available for that part.
The user selects a sequence from the list and hits TestUUT's which runs an overridden PreUUT to prompt for custom information relevant to the test.  The sequence executes with calls to custom VI's and step tests and loads the test parameters from the database from within Teststand itself.  The report is generated within this sequence since it will be formatted differently for each test routine.
[cc] This all sounds ok, I've seen others do this, but more work with the TestStand api. I'd start out simple. What you said here might be easier:
 I had thought about trying to make the model selection and test-sequence selection all as a part of a master sequence that called the other test sequences dynamically, but I couldn't figure out how to do that easily as I think it would require changing the process model.
[cc] The master sequence you mention is Test UUTs Execution Entry Point in the SequentialModel.seq. I think you could put all the model/sequence selection in the PreUUT callback of Test UUTs in one big hairy Dialog for all products - select model, select seq, enter custom information relevant to the test. Then you'd have to dynamically select the sequence to execute, but this is a common architectural thing to do in TestStand, there's an example: <TestStand 4.x>\Examples\DynamicClientSequenceFile
You will have to modify the process model anyway for some of the above stuff^. If you really want to do this:
 ... want to lean on the Teststand engine as much as possible to cut down on coding time ...
 [cc] then you should not be afraid to modify the process model, just make a copy first. Of course for the PreUUT you could override the process model with a PreUUT in the client sequence, but then you'd have to paste the same seq into all your test sequences.
cc