Test program in manufacturing environment

Question

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!
CLD Certified

Answer 1

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
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml