How Do You Store Test Results

[Just Glen]

OK, so this is really sort of a survey. I'm developing a new test system and am toying around with how to store the data. Obviously one alternative is to use TestStand's built in database capability, but in looking at the tables it seems like post-processing could be a bit of a pain (it's not instantly obvious to me how I would author the proper queries, etc).

Another alternative would be to create my own database and then figure out how to get all of the hooks in the proper places to make sure that data is properly stored when it should be, etc. This could result in some fairly complex database design, teststand foo, etc.

So I'm wondering what the community as a whole seems to favor: Use TestStand's built in database stuff or roll your own?

[Blair_Hogg]

I found that the results are being stored in html documents, and created an Excel VB app to load the directory, then load and parse each html document and store it in Excel tables import into Microsoft Access.

There is probably an easier way to do this than the way I did it, If I would just read the manual.

Blair

[RayFarmer]

Hi Blair,

This seems to a lots of work when you can just enable Database logging in TestStand and write the results direct to an Access database, and that's just using the default setup.

Regards

Ray Farmer

[trussell]

I've tried several different methods like individual DUT text files, appended text files, databases, and such.  The best method I've come up with is using a text data file with comma delimiters.  The catch is to log each DUT data as a two dimensional data.  The first columns of each line contian DUT header information such as serial number, date tested and such.  Then a test column, name, and p/f.  After that each result that relates to that test is added for each column.  It takes on the following format.

dut1,date,sn,operator,test,0,p,r1-LL,r1-MV,r1-UL,r1-p/f,r1-description,r2-LL,r2-MV,r2-UL,r1-p/f,r2-description,...etc

dut1,date,sn,operator,test,1,p,r1-LL,r1-MV,r1-UL,r1-p/f,r1-description,r2-LL,r2-MV,r2-UL,r1-p/f,r2-description,...etc

Then then next DUT will be

dut2,date,sn,operator,test,0,p,r1-LL,r1-MV,r1-UL,r1-p/f,r1-description,r2-LL,r2-MV,r2-UL,r1-p/f,r2-description,etc

dut2,date,sn,operator,test,1,p,r1-LL,r1-MV,r1-UL,r1-p/f,r1-description,r2-LL,r2-MV,r2-UL,r1-p/f,r2-description,etc

A little wasteful on memory, but memory is cheap.  The advantage of doing it this way is you can pull into a spreadsheet program, then insert blank line at top, and then insert the data autoformat.  Now you have a simple database without the overhead of the database.  A couple a seconds and anybody of any skillset can pull up the data and it makes sense.   I also divide the files into logical sizes such as work week, quarters, or year so the data files don't get too large.  I've looked a data management programs as well.  They are nice if you want to invest the time to understand what's going on.  Problem is, most people viewing the data files want information fast when they need it.  They are not willing to invest time to install special programs and invest the time to get the information they need.  Just some thoughts. 

[Blair_Hogg]

Thanks, Ray - i probably should have picked up the manual and looked it over before spending the amount of time I did writing the VB code to convert the html files. The system was created for us by a consultant, and he was the one who told me about the html files. This is also our first system with TestStand, and I have been learning new things about it continually.

Blair

[Dennis_Knutson]

I think using a database is the most robust solution and the queries are pretty straightforward. You'll need a couple of inner joins when trying to get to the step results but for things like yield information, you only need the UUT Results table. Data can be imported directly into Excel if you ever need to do that. I like all of my data in one place. I don't have to manage multiple files or do any merging. I was also lucky and got the support of other departments (including IS). Queries are available on our company intranet. Anyone with a web browser can get up to date information at any time.

A word of warning though. Using ms Acess might be find for a small number of test stations or for only a few queries. Things start to fall apart when you are saving a lot of data from a lot of stations and several people are doing a query. Access is not very good at handling simultaneous requests from numerous sources. MySQL, SQL Server, and Oracle databases are much more scaleable and can easily grow with you.