Open Source Test Executive for LabVIEW (OSTE)

[TJ Robertson]

The OSTE project was started in 2002 to create an open source test
exec for the LabVIEW community. Since many companies develop their
own in house test execs of marginal quality, it is simple to see how a
open source one could benefit all of us in the LabVIEW community.

Unfortunately, the 2002 effort seems to have stalled. I would like to
find some people to revive the effort with me. For now, I think that
we should discuss what a features all test execs have in common. It
is my belief that the correct thing to do is create a general test
script format as well as a corresponding test sequencer library to
load scripts, load plug-ins, and iterate through the scripts. This
will allow individuals to create a GUI, and any o
ther code they need
for their project around the generic test sequencer library. I say
this because I have seen far too many applications for test execs to
believe that there is a one size fits all solution (in terms of a
GUI).

One final thing to note is that for this to be a useful project, many
LabVIEW programmers must adopt it for use. Does this seem feasible?

Please help out by going to OpenG.org and declaring your interest as
well as chiming in with your thoughts.

URL too long to post:
OpenG.org -> discussion forums -> Pkg Other -> Open Source Test
Executive.

[magyar]

I don't know if this will help you at all, but this is one possible approach for a simple test sequencer...

I created a test sequencer that is based on an idea I saw in LTR.
In the Lab, where I work, we have many instruments with their own LabVIEW drivers. I create a cluster of variables for each device that contain any and all parameters and readings that would be passed to the device and would be read from the device. These clusters are tied together in one huge variable that is a cluster of all the device specific clusters of variables. I call this very complex cluster of cluster of variables the "gigacluster".
Each subtest is handled by a VI with the gigacluster as an input and as an output.
I use the messaging capability to keep a snapshot of  the state of this gigacluster.

a) Recording a sequence:

When a subtest executes, for example, we set a programmable power supply to 12 VDC, that value is registered in the gigacluster.
This snapshot of the gigacluster is put in an array of the gigaclusters. Each subset will modify the appropriate variable in the gigacluster.
When the test sequence is complete, it is flattened into a string and saved as a text file.

b) Running a sequence:

To run a sequence, the recoded text file is unflattened to become an array of the gigacluster. As each subtest is executed one after the other the variables saved will be sent to the appropriate device.

c) I can edit an existing test sequence.

There one major limitation:
If the size or makeup of the gigacluster is changed (for example, when we add another device) the previously recorded test sequences can not be played back anymore.

[mikeporter]

For a test executive like this to be truly useful in the environment where test executives will typically be used, the code has to be built from the bottom up to depend upon database technology to store both results and test setups. Data is useless without context and without a database it's impossible to reliably capture the context for test data in any but the most trivial of applications.

Moreover, there is no good reason for avoiding databases. There are excellent Open Source DBMS packages available and the facilities for accessing them are built into Windows. In addition, Unix platforms of various kinds have been talking to databases for decades so I would have a hard time believing that it would be too hard to get the Unix, Linux and Mac versions online. In any case, the structure could be written such that there is an isolation layer between the data management subsystem and the application layers that makes the choice of database--and even the database structure--a non-issue in terms of compatability.

Storing setup data in a file will make this system a non-starter for any sort of serious application.

Mike...

[Jim_Kring]

TJ: We have just created a new discussion forum (here) at OpenG.org for discussing the Test Executive project.  I am sorry that I have not had enough time to spend on this project, personally, because it is very much needed.  I will continue to support any efforts by facilitating collaberation and helping with admin of project resources.  Please start up any discussions on the OpenG forums and hopefully we can get this stone rolling again.

Cheers,

-Jim Kring

[Jim_Kring]

Mike: I agree.  Database is critical.  Maybe the project can use the LabSQL toolkit for starters and it will give us a good excuse to start working on some cross-platform ODBC toolkits.