Creatively importing data from Excel 2003 using Labview 8.2?

[Erik_1]

The VI I am currently writing will be used on a test station that performs automated valve tests.

With that said, what I am trying to do is allow the user to configure their specific test sequence via an excel spreadsheet. Since multiple components will be tested, I was envisioning using a separate sheet for each type of valve (the various valve models require different test conditions). Ideally I would like to configure the VI in a way such that when it imports the data from excel it also reads the sheet names (which will be the names of the specific valves) and generates a selectable pull down menu within labview that, when selected, will run the appropriate test sequence (as defined by the data from the sheet).

Just to clarify here is an example. For simplicity lets say the user wants to test two different valves, Valve-1 and Valve-2. So they generate an excel spreadsheet with two sheets, one called "Valve-1" and the other "Valve-2". Within each sheet the user inputs their test conditions (pressures, test cart component states (facility valves, flowmeters, etc.), and the corresponding times they might want these parameters to change). What I would like is for the program to prompt the user, when it is first run, to import the test config spreadsheet - once this happens I would like the program to generate a pull down menu with two choices - Valve1 and Valve 2. When the user selects either of the two choices and clicks "execute" the VI will run the test sequence defined by that sheet in the spreadsheet.

Is this possible? How might I go about accomplishing this?

Thanks!!!

-Erik

Message Edited by Erik_1 on 06-26-2007 05:28 PM

[mikeporter]

There are certainly ways of getting data like you are discussing from Excel spreadsheets (check out the examples that ship with LV) however it strikes me that you are trying to make the spreadsheet act as though it were a database. Why not simply use a database? It would provide all the flexibility you are envisioning now, expandability for the future - all in an application- and platform-independent form.

Moreover IMHO, from the LV side it's also easier than messing around with ActiveX interfaces that can (and do) change at the drop of a hat.

Topping it all off is that the software to do all this won't cost you a penny. The database connectivity? It's called ADO and is built into Windows. The database itself? There are a variety of solutions that cost nothing: Oracle Express Edition, Microsoft Desktop Engine (MSDE), Jet (also built into Windows) and a large variety of industrial-strength open-source databases. The LabVIEW drivers? I can send you those...

Mike...

[Erik_1]

I actually do not have any experience using databases and I'm relatively new to using LV. Where would you recommend I look to learn about these topics? I do have time constrains for this project - do you think learning how to utilize databases in my code is going to take a significant amount of time?

[mikeporter]

How constrained are your time constraints and what is your technical background?

Mike...

[Erik_1]

The complete VI needs to be written and fully debugged within the next month (and there is quite a bit of other functionality that needs to be incorporated other than this autosequence/config stuff).

As for my background - I have a master’s degree in aerospace engineering and I have used labview in the past. However, my previous experience was relatively limited - it could be summarized as basic data acquisition and limited control. This project is certainly much more technically challenging than any other project I have worked on.

The test station itself (not the test article - the test article could be one of many different 2 or 3-way valves we use) will have 16 pneumatically actuated valves, two programmable power supplies (RS-485), three programmable mass flow meters (RS-485), two electronic pressure controllers, a gas boost pump, high and low pressure GN2 tanks, and a range of various other sensors. Ideally the system should have two modes - manual and automatic. The manual mode would be utilized when the system is being used for testing other than what can be specified in the excel config file. The automatic mode will step through the sequence contained in the excel spreadsheet, but it also has to incorporate other tests (i.e. there will have to be some sort of pause in the sequence where the program asks the user to visually inspect the valve and the program will not continue until the technician verifies that the valve is free of damage – things like that). There will have to be a number of control loops to open and close valves in order to maintain tank pressures – and lastly the program needs to output a nice clean test report at the end that summarizes the data (with any applicable plots or notes made by the technician).

Feel free to ask any additional question - your advice is very much appreciated. 

-Erik

Message Edited by Erik_1 on 06-26-2007 07:18 PM

Message Edited by Erik_1 on 06-26-2007 07:19 PM

[Erik_1]

As for the daq hardware - I'm using a cDAQ-9172 chassis with a variety of analog input, digital I/O, and relay modules.

And as an added bonus, the electrical functional tests need to record data at 1kHz - which this chassis doesn't do easily.

-Erik

[mikeporter]

Wow. A month. From your description this is definitely the kind of applications that needs a real database sitting under it. The aerospace industry gives a whole other reason for having a database: data security and validity. Unfortunately given the time constraint you have and the new things that you would need to come up to speed on, it doesn't sound reasonable to get a database into it unless there were some way to multiply the man-hours stuffed into the next month.

Will it be just you building this application, or will you have help? Also is this an application that you will have to opportunity to come back to and enhance or is this system being delivered and that is it?

In terms of general structure for the application, everything has to be done in a very modularized fashion. Check out this thread, it discusses a bit about how a modular test system could be structured and I included some code that might be helpful. The basic idea is to create a software backplane that test modules plug in to. If there are additional developers available this simplifies handing off development duties because you have a standard interface they can build against.

Mike...

PS: I know this might seem like an odd question, but you aren't located on Long Island are you?

[Erik_1]

Thank you for the advice and direction Mike. To answer your questions…

I am currently the only engineer developing this application – this probably will not change over the next month or so. There are a number of LV developers here that can assist me on occasion but for the most part they are extremely busy and do not have time to walk me through anything significant. This system will be used in house and is not going to be delivered – so enhancements or modifications down the road are certainly possible (and probable). The first iteration does not necessarily need to have every bell and whistle but it does need to be functional (of course) and the automatic sequencing is very important (for test repeatability reasons).

It sounds like utilizing databases is not a feasible solution given my time constrains and it also sounds like using Excel is not the proper solution – so for now I might just “hard code” the automatic sequences into the main program.

A question about that: say I have a 13 part test that I want to step through test by test – if I code that into a 13 frame flat or stacked sequence (which is also contained within a while loop such that when the test completes the user can select and run another (separate if desired) test) how can I force the program to step through the sequence based on specific events (like the user inputting the valve serial number or selecting a check box to indicate that the valve is free of damage)? I don’t want to keep running through the while loop, I just want to step through the sequence one frame at a time waiting on user inputs or test results between frames.

What I currently have configured is an event structure within a main while loop that sends a notifier when the user makes a selection – like to run in automatic or manual modes (or do a variety of other things – log data, etc.). I have attached an example of how the automatic loop is configured – I have placed a 13 frame stacked sequence in the “2-way solenoid” case to simulate the 13 part test I would like to run on that component. Like I said previously, I don’t want to keep looping, I just want to step through the sequence frame by frame and then return to the while loop so the user can make another selection. Any feedback on this would be great.

Thanks again for all your help Mike!

-Erik

P.S. Actually I’m out in southern CA – a few miles south of LA.

Message Edited by Erik_1 on 06-27-2007 12:13 PM

[Joe_H]

Well I personally think that databases would be feasible for you to use they are not that hard and are certainly better than activeX. You also should not use a stacked or flat sequence structure. Instead use a que type statemachine with events. have a look at the examples if you do not know what these are.

Just a question out of the blue, have you thought about teststand. In teststand you just build the test modules and let teststand take of the database and reporting function. 

[Erik_1]

Until I reviewed the link Mike sent I had not heard of teststand - I need to examine it in more detail. It is important to note that my sequencing is not strictly time dependant - there are certain portions that are but there are other portions that require the technician to perform leak checks and visual inspections (so the sequence needs to wait until he/she completes the required task before continuing).

Like I said previously I am definitely a novice LV developer and my particular background is not in electronics or software development - however I certainly feel that I'm capable of learning. I recently read the textbook "LabVIEW For Everyone" by Travis and Kring which introduced me to some new concepts (state machines, ques, notifiers, etc.). I will go through the state machine examples and try to figure out how to implement it into my code.

-Erik

Message Edited by Erik_1 on 06-27-2007 01:07 PM