Test Rig Questions

[JWinstanley]

So i have a new project coming up shortly. We currently have multiple test rigs that are driven by labview on different sites within our company. Each test rig has individual programs created for the part it has to test. Each part is virtually the same. 

The plan is to replace this with a generic programme that loads variables from a database dependent on the part number selected. 

The equipment will be the same on all test rigs. I know there is a few issues to sort out with networking across multiple sites but the plan is to create the generic test program and have a database with all the input variables stored on the network server. Whent the program is excuted it just pulls the variables required fromt the database. 

This means when a software update is made its just gets rolled out to each site seemlessly. I am thinking of using an excel database with each row being a different part number and each colum being a different variable. 

Then when the program is finished the results will get saved to another database with the results. As the database is stored on the company server anyone can then go and find the results for any part tested at any of the sites when ever. 

I know the decription above is quite vague but im just looking for guidance to see if this is the best way to go about it, Is excel the right tool to use as the database? Is labview the correct software platform to use rather than NI Teststand etc?

The instruments connected to these rigs all have labview drivers and are off the shelf equipment such as keithly voltmeters, oscilliscopes etc. 

[Kyle97330]

The answer to the question "Is excel the right tool to use as the database?" is "No" ~98% of the time.  It may seem like the right tool because everyone already knows how to use it, but the number of issues you'll have with formatting, permissions/access control, file locks, lack of change tracking, and who knows what else far exceeds the benefit you get by using a tool everyone already knows how to use.

Use a proper external database, and then if you must you can rig up an Excel sheet to download the tables from it so people can look at them with a familiar tool.  If you must, make a macro so people can upload new lines (making sure just to mark the old lines as obsolete, not overwriting them) so they can use it to upload changes as well.  But don't use it as your back-end.

As for which test platform to use, it's really dependant on what type of testing you need to do.  TestStand seems like it would be a good fit based on your vague description, but it has a kind of steep learning curve for some of its features.

[billko]

---

@JWinstanley wrote:

So i have a new project coming up shortly. We currently have multiple test rigs that are driven by labview on different sites within our company. Each test rig has individual programs created for the part it has to test. Each part is virtually the same. 

The plan is to replace this with a generic programme that loads variables from a database dependent on the part number selected. 

The equipment will be the same on all test rigs. I know there is a few issues to sort out with networking across multiple sites but the plan is to create the generic test program and have a database with all the input variables stored on the network server. Whent the program is excuted it just pulls the variables required fromt the database. 

This means when a software update is made its just gets rolled out to each site seemlessly. I am thinking of using an excel database with each row being a different part number and each colum being a different variable. 

Then when the program is finished the results will get saved to another database with the results. As the database is stored on the company server anyone can then go and find the results for any part tested at any of the sites when ever. 

I know the decription above is quite vague but im just looking for guidance to see if this is the best way to go about it, Is excel the right tool to use as the database? Is labview the correct software platform to use rather than NI Teststand etc?

The instruments connected to these rigs all have labview drivers and are off the shelf equipment such as keithly voltmeters, oscilliscopes etc. 

---

I think you are headed in the right direction!  I think the database thing is entirely up to you.  Think about things like scalability.  Do you think the database will grow so complicated that Excel - or maybe Access - will not suffice? - edit: oh the previous poster brought up stuff I hadn't considered about file locks and stuff with Excel.

Even though you already have stuff like LabVIEW drivers, TestStand is so good at integrating LabVIEW VIs that it is definitely a viable option.  Plus, TestStand has excellent built-in default test results reporting.  (You can get as fancy with it as you dare, too.)  However, a pure LabVIEW solution is equally viable.

Good luck!

[JÞB]

know the decription above is quite vague but im just looking for guidance to see if this is the best way to go about it, Is excel the right tool to use as the database? Is labview the correct software platform to use rather than NI Teststand etc?

The instruments connected to these rigs all have labview drivers and are off the shelf equipment such as keithly voltmeters, oscilliscopes etc. 

---

What you are discribing is a "Test Executive" with a common set of reusable modules.  From your brief but, clear statements, I would definately look into TestStand.  Using 1 sequence per part number with each sequence step calling a common set of modules from LabVIEW libraries.  Specific things like timits, and timing (Parameters in TestStand speek) can be handled several different ways and would depend on your specific needs.  Reporting, and sight management options becomes nearly automatic and needs to be only done once.

Now, I'll get into the difference between "Cost" and "Price" (No I do not work for NI sales) TestStand Costs more and there is a learning curve.  In situations like yours it often saves a lot of time in follow on development and change management.  In the long run it saves money by providing commonality among reporting and test modules.  

That is, if its done right the first time Bring in an Alliance Partner to train you up and show you how.