11-09-2009 11:44 AM
My apologies for having little experience with LabView so far.
I have a set of algorithms for processing voltage that work fine with an emulation (based on added sine and square values). I have acquired a data file from a partner that includes actual data captured, but for a fairly small period of time (~1 sec). To allow me to review the power spectra, and make changes to my controls and observe the outputs, I'd like the data from the measurement file to be read out continuously and simply be interpreted as continously acquired data (even though it's the same data over and over). This is an OK thing to do, as the important features are down in the kilohertz range or higher, so plenty of data samples are available for processing.
Some thoughts I had were:
- I need to make sure the data file works when viewed as a 'loop', so i made sure the cyclic data values at the end of the file returned to the levels started at the top
- I know there is a time field included in the data - is there any way to coerce the reading mechanism or some VI further down to allow looping of that data and simply incremement the time values continuously, similarly to real-time DAQ setups?
- I tried looping EOF to RESET on "read from measurement file" VI, but that just upset later VIs because the dt value went negative
I know I must be missing some basic understanding of LabView... anyone?
David
11-09-2009 11:48 AM
11-09-2009 11:52 AM
I'm afraid that little information isn't helping me a lot. 8 \
11-09-2009 11:52 AM
Hello,
You should read the data from the file one time, before you enter your processing loop, then send the data into your processing loop and operate on it. You would still be using the same data over and over again, you'd save a lot of overhead by not repeatedly reading your file, and you could pretty easily fake a timestamp on your 2nd loop iteration, 3rd loop iteration, etc. Is the dt between points a constant?
If you could post what you have so far, we can probably be of more help.
d
11-09-2009 11:58 AM
Diane,
Thanks for your response. I realized there might be some sort of intermediate VI that I can put between my 'read measurement file' and my filters and other controls that might buffer and replay that data over and over, but I wasn't sure what VI might help with that.
Further, there really isn't much of anything to attach - it's a simple Read Measurement File running to a set of filters and output graphs. I connected the file output to the filter inputs, and when run it stops at the end of the data. When I looped EOF to Reset, it causes negative delta T, which makes sense on the first new value.
Yes, all the data has fixed delta T for all samples. Is there some way to dispense with the time values and just send inherently spaced datg samples to inputs?
If I sound like a beginner, it's because I am.
11-09-2009 12:05 PM
As I said, this file is pretty simple.
Any help in 'looping' the input data would be great. It's 125000 data samples in several 'channels' including a time channel... so about 1 second of data. Samples are all uniform delta T (i.e. 8us each)
david
11-09-2009 12:51 PM - edited 11-09-2009 12:57 PM
I'm not sure if im fully answering your question. But here is a way to read data from a file and loop it/plot it continuously. You just read the file once (as was suggested above) and then reference the array repeatedly. By referencing the array repeatedly(when you reach the end (i.e. end of the for loop), start at the beginning of the array the next time the while loop iterates.), it keeps you from opening, reading, and closing the file over and over (also stated above). You may have to index array in the for loop if your file has multiple columns, and you only want the data from one of them.
11-09-2009 01:15 PM
Hi David,
No need to apologize for / worry about being a beginner! We were all beginners at some point and all of us on this forum are pleased that you are trying things out for yourself and then asking for help when you get stuck, instead of just asking us if we'll write your code for you. 🙂
for(imstuck) posted a nice picture that illustrates where I was going in my answer. I wasn't able to open your code since I'm still using LV8.6...if you want to save it as 8.6 and re-post, I'd be happy to take a look at it for you.
The first question is, do you understand what for(imstuck) shows here? He has the "read from file" function outside the loop. He uses the "create waveform" to change the data type from an array of values to a waveform. The "waveform" data type contains the start time of the waveform (that would be your initial timestamp), the dt value between points, and the actual data itself.
After he creates the waveform, he uses a shift register to pass it between loop iterations. The "append waveforms" function does exactly what you'd think it would do. The graph will continuously update. The FOR loop allows each channel to be processed separately.
So you might find that your waveform graph behaves a bit oddly if you use exactly what is shown in the picture. It will be iterating through each of your waveforms (on the first iteration of the FOR loop it will show channel 1, the second iteration will show channel 2, etc). It will also be appending data to each of your channels on subsequent iterations of the while loop. I expect you'll want to do some tweaking there.
Does any of this help? Or are we misunderstanding your question?
Another thing to note....if you use a waveform graph or waveform chart, then by definition your data will be spaced at even intervals (i.e. the graph / chart assumes that dt is a constant). So if you don't really need your timestamp information, then you might not need to convert your data to a waveform.
d
11-09-2009 01:27 PM - edited 11-09-2009 01:28 PM
So if you don't really need your timestamp information, then you might not need to convert your data to a waveform.
Thanks for pointing this out! I had meant to put it in there but forgot. Also, thanks for the added detail, I didn't really have time to put it all in there. Well, either way hopefully this gave him a starting point.
11-09-2009 01:35 PM
Yes, I think I understand part of it. I'll go back and study the operation of samples in individual paths as well as the composite ones. I don't need the deltaT values, as I want to process and display as uniform continuously captured samples; filters also work this way I think.
I was only a little disappointed that the 'read file' didn't have its own 'loop' method that could simply send the data over and over... I clearly don't understand the top-level operation of the package with respect to data handling and instances, so I'll go back and have another read.
Many thanks to all,
David