LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Buffer problem - Voltage acquisition coded the same way as example - Can't find anything more to test

Hello Labview coders,

I'm getting beyond crazy finishing my application. I'm posting here hoping for help because I don't have hairs to pull anymore... 1 week of debuging the same problem, I've tested everything I know and found online..

I'm Using Labview 2020.

I'm reading Frequency and SampleToRead from a file (10000Hz and 10Samples in this case).
I then configure the task for multiple channels, Start the task (only once of course), read the datas in while loop (independant from everything else), then I put my results in graphs charts.

OK, I know my code is "working" because if my parameters are Frequency=Samples (so 1Hz) everything is good.

 

Then I needed to up the frequency and from then my code is not working anymore.
I've tested so many things, including passing datas through FIFOs...

 

Now I've found a example code named "Voltage - Continuous Input" that is working perfectly the way I want it. So I've copied every steps of the code into my own and I can't figure out why it is working flawlesly in the example and bugging in my code. Because I can't spot ANY differences...

I've attached some screenshots in hope someone could help me.

 

ps:
Sorry for my english I'm not a native speaker.

I'm not new to Labview but there I can't debug this thing.

 

 

0 Kudos
Message 1 of 4
(364 Views)

Hi Moro,

 


@Moro` wrote:

I'm reading Frequency and SampleToRead from a file (10000Hz and 10Samples in this case).
I then configure the task for multiple channels, Start the task (only once of course), read the datas in while loop (independant from everything else), then I put my results in graphs charts.

OK, I know my code is "working" because if my parameters are Frequency=Samples (so 1Hz) everything is good.


Two recommendations:

  1. Read the help for the DAQmxTiming function carefully! When using the "continuous" mode special rules apply to the "samples to read" input! Generic rule: don't apply your own data here and let DAQmx setup its buffer on its own!
  2. Setting a samplerate of 10kHz and reading only 10 samples will result in a loop iterating at 1kHz: this will give you problems on a default Windows computer! Generic rule: set the number of samples to read to about 1/10 of the sample rate…
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 4
(344 Views)

Read Error -200279: Unable to Keep Up With Acquisition in NI-DAQmx

-------------------------------------------------------
Control Lead | Intelline Inc
0 Kudos
Message 3 of 4
(315 Views)

A little background to explain why GerdW's tips will help you solve this thing quick.

 

There's a *little* bit of overhead involved with each call to DAQmx Read, as the code has to work it's way down through layers of the driver.  The exact amount will vary, depending on system performance and a variety of task particulars.   But very very generally, you should expect it to be closer to a millisecond than a microsecond.

 

Consequently, you want to request enough data from the driver on each call that the overhead is relatively small compared to the time needed to acquire those samples.  That helps provide some spare time for processing between reads.   Over time, the LabVIEW community has kinda settled on 1/10 sec worth of samples per read as an excellent starting point that supports a very wide range of apps.  It lets you update indicators & charts 10 times a second, which is plenty close enough to real time for anything a human operator needs to do.   If they can't interpret and react to things in less than 1/10 sec (and humans can't), they don't really need to see the data update faster than that.

    There *are* exceptions where you need to do something different, but it's unlikely you're dealing with one of those cases.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4
(312 Views)