05-07-2020
02:42 PM
- last edited on
11-07-2024
03:48 PM
by
Content Cleaner
No, you will need to use multiple tasks. One task has one timing rate. Your cDAQ chassis should be able to do up to 3 analog input tasks. You'll need two Create Channels, two Timing, etc. Make sure your Read functions are either in separate, independent loops or that they read the same amount of *time* worth of data. For example, if task A reads at 10 kHz and task B reads at 2 kHz, you'll need to read 5 points of A for every 1 point of B (for example, read 500 samples per read from A and 100 samples per read from B). This is to make sure your loop isn't waiting on one over the other. If you try to read 500 samples from A and B, then A will return 500 samples very quickly, then the loop has to wait for B. By the time B has 500 samples, A will have 2500 samples in its buffer, which will overflow quickly (and be out of sync with B *immediately*).
I recommend multiple loops. Generally speaking you only want a single "timing" thing per loop. Having two DAQmx Reads in a loop means you have two timing sources (since both block until they're done). Since you're reading two devices on the same chassis, they have the same base clock so they will always be in sync. This is not true for multiple devices that aren't hardware-synchronized. For example, if you used two separate cDAQ chassis, you'd have to connect their timing circuits externally, otherwise you could get drift leading to a buffer overflow (though this would probably take a while to actually drift enough to matter).
More reading:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MYRSA2&l=en-US
05-12-2020 05:13 PM - edited 05-12-2020 05:19 PM
Hi NI Community,
I'm working on a simple VI to collect data. I'm encountering some issues with sampling rates and data collection speed.
Currently, I have 8 channels set up on the 100kS/s analog input module and trying to collect sine wave signals on Channel 2 and Channel 7.
Please see the images below for the setup and outputs. As you can see, it is taking quite a long time to plot a 5kHz sinewave (CH7 waveform). I know there is something wrong with the sampling rate and acquiring speed. How do I correct my set up so that it outputs it correctly? I want to collect data at 100 kS/s and display that data on plots then save it at the end of the run.
Channel 2 is collecting data from a 1kHz sinewave
Channel 7 is collecting data from a 5kHz sinewave
Time (x-axis) on plots is Current Time - Start Time in seconds.
Here is my set up
Here is the output
Thank you!
05-12-2020
06:09 PM
- last edited on
11-07-2024
03:49 PM
by
Content Cleaner
You have ever growing arrays. That causes a lot of memory allocations, which can get very slow. So here are a couple of suggestions:
1. Change your XY graphs into Waveform Charts or even a single chart. A chart holds a history, so you just have to wire your array of waveforms straight to a single chart and it will plot all of the graphs, including the timing information (part of the waveform data).
2. For logging, I HIGHLY recommend you change from saving at the end to save as you go. Use a Producer/Consumer setup so that your logging happens in parallel with the data acquisition. They will then run at whatever rates they need to and you will not have infinitely growing memory issues.
05-12-2020 08:02 PM
Thank you for your response.
I have an issue with the data saved in my text file. I'm trying to get 100kS/s but it seems like the sampling rate is not correct. What can I do to fix that?
In my text file, I see the below. As you can see, that is not 100kS/s
Time (s) CH1 CH2 CH3 CH4 CH5 CH6 CH7 CH8
0.013 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.013 -0.003 -0.004 -2.486 0.003 -0.000 -0.011 -1.604 -0.002
0.013 0.000 -0.000 -1.567 0.003 -0.000 -0.005 1.320 -0.001
0.013 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.002 -0.002 0.811 0.001 0.002 0.005 2.419 0.003
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 -0.002 -0.000 2.433 0.003 -0.000 0.007 0.172 0.003
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 -0.002 -0.002 1.802 -0.001 -0.000 -0.001 -2.315 -0.001
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 -0.003 -0.002 -0.499 -0.001 -0.000 -0.012 -1.606 -0.004
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.000 -0.002 -2.338 -0.001 -0.002 -0.009 1.319 -0.001
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.000 -0.000 -2.001 0.003 -0.000 0.001 2.417 0.001
0.014 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.014 0.000 -0.000 0.195 0.001 0.002 0.007 0.174 0.003
0.015 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
0.015 -0.002 -0.004 2.211 0.001 -0.000 -0.001 -2.315 -0.001
05-12-2020 09:00 PM - edited 05-12-2020 09:00 PM
Hi BertMcMahan,
Thanks for your suggestion. I've created a simple VI for data acquisition and I'm having problems with getting the correct sampling rate. When i collect data and print the data into a csv file, it doesn't look like I'm collecting 100 kS/s . I would expect to see 100,000 samples in 1 second. What did I do wrong here?
05-12-2020 10:56 PM
First, get rid of all the constants 0 through 7 on the Index Array. You don't need them. Unwired, those indices default to 0, 1, 2, ....
A big problem I see is that you are initializing the shift registers with an array of doubles, but are building onto that with waveforms. You can even see the coercion dots on the Build Array showing the waveform is being coerced to something else. First, that means the output is an array of doubles, not a waveform, thus you've lost all timing information that is built into the waveform.
Second, and perhaps most importantly, the appearance of the index array makes it look like a single value is being built onto the array. Thus that entire waveform is being coerced into a single value, and you are losing the vast majority of the data. If you right click on the Build Array and select Concatenate Inputs, it *may* help.
But the real solution is to initialize the shift registers with a waveform, and use waveform functions to append the waveforms together.
But the actual best solution is to follow the advice in earlier messages to send the waveform data to a separate loop through a queue in a producer/consumer architecture and continuously write to file in that loop as it receives data.
05-13-2020 01:47 AM - edited 05-13-2020 01:47 AM
Hi Victor,
@victor55 wrote:I have an issue with the data saved in my text file. I'm trying to get 100kS/s but it seems like the sampling rate is not correct. What can I do to fix that?
In my text file, I see the below. As you can see, that is not 100kS/s
The problem is the way you are creating this "time" column data!
You are reading 10000 samples per DAQmxRead call for each channel, but you only create a scalar (single) value for the Time axis.
Possible solutions:
05-13-2020 12:03 PM
Thank you for your response! I'm currently working on the Producer/Consumer loops. I have a question about concatenating the array of data. I tried that and it seems like it kind of fixes the logging problem but the data is now in a single column instead of 8 columns for each channel. I'm looking for a way to fix that, how can I split that into 8 columns for each channel separately?
Thank you!
05-13-2020 12:22 PM
Thanks for your answer. How do I solve the time issue?
The way I calculate time is (Current Time - Start Time) and I assume the loop is executing 100kS/s due to the settings I have at the Timing palette.