Jump to content

todd

Members
  • Posts

    335
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by todd

  1. 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
  2. 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: --todd
  3. 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.
  4. 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
×
×
  • Create New...

Important Information

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