RFC: Request for Criticism

[Mike Webster]

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

[~jiggawax~]

Mike,

You are using the OI (UI) and the Seq. Editor the way it was intended to be used if I understand you correctly.

I would try and avoid using different models if I were you.  You should be able to manipulate the model through callbacks.  This will give you different client sequence files which then can be called based on which test the operator is running.  The only time I would use different models is if you are doing sequential testing and then you switch to parallel or batch testing. 

In the case that you cannot use the same model-  Will the client sequence be required to run on both models?  Or is the scenario where you have two client sequences and one uses model A and the other model B?   If that's the case then just change the sequence file properties to use a specific model.  Then you won't have to worry about doing it in your code.  If however one client sequence file needs to run with both Model A and Model B then you will have to change the station model through your code like you stated.

In general a Model should be station specific.  So all test engineers should be required to use the same model on that station.  The way they get different behavior is through callbacks.  This will greatly reduce the amount of supported code.

Hope this helps some,

[Mike Webster]

Thanks for the reply, Jigg.

I think there's some confusion that I didn't quite catch onto until reading your response.  Every time I mention "Model" before the last paragraph, I'm referring to a model-type of the UUT, not the Teststand Process Model.  I will henceforth resolve to refer to them as part-numbers.

The overall picture is that there are maybe 20 different PN's with one or two tests (and maybe more in the future) associated with them.  Each model has its own parameter list for each supported test.  This is all worked out in a database schema that I plan to use partly in Labview (during initial model selection and looking up valid test sequences) and partly in Teststand (when looking up sequence parameters).

The part about modifying process models was a stray thought I had to make the model selection and test selection as part of a "master" sequence which called the relevant subsequence.  But I think leaning on Labview in that case will make things easier and it should suffice for this particular application.

Sorry about the confusion ,

Mike

[dowNow]

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

[Mike Webster]

Thank you for your comments, dowNow.

The reason I was leaning towards a parallel DAQ loop is that the customer wants to be able to launch a parallel "manual mode" control/monitoring VI running in parallel with the testing.  This manual mode VI is what is driving the decision to go with a parallel DAQ loop.  My first inclination was to do as you describe and have that as a per-sequence, or even a per-test step setup.  But even if I didn't need the manual control VI to run in parallel with testing, I still need to know what model is hooked up at the manual control level because certain valves have to be actuated in certain directions and there are model-specific pressure and drive current limits to adhere to.

I'll look into adding the manual mode and calibration VI's to the Tools menu.  I haven't done any Teststand menu editing outside of removing and modifying some of the default CommandKind_ items.  Do I need to manually add commands to that CommandKind typedef or will tools added using the tools>customize menu automatically show up in the CommandKind_DefaultToolsMenu_Set?

I appreciate the philosophy behind doing things so that the sequence editor has access to everything from the OI, but I seriously think there's a good 90% probability the customer will never touch the sequence editor and if they do, it will be with our user's manual laid out next to them guiding them through a process (so we can dictate: backup existing, launch seqedit, open, modify, save, exit, update database, launch OI).

And as far as duplicate code in sequences, at the moment we intend to deploy with just two (paramaterized) test sequences, so I'm not too worried about the overhead on copying the PreUUT override ... 

Best Regards and thanks again for your time,

Mike