Jump to content

Suggestions for Multiple UUT Controller


Recommended Posts

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

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: .

Link to post
Share on other sites

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.

Link to post
Share on other sites

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!

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.