developing for multiple ATE systems that are not identical

[LV4Me]

I am developing a test program that, due to lack of system availability, will need to be able to run on two similar, but not identical test systems.  I work in a department that has a rather extensive test "template" developed over the years and will be using LabView 8.2.1.  It occurred to me (still relatively new to LabView) that the cleanest idea that comes to mind would be if I could have two different LabView libraries with the difference VIs having the same name and choose which library the routines would be pulled from at program load time (as opposed to having a myriad of case structures sprinkled throughout my program choosing between VIs).  Is there a way to do this?  Or, is there a better way to accomplish this?

Thanks in advance.

[krispiekream]

What we do at my place is that we write a script file.

A text file.

So for whatever ATE systems you want, you can run whatever script you want to use, which certian script calls for certain VIs or whatever.

The system calls for certain function in the program. 

I think its easier than creating different test software for each system.

[Broken_Arrow]

Your method would really depend on how many VI's end up being different.

I have found that dynamically loading VI's makes for a cleaner looking diagram, but a complicated directory structure, hard to edit code (where's my VI's, oh yeah, I'm using rig 2) and more difficult portability. Since hard drive space usually isn't an issue any more, I find myself doing the case statements more often.

You may find, like I have, that good old statically loaded VI's are a fine way to go after all.

These are opinions.

[F._Schubert]

I think this is a bit of a common situation for other ATE-engineers as well, and I havn't heard of any good solution yet. In my case, ATE's are sold to new customers that have a little bit of different specs for their UUTs. Not much, but maybe the voltage range is diffrent, so I need to at least have a variable for the amplifier gain, if not a diffrent code to talk to the device.

So the problem is, that we need to set some flags about the system at top level of the software, and they affect the most low-level tasks (driver/device specific).

Altough this is not 'best practice' to code, we have a set of global variables initialized in the very beginning of the top-level vi (guarded by a single frame sequence). In the low level vi's, we have these case structures you mentioned. A bit of an improvement can be achieved using the disable structures (you don't need the dll's for all the possible device present). It's not an easy-to-follow way, so the best is to keep it as simple as possible and live with dirty duct-tape fixes (aka globals). BTW: always use enums (type def'ed), never booleans, there always might be a 3rd option.

One way I haven't explored so far, and I hope it's working better is OOP. But I see too many pitfals there (including experience of developers and myself, but most certainly the unknown changes of the future). I would advocate duct-tape, 'cause most of the time you will get pressure in the final implementation stage anyhow (thissetup is already running with type A hardware, why not with type B hardware, it's from the same vendor,...; sounds familiar?).

Felix

[Ben]

---

F. Schubert wrote:

...

One way I haven't explored so far, and I hope it's working better is OOP. ...

Felix

---

... and I'll pick-up where Felix left off.

LVOOP

There is a LVOOP example at

...\examples\lvoop\BoardTesting

that illustrates some of the power of LVOOP. when properly implemented a LVOOP solution does what everyone esle has been suggesting about switch and dynamic calls etc but since it a complete supported solution to the challenge before you (stop breathe) you don't have to change existing VIs to support new flavors of test (so no re-testing) and you don't have to explicitly check "should I do this now or that?" AND LVOOP does the lodaing of the proper VI so no need to do the VI server thingy.

Discalimer:

Some of the error message for LVOOP in LV 8.2 were hard to decypher in that I had to know what I just did and how that affected the rest to figure out what that message could be talking about.

In LV 2009 the error messages are much better.

Ben

[LV4Me]

---

Ben wrote:

LVOOP

There is a LVOOP example at

...\examples\lvoop\BoardTesting

Ben

---

Sorry, I am a bit dense at following the link (I even searched on the terms)...where can I find the example?

Thanks.

[Mark_Yedinak]

---

testmule wrote:

---

Ben wrote:

LVOOP

There is a LVOOP example at

...\examples\lvoop\BoardTesting

Ben

---

Sorry, I am a bit dense at following the link (I even searched on the terms)...where can I find the example?

Thanks.

---

Ben is refering to where LabVIEW is installed. For example c:\Program Files\National Instruments\LabVIEW 2009\examples\lvoop\BoardTesting.

[JÞB]

Back in the day---(and LabVIEW 6.1 )

And I'm not saying its the most effecient code,.!......

I ran into a similar situation.  Test station A has equip x,y,z that do fns A,B,C and Test Station B had Equipment s,t,u that had the same fns x,y,z but required different addressing and different cmmands.

My soution was to write a set of "Function Drivers" so that the operator (or the station config file) could forward the station information to the test and know how that specific station could accomplish a given function.  It worked- and earned the name "IVI-Anorexic" when I'd hoped "Function drivers" would stick. yet, breaking it down to "Functions" e.g. "Voltage Source" or "Temperature controler" and putting the equipment specific drivers in cases of the "xFuncion Driver"

made for some high re-use code.   Caveat: be careful about errors and range checking if you go here,  you better really know the equipment limitations when they differ!