Can anyone help me with this DAQ assistant error. Error -200279 occured - Attempted to read samples that are no longer available.

[lorc34]

I have attached my VI which was made with Labview 2010.

The VI uses DAQ assistant to read voltage levels on 4 different pins. The DAQ is a USB 6009. This DAQ has 8 analog inputs. They are split into 4 pairs of 2, e.g. A0+, A0-, A1+, A1- etc. I have wired all 4 pairs to 4 magnetometers.

I am able to read the magnetic field strengths and display on graph. If the level on the second magnetometer (only the second for now as its just in a test phase) goes above 250 or below -250, it triggers a light which turns red, using one of the analog outputs on the USB 6009. If it stays within the limits, it will be green (using the other analog output)

This so far works perfectly fine. Where I started having issues was in the current implementation of the VI which uses a second while loop. This while loop triggers when the magnetometers go out of their limit of 250. At this point, the light will stay red, and a user must push a button which connects digital I/O pins 17 and 18, which triggers the 'STOP' function of this inner while loop.

If I wave a magnet near the magnetometer, get the light to turn red, and wait more than 5 seconds, push the button, this DAQ Assistant error appears. However, if I make the light go red and immediately push the button within say 2-3 seconds, the VI works perfectly fine! Do you know why waiting inside that inner while loop for too long causes the error?

The intention of the VI is that if the magnetic field level near the magnetometers goes above a certain threshold, the light turns red, and a user must physically push a button to turn it back to green. If the levels do not go above the threshold they are green (i.e. they are normally green)

Error -200279 occured at VIname.vi:Instance:0:1 - Attempted to read samples that are no longer available. The request sample was previously available, but has since been overwritten.

Increasing the buffer size, reading the data more frequently or requesting a fixed number of samples to read instead of reading all available samples might correct the problem.

Property: RelativeTo
Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name:_unnamedTask<233AF8>



EDIT: Another issue is that when the program enters this 'inner' while loop, the code outside the inner while loop (but still in the outer while loop) does not run. For example, the DAQ Assistant acquiring magnetometer levels and graphs showing levels of magnetometers. Is there a way to implement my program without an inner while loop which causes this behaviour and may also fix the program crashing too?

[GerdW]

Hi lorc,

---

@lorc34 wrote:

Error -200279 occured at VIname.vi:Instance:0:1 - Attempted to read samples that are no longer available. The request sample was previously available, but has since been overwritten

---

When you setup the DAQ task to read "continuously" then you should read the sample continuously! Right now the outer loop (with the first DAQAssistent) is blocked from iterating as long as the inner loop executes!

Recommendations:

• Don't use the DAQAssistent, use the plain DAQmx functions instead. They are explained in all those example VIs and in this article.
• Change your VI to a non-blicking behaviour: do you really need an inner loop? (Answer: No, you don't.)
• Implement a real state machine.
• Remove the Rube-Goldberg, even LV2010 knowns about the InRangeAndCoerce function…

[lorc34]

Hi Gerd,

Thank you for your reply. I will have to look up some things you mean like Rube Goldberg.

I tried using the DAQmx code generated from the DAQ assistant but couldn't understand how to do it after a small check but I can investigate further..

Also this error occurs whether I read continuously or with 'N samples'. 

In my mind it's possible to do this for example if it was python or similar:

Color=0

While()

    GetLevel()

    If level > 250 or < -250:

        Color=1

    If Color=1

        SetColor(Red)

    Elseif Color=0

        SetColor(Green)

    If(ButtonPushed):

        Color=0

This would allow a user to reset the Color to green. As it stands in my Labview program, I just check the level and enter a while loop if its above the threshold. Is it possible to do what I described above in labview where you have a variable set that can force the program to enter a certain state each loop? And that variable can be controlled from different ways (e.g. threshold exceeded vs button pushed)

[GerdW · Accepted solution]

Hi lorc,

---

@lorc34 wrote:

In my mind it's possible to do this for example if it was python or similar:

Color=0

While()

    GetLevel()

    If level > 250 or < -250:

        Color=1

    If Color=1

        SetColor(Red)

    Elseif Color=0

        SetColor(Green)

    If(ButtonPushed):

        Color=0

---

In your "python" example there is only one while() loop, so why are there two loops in your LabVIEW VI?

It seems to me that the variable "Color" should be a boolean with values false/true instead of an integer 0/1…

This would be a LabVIEW replacement for your python snippet:

(It is not exactly the same, but very similar…)

[lorc34]

I only used an inner while loop in Labview because it gave me a way to 'lock' the program when it turns red. I dont really know how to implement a variable which we can use to control the light and which can exist from one loop iteration to the next. If I dont have that inner while loop, the DAQ assistant will get a new data, and the light will turn back to green if the level has dropped since it was red.

E.g. Level hits 500 -> light turns red
next reading is 150 -> light turns green

This is wrong, because we must force an operator to press the button in order for the light to turn green. So the way I did that was, when it turns red, it goes into another while loop, and pressing the button is the 'stop' criteria for that while loop. However it seems to be causing issues with crashing?

Do you think using a state machine or using the code you showed above is better?

[lorc34]

I think your program will work as long as the default of that True-False button which controls the bottom select function is defaulted to 'False'

[lorc34]

Thank you Gerd. Your solution worked using a while loop with boolean shift register. Now all I need to do is understand how sampling and rate works with DAQ lol

[lorc34]

Like, what is the difference between using 'number of samples' = 10, 'rate' = 1000, versus 'number of samples' = 1000, 'rate' = 1000 ? When I do the former, the while loop iterations are 100 per second. When I do the latter, it is 1 iteration of while loop per second. Having 100 while loop iterations per second seems to make the button push much more responsive. I can trigger the light green-red-green extremely fast. When I set no. samples to 1000, it can only update the light once per second. 

Is it that acquiring more samples leads to a better precision on the voltage level of the acquired signal? At the tradeoff of the program being less responsive to button pushes etc? Thank you again.

[Kevin_Price]

---

@lorc34 wrote:

Like, what is the difference between using 'number of samples' = 10, 'rate' = 1000, versus 'number of samples' = 1000, 'rate' = 1000 ?...

Is it that acquiring more samples leads to a better precision on the voltage level of the acquired signal? At the tradeoff of the program being less responsive to button pushes etc?

---

No, it's actually much simpler than that.  In both cases, the DAQ device will digitize samples at a rate of 1000 Hz.  These samples are then transferred by the DAQmx driver into a buffer that the task owns.  The 'number of samples' you *read* from the buffer each loop iteration will determine your loop rate (provided that the code in your loop can execute faster than the time it takes for the 'number of samples' you ask for to be delivered according to your 'rate').  It will have *no* effect on the accuracy or precision of the digitized values that you retrieve.

With a rate of 1000, when you repeatedly request 10 samples per iteration, the task needs 1/100 second to digitize 10 new samples and transfer them to the task buffer.  If you repeatedly request 1000 samples, the task needs 1 full second to get them.  Either way, the same voltage values get digitized and transferred.  You're just trading off read_size and read_rate under the constraint that (read_size)*(read_rate)=1000 samples/sec

A good general rule of thumb is to request about 1/10 sec worth of samples per iteration.  This tends to be a pretty robust tradeoff across a wide range of sample rates and reasonable amounts of code-in-the-loop.

-Kevin P

[lorc34]

Hi Kevin,

I think I was not clear when I said accuracy. Of course the values will be the same. But if you have a sine wave that you're acquiring, having 'number of samples' = 1000, and 'rate' = 1000, you will get a more clear picture of the sine wave? Whereas if you have 10 samples and rate 1000, the sine wave might not be captured properly?

We are not dealing with very high frequency signals here, its near-DC and we only actually take 10 readings per second from the DAQ assistant dynamic data output

Also as a bit of a side question, do you see any issue with us using Labview 2010 in future? It is obviously 14 years old now.