test program in manufacturing environment

[mysticfree]

I'm designing a program to be used in a manufacturing facility.  The ultimate goal is for a user to:
1) select a part number that has specific parameters to be verified (resistance, flow, leak),
2) tested several parts of the selected type and then
3) return to the part selection portion of the program when the user is ready to test a new part. 

Between these two action (pick part type, test it) is a diagnostic option that allows a user to verify the test setup (turn relays on & off, get voltage readings from different analog channels).  So far, I have been able to write each section seperately.  I can pull up a database of parts with their associate test values and allow one part to be selected.  I can run a diagnostic VI that checks the functionality of the test equipment.  And I have state machine VI that simulates the test sequence (resistance, flow, leak tests) using values (expected and tolerance) that I manually key in at the beginning of the program. 

Now I am stuck on how to get all three together in one VI.  Do I use a tab control with a tab for each function (select part, test part, diagnostics)?  Should I use a sub-panel control instead? Do I keep each function as a seperate VI and create a 4th VI to call each one?  (I will need to pass the selected part info into the "test part" section.)  Maybe I'm making this more complicated than it needs to be. 

Any thoughts on the best methodology to handle are greatly appreciated!

[Gabi1]

it sound like a perfect fit to an event structure, driven by a set of buttons.

to test out how it would fit your application, you can put a call to the operating vi with "open front panel" and "wait until done" property in each event, without implementing the program fully.

[_S_G]

I second that.  A state machine is what I've used in the past for this type of application.  When you need to call a sequence of operations, call a series of states.  You can implement a loop in your state machine (using local variables and having different states for "initialize" "increment" "check condition" and "end").

One other option that could make things easier is TestStand, but that would be appropriate ONLY if your test procedure is likely to change on a regular basis and you require flexibility in your test procedure.

[mysticfree]

Thanks!  This might be just the ticket.  Since it wasn't covered in the Basics I & II course, I look up 'event structure' in the help and ran an example. 

Would it be easier to collect the 'selected part' into a cluster?  Would I then be able to pass that cluster on to the 'test part' portion, perhaps by through a shift register?

[F._Schubert]

Minimize the number of clicks (and mouse movement) the operator needs to perform. That improves test throuput, as the guy above them says (and he propably judges your equipment). So the best might be 3 Windows (Dialog style) with Cancle/Confirm and End/Again at the last one.

The operators won't take a close look (they do it day by day), so when you need their attention, use red/green color. And minimize information. On the other hand, they don't need a stylish GUI, they are happy to get the UUTs through (thats what they are payed for).

Don't care about them more, because it is their job is to use any UI. And they are good at their job (I really love them, how they accomodate to some old fashiond software I designed years ago).

And have a thinking who else is going to see the software (customers, engineers, CEOs, visitors, researchers/sientists ...). Their objectives are different.

For the Diagram, a state machine is great in that case.

One more thing about the UI: when users feel unsure, they try to close the window AND they like to have a cancle button. So have an action for both (normally the same) is a good idea.

Felix