Data was overwritten before read by system ->NI -6221 ( Error - 200141)

[Mrtechie]

Hello All , 

I am using NI 6221 card in my application . Whenever the application starts within few minutes it throws the error -200141 stating that Data was overwritten before read by the system in the counter.vi . i have attached the screenshot of the error , counter.vi and 6221 card with TB . what is the thing i have to modify in that VI .. pls help me to ressolve this issue 

[GerdW]

Hi bhuvanesh,

how often do you read data? How do you call this FGV aka AE?

At which pulse frequency does the error occur?

Why do you read counter values twice and throw away the second reading?

How stable is your USB connection?

(Why do you show an image of that connector block?)

[Mrtechie]

AE means ?? i need to continuously acquire the data from the NI card . Min frequency 0.1 and max frequnecy 100 

[GerdW]

Hi bhuvanesh,

AE means ??

FGV = functional global variable, AE = action engine

Your VI looks like a typical FGV aka AE…

i need to continuously acquire the data from the NI card

Your "counter.vi" does not run continuously as the while loops stops immediatly, so please answer my questions…

[Kevin_Price]

As the error states, you aren't pulling data out of the task buffer fast enough to keep up withQuote how fast the task is putting it in.

The problem does *not* appear to be in the vi you posted.  It appears that your higher level app isn't *calling* this vi often enough.   I suspect your 2nd counter read where you read all the leftover data and discard it was a troubleshooting attempt to eliminate your error.  It probably *did* help delay the error, right?  But in the long run, you probably don't want to keep doing that.   You're keeping and using the older data while discarding the fresher data, which isn't normally a good practice.

A further problem is that you have a 0.05 sec timeout for reading 100 freq values, but you've stated that your freq range is from 0.1 to 100 Hz.  100 measurements will require at least 1 second.   It seems you'll keep frequently timing out on the 1st read, then scooping up all the leftovers and discarding them with the 2nd.  Only when the calling code has a long delay before the next "Read" call will you have a chance to actually find your 100 samples waiting.

You need to think carefully about "who's in charge" of the execution timing.  Because you're measuring a variable frequency, it should probably be the calling code.  Therefore the "Read" case of the code you posted should execute quickly and be better behaved.  One simple place to start is to do just one read of "all available samples."   That'll execute quickly.  You just have to structure your app to handle the variable-length data packets you'll get.

-Kevin P

[Mrtechie]

hello kevin, 

In ( counter data.vi)  when the counter is on it always a give a -1 . so it can accept .i have attached a counter.vi too . have a look at that and help me to resolve this 

[Kevin_Price]

As I said before, that kind of error is most likely caused because you aren't *calling* the posted vi often enough.  Once the task is started, pulse signals will keep storing frequency measurements in the task buffer.  This happens in the background between attempts to call DAQmx Read to retrieve values from the buffer.

In general, your reads rate needs to keep pace with the tasks fill rate.  Faster pulses means you need a faster overall read rate (frequency of calling times # of samples per call).   So whatever part of your app keeps calling the vi you posted needs to call it more frequently to prevent the buffer from overfilling between reads.

-Kevin P