todd

Like this?

Just north of Seattle, WA (US) - LV runs my custom ATE to characterize a programmable system on chip (PSoC). It's a reconfigurable analog array + reconfig digital + microprocessor. Someone else here uses LV as an automation interface to the chip's IDE (free download).

Use an 'Event Structure' to handle what happens when the buttons are clicked. Use a 'Property Node' to hide controls and indicators or to switch between tabs in a 'Tab Control'.

If it takes you longer to test each of those options than it does to post the question - then you need the wiring practice.

The problem is that Listbox 2 does not contain the Numerics. The Listbox is underneath the numerics. Perhaps this subpanel (with a better connector-less scheme) will help.

Download File:post-107-1092084358.vi

Download File:post-107-1092084368.vi

I use two 6733 PCI cards. They are not yet supported by DAQmx so you must use Traditional DAQ. There is a promising example called "Continuous Generation.vi" that says:

Continuous Generation writes values to one or more analog output channels indefinitely, until the generation is cleared.  This is timed signal generation, meaning that a hardware clock is used to control the update rate for fast and accurate timing.  It is also buffered generation, meaning that the data is stored in an intermediate memory buffer before it is written to the analog output channels.

This VI writes new data into the memory buffer while the generation is in progress.  First, it fills the buffer with data, then starts the generation.  After that, it continues to write new data into one half of the buffer while the other half is being generated.

--todd

An Open Source Test Executive would need to be extremely modular and flexible, no? I am willing to contribute.

The Data queue is a great idea. I will try to apply that model to hardware configuration data (mainly relay settings) and to the test sequencer. The VCluster could contain elements that describe what kind of processing to perform. Other elements are probably parameter name, data and units.

My test module vi's each have (the following are strung together with errors):

prerun.vi: (recently genericized from project-specific) programs the DUT (unless programmed during last run), lightly configures stimulus and measurement instrumentation (unless configured during last run), and closes relays between DUT and instrumentation (unless ... last run)

dut param config.vi: sends command to the DUT to configure its global parameters

<project name> <param name>.vi: twiddles stimuli and takes measurements to get parameter data (plans to add selective parameter testing using a global bitmask)

|<project name>|save data.vi: (not completely genericized) puts data into flatfiles or a database

postrun.vi: clears hardware settings, unless needed by next run

So, the test executive gets ready then calls a test module by reference based on the sequence file(s).

How do the parameter measuring vi's running in parallel know when to execute? It could be quite handy to be able to drop a new measurement vi into a folder and have it run without changing the test module.

The test executive I've created calls test modules by references. First, each test module sets up benchtop, custom and PCI instrumentation. Next, a series of sub-tests are performed. Finally, 'Save Data' then 'Post Run' vi's are called.

First version:

Each sub-test measures interesting things then updates a test module specific global (which has clusters of: doubles, longs, 1d and 2d arrays of doubles, and other types). The module specific 'Save Data' vi pulls data out of the global then stores the data in flat files or a database, depending on switches.

Second version:

Each sub-test measures interesting things and shows each in an indicator (same variety of data types as the First version). Each indicator's value is converted to a variant. Attributes are added to indicate data level (debug, production) and what to do with the data (1> create a graph showing, for example, gain setting vs gain error; 2> just log the data) then concatenated into a 1d array of variants. This array is concatenated onto the 1d variant array passed into the sub-test.

Now a generic 'Save Data' vi iterates through the variant array doing what the attributes call for. OpenG's get variant names is elegant for creating flat files or for filling a database (saw Jim's SQL insert example).

Now the question. The second version was brought about by obvious shortcomings of the first version. Does anyone care to comment about pitfalls that would cause a third version? (I've left off things such as: throwing data into a queue for graphing and for offline processing like histograms.)

Also, we're up to about twenty test modules (our IC is on-the-fly reconfigurable mixed-signal). We end up with lots of data that needs to be presented against data sheet limits, sigmas, etc. What is the best way to dynamically generate graphs? The Excel Report vi's fall short because some graphs have 13k points.

--todd