06-23-2010 01:28 PM
Alright,
I'm relatively new to LabView software. We are using a NI-DAQ 9237 (Wireless) to acquire load data (strain) from a load washer on a bolt.
My problem has been recording data in the manner I want to. Simply put, I just need a continuous sampling rate of 10Hz. Meaning, I want SE to write 600 data points to a text file per minute. I've played with the "buffer" and "rate" in the Step configuration (where buffer is the "samples" variable).
Will SE not simply run the project and update the data file in a live fashion? (i.e. not waiting till the project is stopped to record?)
I don't need the displays to do anything.
I've tried various settings such as using 10Hz for rate, and 10 for samples, but over a course of 3-4 mins I've generated 300-400k data points. This will not do, as I am planning on running this test for at least 48hrs at a time, and this will require lots of disk space and effort in processing the data manually etc etc.
There has to be a simple setting for logging data directly to the disk live. Any pointers?
Thanks
06-24-2010 10:26 AM
Can you post your .seproj file so we can have a look at your settings? Some initial questions just to get you going...
Are you Recording data (logging to file using the Record tab) or are you saving to ASCII using the Save to ASCII step?
Does the number of samples exported to the data file need to match the sample rate? i.e. for your post-processing needs do you have to see 600 sample points if you sample for 60 seconds at 10hz? Or can you sample at 10hz and have it export an average of x number of samples (a smoothing filter basically)?
The reason I'm asking is that will be the difference of whether or not to record the raw signal coming from the DAQmx Acquire step or a DBL signal- which is the converted raw signal passed through something like an Amplitudes and Levels step (converted to DC and necessary to view the data in real-time like a strip chart).
Without seeing what you're working with I'll assume you need the full 10hz worth of data and saving with something other than the Save to ASCII step- the suggestions I have are the following:
That's it, when you record 1 min of data you should have a txt file with 600 samples in it.
Again, without your .seproj file it's difficult to know how much of the above mentioned suggestions you've already covered.
Hope that helps, we can elaborate more on DBL signals and DC averaging later if you'd like a much smaller data file.
06-24-2010 12:23 PM
Hmmm...
I just reread your post.
It seems as though you're trying to solve two seperate issues.
@lhunziker wrote:
Alright,
Simply put, I just need a continuous sampling rate of 10Hz. Meaning, I want SE to write 600 data points to a text file per minute. These are simple Timing Settings discussed in my original reply
Will SE not simply run the project and update the data file in a live fashion? (i.e. not waiting till the project is stopped to record?) This sounds like a sperate issue. Yes, SigEx updates the data file in a seudo-live fashion but you cannont (or it's recommended NOT to for obvious Windows file control reasons) open the data file as it's being written to.
I don't need the displays to do anything. The only way to see SigEx "update the data file in a live fashion" is to view it in a graph. Do you need to view the data in real-time over the course of this 48hrs? If so you WILL need the displays to do something, it takes some simple configuration but easily done. Clairfy on this please and we'll get you going in that direction.
I've tried various settings such as using 10Hz for rate, and 10 for samples, but over a course of 3-4 mins I've generated 300-400k data points. Again, this sounds like Timing Settings not being set properly This will not do, as I am planning on running this test for at least 48hrs at a time, and this will require lots of disk space and effort in processing the data manually etc etc. This sounds like your oversampling and afraid of running out of disk space? Lets work on your Timing Settings. Also please re-read my original question on wheather or not you actually need all that resolution (i.e. all those sample points over a 48hr period).
There has to be a simple setting for logging data directly to the disk live. There is; SigEx does log data to the disk live (actually it writes to a buffer then dumps the buffer out on the data file every so often, so it's not like it's writing to file one I/O every sample point) The only way to "View" this data is in a scope or strip chart. Any pointers?
Thanks
I just did a test recently where I had to monitor relaxation of a tank strap setup by logging load washer data. My sample rate was MUCH lower than your needs, I was sampling 1/sec for the first 3 hrs then once every 5min after that for 48hrs.
I was logging to an ASCII file but had the display running the real-time graph so I could monitor loads over time...
06-24-2010 01:55 PM
Thanks for the info.
Fortunately, I spoke with an app engineer over the phone yesterday and have managed to get the settings tweaked to where I'd like them. Basically, we are using a 9237 which has a MINIMUM actual sample rate of around 1.6kHz. So the issue was that we need to run at 10Hz for long periods of time as we are trying to model and collect data on a wind turbine which would have a driving force at around 2-3Hz, so we wanted to get enough resolution to see those oscillations and what effect they had on the loading of a few particular bolts in the blade system.
But we worked around this massive sample rate by simply using the Processing->Subset and Resample step (Only available in full licensed edition/eval). Just using a resample with a dt=100m gave us an output to the .txt file of pretty darn close to 10Hz. And I guess the whole "live" update will not be a big deal. Generally, the relevant data will be collected overnight (when the turbine really operates at capacity), and we will just stop the run during the day and analyze the data as there is much less wind for operation during the normal workday.
Thanks though! Your help and insight is greatly appreciated.
06-24-2010 02:23 PM
Cool, glad you got it figured out.
Thanks for checking back in with your solution. Too often people don't follow up with information that can be useful for others.