LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200361 occured at DAQmx Read

We have a problem with "Error -200361 occured at DAQmx Read" when sampling at 500kS/s using the 9201 in a USB-9162 carrier. It

seems that our program is acquiring the data quicker than it is able to process it. We have an oscillating circuitry, oscillating at about

190kHz. A coil is placed around a glass tube with ferroelectric powder passing, and we want to monitor the change of this resonance

frequency due to the amount of this powder in the coil using a Labview program. The frequency is then used to calculate the flow of

powder and the approximate mean flow during a minute.

 

The program is made in LabView 8.6, and saved as a 8.0 version for use in a computer with Win XP SP2,

3GHz, 1GB RAM and LabView v8.0.

 

The program works fine using the computer which it was made in, but when it is beeing run in the computer to be used, error 200361

occurs immediatly. I created a button to turn on/off plotting the results in graphs, as this seemed to take a lot of resources, which helped

a bit. I also changed the priority for LabView to "High" in task manager, and now it works for some time, before it crashes.

It also seems to crash when starting an other LabView program which also has to run on the computer.

 

I have attached the vi and sub-vi, could someone please take a look on it and give advice on how to make the program more efficient?

 

Thanks!

Message Edited by ltvedt on 08-24-2009 01:50 PM
Download All
0 Kudos
Message 1 of 10
(5,085 Views)
What NI-DAQmx are you using on your computers?
0 Kudos
Message 2 of 10
(5,068 Views)

Hi ltvedt

 

I had a quick look at your application and one improvement I can suggest is to use a Producer/Consumer design pattern. With this you use two loops, one to acquire the data and another to process it and a queue to communicate between them. You can find a template if you open File->New and then under VI->From Template->Frameworks->Design Patters->Producer/Consumer (Data).

 

Best Regards

 

David

NISW

0 Kudos
Message 3 of 10
(5,065 Views)

Thanks for your quick reply!

 

I am not shure which version it is, but I think it is 8.0.1.

I am not currently on site with this computer, so I cannot check it.

 

My office computer where it works fine has 8.7.2 installed.

 

Also an update regarding the error message, it is Error 200279, not 200361 as stated earlier.

 

I tried the method of producer/consumer, and found that the buffer just increased in size,

which made me realize that the problem was that the data was processed slower than the

aquisition of new data.

Message Edited by ltvedt on 08-24-2009 03:05 PM
0 Kudos
Message 4 of 10
(5,060 Views)

Do you still get your error or is it fixed by increasing your buffer size?

If not please have a look at this KB Entry.

 

Stefan

 

0 Kudos
Message 5 of 10
(5,053 Views)

The error will not appear when using producer/consumer, but the buffer will continue to grow quite quickly. This will also give a lag

in the returned flow of the powder.

 

I will check the KB entry and see if I can figure it out tomorrow.

 

Thanks a lot for your help so far!

Smiley Happy

 

Lars

0 Kudos
Message 6 of 10
(5,046 Views)

Hi 

 

Those two error codes have can alternate and are both a sympthoms of the same problem. You are reading data into your application from the buffer slower than you are reading data from the instrument to the buffer.

One solution to this is to attempt to disconnect the reading from the processing (the pattern I talked about in my last post) which in essance is a way of buffering in you application. Another is to read the data at a slower rate. Yet another is to read larger chunks (more samples) per iteration.

 

Best Regards

David

0 Kudos
Message 7 of 10
(5,045 Views)

Hi,

We cannot reduce the sampling speed due to the speed of the powder and the need of "seeing" the grains as they pass the 2cm long coil. I changed the program to include a producer/consumer structure. I also increased the "samples per channel" in the Sample Clock as well as the amount of samples to be read by the DAQ. The samples per channel was set to a integer multiply of 1024 and the amount of samples to be read was set to half of this buffer size.

As I understand it, by using an integer multiply of 1024, the FFT of the signal will be done much quicker.

 

Now the program seems to run fine as long as no graphs are plotted.

 

Thanks for all help!

 

Lars

0 Kudos
Message 8 of 10
(5,015 Views)

Hi Lars

 

That's great!

 

Just remember that if this is an application that is supposed to run for a long time a good test to run is to visualize the number of samples in the buffer (see the KB linked earlier by Stefan) and number of elements in the producer/consumer queue (get Queue status.vi). This to make sure thay are stable and not just increasing more slowly. If they are increasing slowly you have just prolonged the problem. That may be enough depending on how fast they increase and your application. Just something to keep in mind, hope everything continues working well Smiley Happy

 

Best Regards

 

David

0 Kudos
Message 9 of 10
(5,010 Views)

Thanks for the heads up David,

 

I added an indicator on the # of elements in the queue, to be able to check this. The system will be running throughout the day to check if it is stable.

I will post as soon as I am shure everything is ok.

 

Again, thanks a lot for all the help guys!

 

Smiley Very Happy

0 Kudos
Message 10 of 10
(5,008 Views)