Vibration Test VI...Advice Needed

[Adzel]

Hello,

I am a new LabVIEW user and have been utilizing 7-Express since early February 2005. I have created a vi to do the following:

1. capture a signal on channel 0 (from a hammer via an accel)
2. Trigger based on some given signal level (volts)
3. Upon triggering, capture both the impulse (channel 0) and response (in this case an accel on a cantilever beam).
4. Present both the impulse (ch 0) and response (beam) on a waveform graph.
5. The vi also shows FFT-Power Spectrum and Power Spectral Density and Magnitude/Phase/Coherence.
6. The data is then sent to 2-files, one has the entire "history" the other is for Magnitude/Phase/Coherence data only.

The vi runs and captures the waveforms as needed. Issues I am seeing are as follows:

1. Screen-capture: the waveform appear on screen for only an instant (one-loop iteration) and then the waveform disappears.
My fix: a user-enabled pre-set pause switch.
My issue: Is there a better way of doing this?

2. Magnitude/Phase/Coherence is captured...
My issue: ....but it does not appear to be collating and calculating poperly. For coherence it is the average of two consecutive hammer strikes and the beam's response. I would like to see this captured for consecutive (good) strikes only.

3. Data to file. The 7-Express Write data to file collects signals fine.
My issue: How to provide better headers.
My issue #2: I only want the Magnitude/Phase/Coherence averages to go to the Magnitude/Phase/Coherence file.

4. I have attached my vi for review. All help with any of the above will be greatly appreciated.

Thanks!!

[Johnner]

Adzel,

This is good work for a new LabVIEW user. It seems as if the issues you have mentioned (and some additional ones you may not have realized) relate primarily to program execution, so I'm going to focus my comments there.

It's an old saw around here, but you really need to shift your VI to a state machine architecture. Two immediate benefits are that your VI will be simpler for others to interpret, and it will become more clear how to solve issues like your first one below. "State Machine" is easy advice to give, but it can be difficult for a beginner to apply, because there are many different flavors of state machine in LabVIEW. Attached is a simple state machine shell in 7.0 that uses strings to manage the states and contains my general advice for your situation. The use-strings approach is simpler to program, but much less flexible and extensible than using an using an enumerated typedef, so you may want to check out that option instead by choosing File >> New... in LabVIEW and opening up VI From Template >> Frameworks >> Design Patterns >> Standard State Machine.

One other observation I will make regarding program execution is that you may be making a mistake with your tab control. On your diagram, you have the tab control wired to a case structure with separate code inside for the various analyses you perform on the acquired data. As a result, only one of these analyses will be performed in a given loop iteration--not all of them. I think this may not be what you're after. Instead, you could do all the analyses in each loop iteration, and allow the user to switch back and forth between tabs at will in order to view a given analysis. You just need to move all the code outside of the case structure and delete it.

With regard to "better headers" for your saved data: you may need to move beyond the Express VI and start using the lower-level File I/O VIs if you want precise control of the file output you get.

Two things I didn't mention or demonstrate, but would make your code even better after you adopt the state machine approach: using the Event structure to respond to user actions (a Wait for User case, typically) and using a master "program data" cluster to pass data between loop iterations instead of a bunch of individual shift registers. It's best to make this cluster a typedef, when you get to the point of wanting to try it.

Hope this helps,
John

[Adzel]

Johnner,

Thanks very much for the advice and pointers. I am working thru the note carefully and will try the type-def function.

Will let you know how things go.

Best regards,

Adzel