Error -200279 occured at Acquisition.lvlib: Acquire.vi

[ramssrk]

Hello,

Error -200279 Occured in my LabVIEW application, after checking the NI Forums, the solution given was to add delays in the while loop.(I've added 10ms of delay) By doing so i got the "No Enough Memory" error along with some unspecified error occured. I attaached the pics.

In my application i'm trying to acquire data continuously for more than 10 days with sampling rate 1000. I've also attached my code snapshots. I'm Creating tasks, Configuring, starting tasks in one subvi. And Read DAQmx in another Subvi then stop,clear DAQmx in one more subvi. I have a case structure where i'm calling these subvis in each case. 

Can someone plesae help me to solve this problem?

Thanks in advance.

-Siva

[Alexander_Sobolev]

How soon do you have this error?

What happens with this data after queue? Do you keep all in memory?

How many channels in each task, how many tasks? For each channel you have:

10 days * 1 000 sample/s * 3600 * 24 * 2 bytes/sample = 1.7 GByte

[ramssrk]

Hi Alexander_Sobolev ,

I used to get this error after 8 days (but it is not consistent, some times it happened after 12 days).

I acquire data continuously and then read it continuously. Some times i even record it continuously. (And i'm taking care of the record file size by creating a new file for every 24 hours and recording)

I use 16 channels.

Thank you for your reply.

-Siva

[Kevin_Price]

You typically sample at 1000 Hz.  You always request 1/10 second worth of samples each loop iteration.  Most of the time, your loop iterates in less than 1/10 second.  So the next time you call DAQmx Read and request 1/10 second worth of samples, the function call waits for the rest of them to accumulate and then returns them.  Every once in a while though, it'll take more than 1/10 second to iterate the loop b/c Windows has gotten busy prioritizing other things -- things which may or may not relate to other parts of your app.

If these interruptions are not too long and happen fairly rarely, your code will recover.  Let's say one iteration takes 3/10 second.  What'll happen next is a very fast spin through 3 iterations of the loop, each time reading out 1/10 second of samples that are already available in the buffer.  The 4th iteration will need to wait for the rest of that next 1/10 second of samples.  But then you're back to your normal iteration pace.

Error -200279 comes up if you fall behind by the full size of your task buffer.  Hence the error text suggestion to increase the buffer or to read more often.  Nominally, you're reading often enough, but under Windows that timing isn't guaranteed.  So I'd recommend increasing the task buffer sizes.

I don't know what size they are now, but I'd suggest increasing them 5x or 10x if feasible.  With error rates that require weeks of testing to confirm "fixes", you don't want to be too subtle about the changes you make.

The second error sounds like you're running out of memory overall.  It's very possible that as you get really close to being out of memory, Windows gets so busy *trying* to get more that it slows down your DAQmx Read loop and leads to the -200279 error.  So the two errors *might* be related.

   Alexander's questions were aimed at finding a place you might be accumulating data in memory continuously.  This is the most common way people run into memory issues over time.  I'll add a couple other things to watch out for:

- references or resources that can be created / opened without necessarily being closed / destroyed.  These could be task refnums, queue refs, file refnums, etc.

- a subtler one would be parts of the code that temporarily require large contiguous blocks of memory.  Even if that memory is only used for a little while and then made back available to the app again, there can be a slow buildup of memory fragmentation which makes it increasingly difficult to keep finding a large contiguous chunk of unoccupied space.

It'll help if you can post all your code.  Not promising that I'll *personally* have time to comb through it, but without the code all *anyone* can do is guess.

-Kevin P

[ramssrk]

Thanks Kevin for your detailed explanation.

Presently, i'm running the code to check the data queue buffer sizes (No.of elements in the queues) and see whether is there any data Queue buffer size is increasing and causing buffer overflow. (All the queue sizes are set to -1). I'm thinking the data queue buffer overflow is giving the "No Enough Memory" error. I'll post you the outcomes of my tests.

Thank you.

-Siva

[hdempseyjones]

Hi all,

Sorry to jump onto your thread but have been having some issues with the same error described above.

I am reading from an accelerometer, performing some operations on the output (filtering etc), then once a person make a movement above threshold value the program plays a sound then stops.

This was all working fine, until I put the whole thing into a for loop - to run it several times. Now, when I watch the smoothed output in a waveform chart, after about 4 seconds of no movement it appears to slow down (data coming onto the chart in a chugged up way), then when I make a movement it gets even slower - not sure if this is just with additional time though, or related to the movement itself...

DAQ timing: My buffer size is 2000, rate of acquisition is also 2000 (I read somewhere these should be the same?)

DAQ read: I am reading at '1' so I think this means once every 2000th of a second? I had '-1' in there for a while, which I thought meant something similar, like 'read every sample'. But when I put that in now it runs very strangely, flickering weird line instead of normal output.

As above, I read that there might be various issues

- Need to put a wait in to allow your hardware/ software to catch up with each other?

- A process in your code that is taking a long time, causing a lag?

However, this all seems a bit odd as it was fine out of the for loop...

I was wondering if I could probe the minds of people who know much more than me to see

1. what you thought of my timing and read parameters - do they seem appropriate (I am working my way though this, but wanted a human to confirm: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7KdSAK)

2. whether you thought putting a wait into my while loop that does the reading might affect my acquisition? I need really fast and accurate reading to detect movements and am worried about creating a lag of my own with a wait

3. whether you guys thought it might have something to do with my filter (savitzky golay ptbypt), as I had one brief but temporary instance of lag after I implemented this for the first time.

Sorry to be so clueless and for the long post (I am a psychologist by training/ reluctant programmer with no training!), any advice would be most appreciated!

Harriet

[Kevin_Price]

In the linked article, the "How Much?" paragraph of part 1 is partly misleading and partly wrong.  In finite acquisition, the # samples input sets the buffer size.  The use of the phrase "how many samples are read on each channel" is misleading.  In continuous acquisition, the # samples input is often ignored.  DAQmx calculates its own value according to these rules.

The "How Much?" paragraph of part 2 presents a useful rule of thumb.  In continuous acquisition, a good general starting point is to plan to read about 1/10th second worth of samples per call to DAQmx Read.  For you, at 2000 Hz, that'd be 200 samples.

There's some leeway though.  If you need lower latency between when the data is sampled and when your algorithm can assess and respond, you may need to iterate faster than 10 times a second.  Let's say you want latency of only 1/50th second.  Well, then you'd just request 40 samples at a time.

Either way, let your request for multiple samples be the thing that paces the iteration rate.  Don't add a separate wait timer in the loop -- many posters have created problems for themselves this way by overconstraining their timing.

At 2 kHz data rate, your SG filter should be plenty capable of keeping up.  I notice a few of the dreaded blue "dynamic data" wires though.  Many of us who know a little something about DAQ would sooner make olympic skaters wear training wheels than resort to the use of dynamic data wires.  Try to stick with waveforms.

-Kevin P

[hdempseyjones]

Hi Kevin,

Thanks for your response - I love your ice-skaters analogy (but will get to my newly existing Q about dynamic data in a second).

I am ok with reading data at 1/50th second, so altered my DAQmx Read 'samples per channel' to 40 as you suggested.

Things seem to go ok if looking at a waveform chart of the raw voltage values converted to g, but then looking at my sgf filtered data on a similar waveform chart it looks really weird - there is only a tiny fraction of data showing up on the right hand corner and I think it is lagging massively as I can't see any movement when I move my accelerometer (the movement is, however, visible in the raw g waveform chart).

Any thoughts on why this might be happening? My program relies on the sgf data for following processes, so it gets stuck and can't progress.

Second question - why do we hate dynamic data? The data just becomes that once I divide my 2 channels using 'split signals' VI. I will look it up but is there a way to split channels and recombine them without ending up with dynamic data (in case I can't find anything)?

Thank you again for all your help, my program is so close to working I can taste it! 😄

[Kevin_Price]

No ideas about the S-G filter stuff.  The code is LV 2017; I'm on 2016 and can't open it.

Why do we hate dynamic data?  It's partly rational and partly irrational.

The mostly rational part is that after many years of being able to identify datatypes by the appearance of their wires, dynamic data came in and broke that correspondence.  It's much more opaque, and you often end up converting back to more traditional datatypes anyway in order to call well-known processing functions.  It strikes a lot of us as not only unnecessary, but actually kind of an obstacle to advancement as a programmer.   That's the idea I was trying to capture with the analogy.

    Many many threads get started that contain just a couple of express vi's (also held in low regard by myself and many others) stuck together with dynamic data wires.  The poster has done about 5 total minutes of programming and configuration work, but has spent subsequent hours at a dead end because the apparent "magic" of these opaque express vi's and dynamic data wires has helped them bypass a fundamental understanding of their data.   To me, that's a dubious goal in a dataflow language.

The irrational part arises in a way that's fairly analogous to an attitude you might find in Linux power users about Windows.  You start with good rational reasons for the preference, but over time the preference becomes an emotional commitment which can lead to an irrational disdain.

Your call to DAQmx Read returns an array of waveforms.  Each element of the array is a single waveform representing a specific single channel of data (along with timing info and probably some other metadata).  To extract an element from an array, use the "Index Array" function.  To put it back, well, there's many ways depending on what you need.  You can append, insert, or replace. 

    You'll find that there are a lot of functions available for array operations and for waveform operations.  Each is identifiable by name & icon.  There are many fewer functions available for dynamic data.  Their behavior tends to be variable and not knowable without right-clicking or double-clicking to check configuration settings, which is a problem in run mode while debugging.

-Kevin P

[hdempseyjones]

Hi Kevin,

Thanks for the info on dynamic wires - I have now removed them for waveforms. I used 'WDT index channel DBL.vi' to split the waveforms instead of 'index array', do you think that is correct?

I have also made some attempts to fix my lag issue

- I moved the DAQmx Read stuff to its own while loop (analysis and TDMS writing are now done in other loops, activated by queues i.e., dequeueing elements)

- I changed my buffer size in DAQmx Timing to 5000 (double my sample rate) to allow for lags

- I changed my DAQmx Read *samples per channel* to 40 (from 1) so it reads more slowly

Only thing is... now my loop does not run at all :s    (while loop counter is stuck at 1 and no data is coming in)

You have any ideas what might be up?? Do you think you might be able to take a quick peak at my VI at all see if I have done something crazy? I have such a low understanding of all these rate/ buffer/ hardware aspects that its really hard for me to debug. I am reading up though to try and get better though