LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Control Number of samples in 9237

Solved!
Go to solution

Hello,

 

I'm using a simulated 9174 compactDaq with a 9237 card on it. My intention is to simulate the situation that my client has.

 

My client wants to control the volume size of the aquired data because in this moment the aquisition is very high and the aquisition period it's like 30 seconds.

 

In this moment,  I know that the sample rate can only be:

 

SampleRate = (12800 000/256)/n, n goes from 1 to31

 

My aquisition uses the log option. So, I only start and stop the aquisition and the measured values goes to a tdms file.

 

Doing some tests I got the following results:

 

n (sample rate) , aquisitionPeriod (ms) ---> Aquired samples

31                   , 5000                       ---> 7168

31                   , 1000                       ---> 3584

 

Shouldn't be 5 times less?

 

I hope someone can give a hand on this subject.

 

Thanks and have a good weekand

Software developer
www.mcm-electronics.com





PORTUGAL
0 Kudos
Message 1 of 6
(2,843 Views)

Without seeing code, it's difficult to tell how you know what the acquisition time actually is.  How are you setting your acquisition time? 

 

If you really are acquiring 5 seconds' worth of data, then 1 second worth of data, at the same sample rate, then yes, you are quite right, your acquired samples from the 1 second acquisition should be 5X less than your acquired samples from the 5 second acquisition.

 

I'd have to see the code, or at least obtain more information from you as to how you're determining your acquisition timing, to really know what's going on, but my initial suspicion is that your acquisition time is not what you think it is (i.e. you think you're acquiring 5sec or 1 sec of data, but you aren't, for some reason).  That's also borne out by the number of samples obtained.  5 seconds at 1613Hz ([12,800,000/256]/31 = 1613) should yield 8065 samples, not 7168.

 

Can you post your code, or a small example which demonstrates the problem?  I'll be using LV2009 until my new computer arrives later this week, so could you post any code in that version or earlier?

0 Kudos
Message 2 of 6
(2,815 Views)

Hello Diane,

 

The code is in attach. I saved it to 2009. So... See if you can understand. Because I can't.

 

Thanks

Software developer
www.mcm-electronics.com





PORTUGAL
0 Kudos
Message 3 of 6
(2,799 Views)

Hi there Jorge,

 

Yup, I see some problems.  🙂

 

I assume that your DAQmx Read function is inside your first TDMS subVI (which for some reason I don't have on my computer, so unfortunately I can't look inside it and see what's going on in there).  I note that your task is wired through it.  Otherwise, DAQmx Read doesn't seem to be making an appearance, which would make no sense.  Still, it must be in there somewhere, or you wouldn't be reading any samples at all.

 

Let's go ahead and assume that DAQmx Read is hidden inside that subVI which I don't have and therefore can't open.  🙂

 

When you configure your clock, you specify "Continuous Samples" and a sample rate.  You don't specify the number of samples to acquire.

 

You also don't specify the number of samples to acquire for your DAQmx Read function (at least, you don't wire that information into your TDMS subVI).  That means that DAQmx Read is using the default value of "-1" to determine the number of samples to read.

 

If we look at the help for DAQmx read, we discover the following:

 

DAQread.PNG

 

So, you have your Read task configured to just grab whatever happens to be in the buffer when DAQmx Read runs.

 

All right.  Now let's examine the fact that you have placed the DAQmx Start function AFTER your Read function, instead of before it.  What happens if you do that?

 

If we look at the help for DAQmx Start, we find the following information:

 

DAQstart.PNG

 

In your case, since your Read function runs before your Start function, DAQmx Read starts your task automatically when it runs.  Because you do not have another Read function after your Start function, your Start function isn't actually doing anything.

 

To summarize:  You are not controlling the number of samples which are read, nor are you reading for any specified amount of time.  You are grabbing whatever number of samples happens to be sitting in the buffer when your Read function executes.  That is why you're getting weird and inconsistent results.

 

I would suggest you look at one of the examples that ships with LabVIEW for how to acquire data and log to a TDMS file.  Under "Help", choose "Find Examples".  Choose "Hardware Input and Output"..."DAQmx"..."Analog Measurements"..."Voltage"..."Cont Acq&Graph Voltage - Write Data to File (TDMS).vi" to get the basic structure of what you want to do.

 

You could also consider configuring your clock to acquire a finite number of samples, and then specify the number of samples.

 

Have a look at the attached VI for how to set up either acquisition type (continuous or finite).  I didn't include the datalogging, but the other example I mention above will show you how to do that.  Note that I'm calculating the number of samples to acquire using the parameters in your original post.

 

I hope this helps!

Diane

0 Kudos
Message 4 of 6
(2,784 Views)

Hello Diane,

 

You give very complete solutions. 🙂

 

Let me just add one thing... Using other device (like 6220) and performing a usual aquisition using Daqmx Read, everything goes well. Because I use this for some years.

 

The difference in here is that I acquiring from 12 StrainGages and 1 encoder during a period that I don't control (more than 30 seconds). Because the amount of data was significant I had to use the "Daqmx Loggin". 

 

This option needs to be configured before "start". That's the explanation.

 

I can only see the amount of data acquired after using "stop" and then reading from tdms file.

 

I also used some examples, and only modified them so that I use my simulated 9237 and measuring Strain. And changing the N Samples in "Daqmx timing" does not makes a difference (using N = 1, 1000, 10000).

 

So, I think that the difficulty is the log to tdms option.

 

Did I explained well or I did not understood you correctly?

 

BR

 

Jorge Amaral

 

Software developer
www.mcm-electronics.com





PORTUGAL
0 Kudos
Message 5 of 6
(2,768 Views)
Solution
Accepted by topic author Jorge_Amaral

Hi Jorge,

 

I think I understand you, but I am not sure.  In order to pin down the problem, can we try a couple of things?

 

First of all, let's eliminate the datalogging and make sure that the code gives us the results we expect as far as samples acquired, given a sample rate and duration.  Then we can go from there.

 

Second, can you send me that TDMS VI that you're using, the one where you set up the logging?  I'd like to have a look at it and see what's going on in there.  It will give me a more complete look at your code and (I hope) allow me to help you better.

 

One word of explanation about N samples in the Timing VI.  Since you are using Continuous sampling, setting N configures the size of the buffer (have a look at the help file for DAQmx Timing for more info).  That's probably why you aren't seeing that parameter make a difference as you change it.

 

As far as the TDMS datalogging goes, if the problem with using "Write to TDMS File" is that you're finding that it's bogging down your DAQ loop, then why not set up a queue and transfer the datalogging to a different loop?  That's the way I'd do it.  See attached.

 

If you could post that subVI in LV2009, I'd be grateful.

 

We'll get it figured out!

Diane

Message 6 of 6
(2,761 Views)