Error -200279

[Maverick...]

Hi friends,

I am getting the error -200279 during acquisition.

I have developed the application in a PXI located at my place.

The application is running fine in that PXI.

But when I ran it on PXI which is located at a remote site. It is giving this error -200279.

I have run the application using remote desktop connect at the remote site.

I have run the application in another PXI located at my place. There also the application is running properly.

Can anyone provide solution for this issue.

Thanks in advance...

[StefanA]

Hi Maverick,

what exactly are you doing in your application?

The error message tells me that you do data acquisition and you are not reading data from the PC Buffer fast enough.

There are several methods to avoid that problem:

−Increase the buffer size with the DAQmx Timing VI

−Increase the Number of Samples per Channel to read with DAQmx Read VI

−Decrease the Samples per Channel per Second acquisition rate with the DAQmx Timing VI

−Don’t do any extra processing in your loop with the DAQmx Read VI

Stefan

[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

[JensG69]

Wow, this thread is 8 years old. And you also jumped to at least one other thread: https://forums.ni.com/t5/LabVIEW/Error-200279-occured-at-Acquisition-lvlib-Acquire-vi/m-p/3801222/hi...

[James_W]

I wonder if either of you are following the NI AAP method?

Acquire

Analyse

Present.

If you do you shouldn't hit this error on the PXI itself.

Recommend:

1) Setup task & Configure the DAQ Card for acquisition

2) Acquire Data (& Loop read function) - stuff data straight into a Queue (run loop as fast as poss, but add ms timer set to 0 if not running on a Realtime target to allow processor to catch up.)

3) Analyse Data in a separate loop from the read, at the speed of de-queue. This should allow you to process data and chuck it is need be to not get H/W errors.

4) Display the Analysed data either directly from the analysis function or separately (updating the UI will incur a big time penalty for redrawing graphics, compared to data acquisition as a rule, or even data analysis, so better to split this out.)

(I rather suspect the Issue is related to not following this and to the different host machine Processor speeds + RAM sizes.)

Dempsy Jones... Unless you are running on realtime H/W you will not be acquiring at 1/2000 sec as the OS (if Windows) will not permit it.

Personally I set my DAQ speed dependent on what I want to measure (Niquist theorem) and then grab a as much data as I can reasonable get to process. I keep the buffer size so it's 2.5 times the sample size in case of loop running slow and then grab the samples I want.

so, if I want 0.2 sec of data I will make sure I have space for 0.5 sec of data in the buffer and that the acquisition loop is able to run theoretically faster than 0.2sec, but set the number of sample to get (calculated from the sample rate) as 0.2 secs of samples then I won't overrun the buffer.

This is then only ever a problem if capturing lots of high speed data - but I don't think this is the case here.

James

[James_W]

Good spot - I missed that!

---

@JensG69 wrote:
Wow, this thread is 8 years old. And you also jumped to at least one other thread: https://forums.ni.com/t5/LabVIEW/Error-200279-occured-at-Acquisition-lvlib-Acquire-vi/m-p/3801222/hi...

---

[hdempseyjones]

I know, terribly sorry, I realised I posted in an 8 year old forum and that no one may ever see my post, so re-posted - then realised people would probably consider double posting spam - won't happen again!

[hdempseyjones]

Hi James,

Thank you so much for your response. As a newbie I have some trouble following all the terminology but have done my best to follow your suggestions.

I wonder if either of you are following the NI AAP method?

Acquire

Analyse

Present.

If you do you shouldn't hit this error on the PXI itself.

I was not aware of this rule, but have now tried to implement it - 1. I put my set up and configure outside my while loop, then 2. in this first while loop I put all the stuff for acquiring and queuing the data. I then have two separate consumer loops (with different dequeue VIs) - 3. one to write raw data to TDMS file and 4. another to process the data.

Unfortunately now these loops do not run at all (the iteration counters are stuck at '0' even though LV says it is running)...

This is quite mysterious - not come across this before. I tried looking in debug mode to see what might be happening but I can't see any errors popping up, so am stumped. I wondered whether it might be something to do with updating the waveform charts on the front panel slowing everything but the issue remains the same if I delete the two charts.

Few other questions related to your post: 

Dempsy Jones... Unless you are running on realtime H/W you will not be acquiring at 1/2000 sec as the OS (if Windows) will not permit it.

--> Ah... I see... How would I find the upper limit? Should I reduce this or just leave it to try sample its fastest? (or could this have a detrimental effect itself?)

Personally I set my DAQ speed dependent on what I want to measure (Niquist theorem) and then grab a as much data as I can reasonable get to process.

--> When sampling at '2000Hz' previously - my events were about 120-180 samples long - I need about this much (or more ideally) information to reconstruct the waves...

I keep the buffer size so it's 2.5 times the sample size in case of loop running slow and then grab the samples I want.

--> Ok so I have currently left *rate of acquisition* as '2000' (unless you think I should reduce this?), but have increased *samples per channel* (buffer?) to '5000'

so, if I want 0.2 sec of data I will make sure I have space for 0.5 sec of data in the buffer and that the acquisition loop is able to run theoretically faster than 0.2sec, but set the number of sample to get (calculated from the sample rate) as 0.2 secs of samples then I won't overrun the buffer.

--> I'm really sorry, but I still don't quite understand - this final part *samples to get* refers to the DAQmx Read *number of samples per channel* - is this *number of samples per channel* from DAQmx Read the same as *number of samples per channel* from the DAQmx Timing?? Do they need to have the same values?!

I don't think I follow... 😞

Is there any way anyone could have a quick peak at my VI to see if I have done something mad?

my main issue is that my loop is now not running at all...

[hdempseyjones]

I wonder if either of you are following the NI AAP method?

Acquire

Analyse

Present.

If you do you shouldn't hit this error on the PXI itself.

I was not aware of this rule, but have now tried to implement it - 1. I put my set up and configure outside my while loop, then 2. in this first while loop I put all the stuff for acquiring and queuing the data. I then have two separate consumer loops (with different dequeue VIs) - 3. one to write raw data to TDMS file and 4. another to process the data.

Unfortunately now these loops do not run at all (the iteration counters are stuck at '0' even though LV says it is running)...

This is quite mysterious - not come across this before. I tried looking in debug mode to see what might be happening but I can't see any errors popping up, so am stumped. I wondered whether it might be something to do with updating the waveform charts on the front panel slowing everything but the issue remains the same if I delete the two charts.

Few other questions related to your post: 

Dempsy Jones... Unless you are running on realtime H/W you will not be acquiring at 1/2000 sec as the OS (if Windows) will not permit it.

--> Ah... I see... How would I find the upper limit? Should I reduce this or just leave it to try sample its fastest? (or could this have a detrimental effect itself?)

Personally I set my DAQ speed dependent on what I want to measure (Niquist theorem) and then grab a as much data as I can reasonable get to process.

--> When sampling at '2000Hz' previously - my events were about 120-180 samples long - I need about this much (or more ideally) information to reconstruct the waves...

I keep the buffer size so it's 2.5 times the sample size in case of loop running slow and then grab the samples I want.

--> Ok so I have currently left *rate of acquisition* as '2000' (unless you think I should reduce this?), but have increased *samples per channel* (buffer?) to '5000'

so, if I want 0.2 sec of data I will make sure I have space for 0.5 sec of data in the buffer and that the acquisition loop is able to run theoretically faster than 0.2sec, but set the number of sample to get (calculated from the sample rate) as 0.2 secs of samples then I won't overrun the buffer.

--> I'm really sorry, but I still don't quite understand - this final part *samples to get* refers to the DAQmx Read *number of samples per channel* - is this *number of samples per channel* from DAQmx Read the same as *number of samples per channel* from the DAQmx Timing?? Do they need to have the same values?!

I don't think I follow... 😞

Is there any way anyone could have a quick peak at my VI to see if I have done something mad?

my main issue is that my loop is now not running at all...

[James_W]

The windows clock runs at a max speed of 1000ms, so if you only acquire 1 sample then you can't acquire any faster than 1kHz (assuming the windows processor is free all the time the loop restarts and the loop takes 1 ms or less to execute.

Acquiring an event of 120 sample at 2kHz takes 60ms, so you should be fine as the sample acquisition time is >1ms (as you have already been told in another thread 10ms is safer, and you are also above this.).

No you don't need to change the sample rate or the number of samples.

It's

1) the timeout on the DAQmx read function you need to pay attention to (you need to ensure you have adequate time to capture your samples - by default the timeout is 10sec)

2) Samples per channel defines the buffer size (see the context help)

Unfortunately I can't comment on your VI's as I'm still waiting on my copy of 2017SP1 to arrive, but if you back save for previous version to 2015, then I can comment for you.

I suspect you have an error or an infinite loop - have you run with execution highlighting on?

James