04-07-2023 10:55 AM
I am using DAQmx to measure the acceleration with accelerometers. I have a sample frequency of 100 Hz, but at every sample time I get an array of about 16 samples. Why is this and which one is the latest sample, the first or last on in the array?
04-07-2023 12:01 PM
What device are you using, can it sample at 100 Hz?
Get rid of the timed while loop, use a normal while loop. No need for sequence structure, get rid of it. Set the number of samples to ~ 0.1 s time the Sample rate. The DAQmx read will control the loop rate.
04-07-2023 12:52 PM
I doubt it can hit 100 Hz, as the dt value in your waveform array is 0.000605 seconds (or 1652 Hz). I think most of NI's vibration acquisition hardware use delta-sigma converters, which have some pretty strict limitations on sample rates.
Your timed loop is set to operate at 10 ms intervals, which will result in errors there. Throw an error display on the output and add a Stop to the loop terminal (and get rid of the timed loop). I bet you get some kind of buffer overflow error that's not stopping anything.
I'll admit I don't know why you're only getting 16 samples, but I bet there's some sort of buffer overflow shenanigans that are throwing errors you don't see. Generally, a 100 Hz continuous DAQmx acquisition should get you a 1 kS buffer. This would fill up in about a second though.
Theoretically you should be seeing more samples come out, since the DAQmx call won't be blocking, and this should work, but I'd fix your sample rate issues first. It's generally advised to read a known number of samples and let DAQmx handle all of your timing. Polling this way will give you variable results, and may return different numbers of samples each cycle.
04-07-2023 01:00 PM
Hi Britt,
@BrittClaus wrote:
I have a sample frequency of 100 Hz, but at every sample time I get an array of about 16 samples. Why is this and which one is the latest sample, the first or last on in the array?
Simple answer: read the manual of your DAQ device to learn about the allowed/supported sample rates!
04-07-2023 01:04 PM
Edit to my previous post, forgot to wire the read input, see below. Make the change in the attached VI.
04-07-2023 09:13 PM - edited 04-07-2023 09:14 PM
Several others have brought this up, here's the whole scoop.
You are apparently using a device with a minimum sample rate of about 1.6 kHz. When you ask for a slower rate, the device uses the minimum it supports.
Then, further, when you leave the '# samples' input to DAQmx Read unwired while running a Continuous Sampling task, DAQmx defaults to retrieve "all available samples". Because your task was sampling at ~1600+ samples/sec and you were retrieving all the new samples every 10 msec, it entirely makes sense that you typically retrieved 16 samples per iteration.
I made a very slight mod to the code mcduff posted so that it makes use of the *actual* sample rate rather than the requested one. (The same construct of querying for an actual sample rate can be seen in many of the DAQmx shipping examples for analog input.)
-Kevin P
04-23-2023 07:07 PM
Use the Example Finder to search examples by keyword, task, supported hardware, etc.
DAQmx also ships an example that supports continuous acquisition from IEPE accelerometers:
<LabVIEW>\examples\DAQmx\Analog Input\IEPE - Continuous Input.vi
Open this example. You can use it as is or save a copy for you to modify. If you remove the features you aren't using (such as triggering and logging), you get code very similar to code that Kevin and mcduff posted.