LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

data was overwritten before it could be read by the system

Solved!
Go to solution

Hello,

 

I use a flow sensor that creates a frequency output, and connected that to my PCI-6035E. When I run it, it works for some seconds, and then gives an error. Error 200141 'Data was overwritten before it could be read by the system.' I also tested with a pulse generator instead of the flow sensor, and the error only occurred when I changed the frequency. How can I solve this prolem?

 

Thanks in advance!

0 Kudos
Message 1 of 7
(3,652 Views)

First of all, there is no error code 200141.  [Hint -- the minus sign is highly significant].  Second, what do you know about the input signal?  And do you know if your hardware is working?  Can MAX read the counter properly?

 

Bob Schor

0 Kudos
Message 2 of 7
(3,647 Views)

Hi Bob,

 

Yes, the error is indeed -200141.

 

The input signal is between 2 and 600Hz. The hardware is working, I tested it on the test panel in MAX and it worked.

0 Kudos
Message 3 of 7
(3,639 Views)

I'm still stuck here. Does anyone know how to solve this problem?

0 Kudos
Message 4 of 7
(3,588 Views)

So much gets "buried" when using the DAQ Assistant -- it is a simplified (some might say "simple-minded") approach to getting started with DAQmx, but is a form of "blunt instrument".  You need a scalpel to "dissect" your problem.  If you type "Learn DAQmx" into a Google search, you will find lots of excellent material, including (the second hit when I just did it) my favorite NI White Paper, Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications.

 

Once you have "real" DAQmx functions, you can start debugging the process using probes, Highlight Execution, and other things to see where you might be going astray.  If you are still having trouble, post the non-DAQ Assistant version for us to examine.

 

Bob Schor

Message 5 of 7
(3,569 Views)
Solution
Accepted by topic author Allard171

Thank you for your replies, Bob.

 

I got it working now, the problem was that I was using continuous samples. I now take a single sample with a while loop and it works.

 

 

0 Kudos
Message 6 of 7
(3,501 Views)

@Allard171 wrote:

I got it working now, the problem was that I was using continuous samples. I now take a single sample with a while loop and it works.


What are you doing with your data in the While Loop after you take it?  Are you processing it (FFT, filter)?  Are you plotting it?  Are you doing anything that might take a substantial amount of time?  

 

Let's assume that you are sampling 1000 samples at 1 kHz, a process that takes 1 second to complete.  Let's also assume that you want to do some computations and then plot those 1000 sample, and lets say this take 0.1 to 0.5 seconds.  Let's look at some timing:

  • Single Sample -- Acquire at t=0, finish at t=1, finish processing at t=1.1 (say).  Next sample starts at t=1.1, done at 2.1, processed at 2.3 (or there abouts).  Continue sampling, with gaps (of various sizes) between the samples.
  • Continuous Sample -- Acquire at t=0, finish at t=1, continue acquiring, finish processing at t=1.1.  Next loop starts at t=1.1, sampling finishes at t=2.0, third sample starts in hardware, processing finishes at 2.3.  Third loop starts at 2.3, sampling finishes at 3.0, next sample starts, processing finishes at 3.5 (say).  You can see that eventually we're going to have two samples finish in one loop, but only the first one will be read, and we will have an Error generated.

The solution to this dilemma is to move the processing, which takes time, out of the Sampling Loop and into a parallel Loop that does only the processing, something that has the name "Producer-Consumer Design Pattern".  Here's the Idea:

  • Producer Loop does Continuous Sample.  As each sample finishes, the data are "exported" (by being placed on a Queue, or on a Stream Channel Wire) out of the Loop to a parallel, "Consumer" Loop.
  • Producer Loop timing is as follows:
    • Acquire at t=0, finish at t=1, export at t=1.001. Next loop starts at t=1.001, sampling finishes at t=2, export and loop finish at t=2.001.  All remaining loops run the same way.
    • Notice that the Producer spends 99.9% of its time "idle", waiting for the Sampling to finish.  Because of the parallel nature of LabVIEW, that means that 999 msec is available for any other loop that needs to process the data.
  • Consumer Loop waits for data from Consumer.  As soon as it arrives, it starts "consuming" (= processing) it.  It should expect another data packet from the Producer in 1 second, so if it can finish "consuming" the data in that time, it can simply wait until the new data arrives and no data are lost or delayed in processing (as fast at the Producer "produces", the Consumer "consumes".
  • Occasionally the Consumer might require a little extra time (for example, if it needs to open a file, do a database lookup, or something like that).  Most Producer-to-Consumer transfer methods are "elastic" -- they can store up a number of data packets when they need a little extra time, as long as, on average, they can "consumer" faster than the Producer "produces".

So it is possible to "have your cake" (take data continuously) and "eat it, too" (display, process, or otherwise handle the data).

 

Bob Schor

Message 7 of 7
(2,224 Views)