Best Architecture for App?

[zenthoef]

I am starting to design a LabVIEW program for a test fixture that will control and take measurements on at most 4 different units. The sequence in which the tests begin and end on each unit will be very user friendly. To give an idea of the flexibility of this test fixture: all the units could start and finish the tests at the same time or they may start and finish the tests at different times. Ideally, testing will initially start at the same time, but as testing goes on tests on inidividual units may start and end at different times as different units are tested. It is desirable to have each test for each unit display if that test passed or failed.
 
For more information, I plan on the user pressing a "Details" button to call a VI that displays the detailed test information for that unit. This "Details VI" will then be closed to return to the top-level VI in which the information I described above will be displayed. The detailed data will also be written and saved to a file.
 
I am thinking that the ideal architecture for this program will be a Master/Slave architecture that controls 4 different General State Machines. The Master Loop will constantly monitor for units under test to be placed on one of the 4 sub-test fixtures. When a unit under test is detected, the master loop will tell the slave loop (which is also the General State Machine) for that fixture to begin the series of tests. In the General State Machine, each test will be a Sub-VI in a different state, this way the status of each test can be updated as that test finishes. When the testing on a unit finishes and the unit is removed, the master loop will detect that unit has been removed from the fixture and re-initialize the appropriate state machine for the next unit.
 
My question is: Is the architecture I have planned for this kind of application the best architecture or is there a better way to approach a problem like this that requires parallel control and data collecting?
 
Thanks.

[smercurio_fc]

Have you considered TestStand, or is that cost-prohibitive? (Though considering the amount of time you would need to spend coding the executive it will probably be cheaper.)

[zenthoef]

I'm not certain that TestStand really meets my needs. I am not controlling a lot of instrumentation. Most of the tests (if not all) are ran using custom fixtures that we have designed. I just have to coordinate what test is happening on what fixture at a certain time.

[smercurio_fc]

TestStand's usability isn't really related to the amount of instruments that you're controlling. It's more of what kind of testing process you're executing. I'm not trying to pitch TestStand - I just threw it out as a suggestion. Your general architecture is generally sound, but has one fundamental flaw: it's limited to 4 devices and would involve (I'm suspecting) duplication of code. You may wish to consider looking at an object-oriented implementation of your test execution. This way you can instantiate as many as you need, and you would not need to have 4 separate slave loops.

[zenthoef]

Thanks for the suggestion of TestStand. I suppose I showed some ignorance in thinking its usefulness is proportional to the number of instruments I am controlling. I only glanced over the white paper for about 5 or 10 minutes. I'm not too hopeful to get something like that anyhow, as the test fixture will probably not justify any additional funds. However, I'll probably at least keep it in mind for future applications.
 
An object-oriented approach sounds interesting. However, I am unsure what this looks like in LabVIEW. Are you refering to each slave loop being a VI? Or is there another approach to object oriented programming in LabVIEW that I am not aware of?
 
Thanks.

[Pie56694]

Hi Zenthoef,If you want to get a glimpse of LabVIEW Object-Oriented Programming (LVOOP) in action, check out <a href="http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=211237&amp;requireLogin=False" target="_blank">this</a> post. <a href="http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/front_oolv/" target="_blank">LabVIEW 8.6 Help &gt;&gt; LabVIEW Object-Oriented Programming</a> <a href="http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/creating_classes/" target="_blank">LabVIEW 8.6 Help &gt;&gt; Creating LabVIEW Classes</a> The smercurio's suggestion is great for scalability.&nbsp; If you might add test stations down the road, the time invested learning LVOOP will probably pay dividends.&nbsp; If the specification will certainly not change, then this one case alone may not justify developing an object-oriented program.&nbsp; However, there is no shortage of arguments in support of learning and deploying LVOOP.

[smercurio_fc]

From a high-level I'm thinking of the test process being a class. When you need to start a test on a unit you instantiate that class and "Run" it. The "Run" method is basically your state machine that is executing the test process. There's a small example that ships with LabVIEW that shows testing of multiple boards using classes that you may want to take a look at to see how it works.