Is diadem the best solution to store test limits and parameters

[ChrisB Bacon]

I understand that diadem is the best repository for test results for analysis and reporting. However can I make use of the database structure to store test limits and instrument setup values as a TDM file that I can call upon in a VI.

If so, is it possible to extract from the TDM file only the values that I require.

For example.

Widget1 test requires min/max values A,B,C and instrument setup values for condition 1,2,3

Widget2 test requires min/max values A,B,C and instrument setup for condition 4,5,6

If this is the case would it make sense to have 1 single TDM with all values and parameters or seperate TDM for widget1 and widget2 etc etc..

Regards

Chris

[Brad_Turpin]

Hi Chris,

This question has come up in one form or another many times over the last several years, actually predating the DataFinder.  I think the honest answer is that the jury is still out as to whether DIAdem and the DataFinder offer a good general-purpose data management and reporting combination for manufacturing test data.  Certainly I have created numerous proofs-of-concept to show prospective customers that it can work and what they can expect from DIAdem and the DataFinder with their data.  There are some cases where I think DIAdem and the DataFinder are hands-down the best tool on the market, and there are other situations where DIAdem and the DataFinder can still do the job but it's a bit of a stretch, and then there are high-end situations where other tools are the better fit.

I'll try to keep this reasonably short, but I think this is a question many will be interested in reading about, so I want to go ahead and post a few points to clarify those "different situation" comments above.  DIAdem and the DataFinder become a much more compelling fit when you run lots of different types of tests, such that the number of results is variable from one test to another, or the result quantity names and units are different from test to test, or the analysis/reporting required is different from test to test.  High mix data plays to the strengths of DIAdem and the DataFinder, because the DataFinder is a self-configuring and expanding data base, and DIAdem is a general purpose analysis and reporting tool and is very flexible.  If your acquired data has a very static format, on the other hand, then it would take much less effort to set up and maintain your own relational data base and create one analysis and reporting solution that would never need to be expanded.

DIAdem and the DataFinder also excel when the overall data amount is not astronomical and when the data consumers are all on the same LAN and are willing to install DIAdem to look at the data or create reports.  Many times in a manufacturing test setting a web interface is requested so that the data consumers can be anywhere in the world and need have only a web browser to interact with the data.  DIAdem and the DataFinder are fully compatible with Citrix and other Windows Terminal Services layers, but that does not come built-in with DIAdem 10.2 and the DataFinder Server Edition 1.1.  Both DIAdem and the DataFinder can handle VERY large data sets, but if you need high-end server options such as data base backups, triple-redundancy, complicated user-definable data access privileges, etc., then a conventional relational data base such as SQL Server or Oracle are going to have more to offer.

Note that the DataFinder data base is an indexed compendium of information stored in flat files and is always tied to those flat files.  If you add or remove or edit a data file, the DataFinder will automatically update the corresponding records-- there is no way to sever this link and use the DataFinder in a file-less mode.  The best way to organize your manfacturing data in these data files is to expose your single value, named data results as properties on the file, group, or channel level.  This enables you to query on the values of those properties.  TDM files used for this purpose will index very quickly but will have a large footprint on disk, since you're storing this information in XML.  If file size is an issue, TDMS files index at least as fast and would have a smaller disk footprint.  ASCII files are actually surprisingly efficient for storing manufacturing data.  If you happen to be using TestStand, note that there is an ATML DataPlugin on www.ni.com/dataplugins which you can use which will automatically expose your measurements as properties in DIAdem and the DataFinder.

Ask as you have additional questions,
Brad Turpin
DIAdem Product Support Engineer
National Instruments

in environments higher volume your data is, on the other hand, the more we have to be careful to make sure that DIAdem and the DataFinder

[ChrisB Bacon]

Brad,

Thank you for the low down DIAdem.

You have confirmed what I was thinking, that, because of the dynamic nature of the DIAdem and the using datafiner to extract data elements. It looks like this may have some mileage.

I currently have LV8.5 and DIAdem10.2.

The test which I wish to perform are, as you described. That is, approximately same test methodology, on different type of similar UUTs, using different setup values and different test limits dependant on the UUT.

This is not a high volume manufacturing test exercise, but an attempt to automate some aspect of development tests to ensure repeatability, correct test values and end data quality.

What I'm hoping to construct is a system where, dependent on the UUT, pulls setup values and test limits into LV .vi, execute the tests and the obtained test values + the test limits are written to a TDM for tarting up into a report.

I have experimented with LV storage pallete ie WriteData[Channel/Group] with varous degrees of sucess using simple numerical test data, together with trying to understand how DIAdem organises the data into an TDM object.

You mentioned that you had demonstrated some proof of concepts with manufacturing type tests. Would it be possible to share some low level demos to show the interaction with a LV test.vi using setup values obtained from datafinder, adding results and exporting to DIAdem.

Regards

Chris

LV - basics I&II

DIAdem - fresh out the box

[Brad_Turpin]

Hi Chris,

Cool, so you're squarely in the high-mix low/med volume quadrant that we know DIAdem and the DataFinder address well.  I would actually recommend using TDMS files instead of TDM files, and also using the atomic (yellow) TDMS VIs instead of the "Write to Measurement File.vi".  Sooner or later you will need to add a property where the property name comes from a variable, or you will need to construct multiple groups to organize your data, etc.  With manufacturing test data TDMS has the advantage over TDM that it stores the info in binary as opposed to XML, which ends up with a much bigger disk footprint.

I am happy to share examples and techniques from my previous experience based on your detailed needs-- feel free to email me at brad.turpin@ni.com

In general, though, LabVIEW will not need to interact with the DataFinder or DIAdem.  LabVIEW just acquires the data and stuffs all the relevant information into a TDMS file that it puts in a Search Area (Windows Folder) that the DataFinder monitors.  Then independently the DataFinder notices the new file, automatically indexes the parametric data and adds records to the data base for you.  At some later time when you query the DataFinder from DIAdem, you will find this new data is returned, along with all the older (relevant) data.  It is possible for LabVIEW to nudge DIAdem to go ahead and create a standard test run report for each acquired data set, if that's desirable.

There is no way for LabVIEW 8.5.x to directly query the DataFinder for information, so any setup information LabVIEW will have to be stored somewhere else.  This is something we'd like to improve moving forward, but that's where we are right now.

Brad Turpin
DIAdem Product Support Engineer
National Instruments