Suggestions for Multiple UUT Controller

[lvb]

I am seeking advice on architecture of a multiple Unit Under Test (UUT) controller. To be extremely generic: Most applications require turning on/off a sequence of digital outputs based upon digital inputs, setting analog outputs, and finally capturing the resulting analog data

Most of my designs consist of a single GUI and control loop. However, when creating a multiple-station controller I cannot seem to come up with solution that is elegent and easy to debug.

So... I come to this forum to seek advice. Please let me know if there is any additional info that may help!

Thanks

[BobbyCee]

Have you considered using GOOP in your design? Treating the "stations" as objects will afford tremendous flexiblity in your design.

Also, what type of daq hardware are you considering/using for your application?

[Omar Mussa]

You should probably take a look at NI TestStand as it is a framework that can handle parallel testing and a lot of generic UUT framework (loading parameters, storing results, reporting, etc) - you could then write the 'Tests' in LabVIEW. You'll need to figure out how you can define 'Tests' that fit into TestStand's framework and meet you application requirements.

[LAVA 1.0 Content]

QUOTE(brianafischer @ Mar 8 2007, 08:30 PM)

So... I come to this forum to seek advice.

I would reccommend starting with "A Software Engineering Approach to LabVIEW" by Conway and Watts. You can see the table of contents at http://safari.phptr.com/0130093653?tocview=true''>http://safari.phptr.com/0130093653?tocview=true' target="_blank">http://safari.phptr.com/0130093653?tocview=true

The book is older, so it doesn't discuss LVOOP, TestStand etc..., but it DOES give you good techniques for writing modular, scalable, and maintainable code. The concepts and skills are still applicable to the latest version of LabVIEW. (The program example in the book is for a multi-UUT test platform!)

Thank you Aristos Queue for recommending this book to me :worship: .

[crelf]

QUOTE(Omar Mussa @ Mar 9 2007, 06:26 PM)

You should probably take a look at NI TestStand as it is a framework that can handle parallel testing and a lot of generic UUT framework (loading parameters, storing results, reporting, etc)

:thumbup: Great idea Omar - TestStand is a great product, and highly configurable too (the operator inteface is written in LabVIEW with a bunch of ActiveX calls so you can write your own). The RunTime Licenses are also cheaper than they used to be a few years ago, so it's well worth a look.

[lvb]

Thanks for the advice regarding TestStand. However, I am seeking advice in techniques to accomplish the forementioned task in a LabVIEW g-code application. I do have the Professional development system, so X controls are an option and I am using LabVIEW 8.2.

Current applications I deal with (that others designed) utilize multiple for loops which is really bad (i.e. 4 for loops for 4 stations!). I haven't seen any good examples beyond a simple state machine. My thoughts thus far are to utilize GOOP to create a class for each station. However, I could use some advice in how to implement the control logic. I currently use re-entrant VI's, but I could also use some advice on how to debug a re-entrant VI while multiple stations are calling it.

QUOTE

Also, what type of daq hardware are you considering/using for your application?

Most applications utilize USB-based DAQ. A few of them would use CompactDAQ..

Thanks again!

[Neville D]

QUOTE(brianafischer @ Mar 9 2007, 05:33 PM)

I do have the Professional development system, so X controls are an option and I am using LabVIEW 8.2.

Current applications I deal with (that others designed) utilize multiple for loops which is really bad (i.e. 4 for loops for 4 stations!). I haven't seen any good examples beyond a simple state machine. My thoughts thus far are to utilize GOOP to create a class for each station. However, I could use some advice in how to implement the control logic. I currently use re-entrant VI's, but I could also use some advice on how to debug a re-entrant VI while multiple stations are calling it.

If you already have LV 8.2, debugging re-entrant VI's is a snap. Just double-click on the VI and you can open its front panel, and probe its diagram just like a regular VI.. multiple instances show up as different VI's with a number attached to the name.. Example.vi_1, Example.vi_2 etc.

As a matter of style, it is better to use while loops (instead of FOR) with the option of stopping the test on error or user-set Stop.

Neville.