Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200279 with PCIe-6363

Solved!
Go to solution

I currently have a simple vi used to continuously acquire voltage data through the DAQ assistant.

Currently I am trying to collect 2 channels sampled at 200k continuously (due to random events).

 

Regardless of where I set the samples to read at, I repeatedly get: Error -200279. 

 

From some other posts, I surmise it is because the DAQmx read function and the "write to file" function are occuring at different rates causing a data mismatch perhaps. 

 

To fix this, should I implement the producer/consumer design pattern? And if so, may I receive guidance on how to actually implement that with my current vi?

 

 

-Matt

0 Kudos
Message 1 of 4
(4,168 Views)
Solution
Accepted by davids24

Hi davd24,

 

We always recommend doing file I/o functions in a separate loop than DAQmx read/write functions. It looks like what is happening in your case is that the time it is taking to write to a file is longer than it is taking to fill up the device on board buffer which throws the error you are seeing. Therefore, I would suggest the producer consumer architecture. Below is a link to a tutorial:

 

http://www.ni.com/white-paper/3023/en/

 

Also here is a link to a community example doing produce consumer with DAQmx functions:

 

https://decibel.ni.com/content/docs/DOC-2431

 

If you have any specific follow up questions after looking through these let me know.

A Johnson
Applications Engineer
National Instruments
Message 2 of 4
(4,144 Views)

Thank you for the information, especially the second link.

 

I have implemented the consumer/producer loop, with another loop to ensure all the data is written from the queue.

I used this link to implement that:

 

https://decibel.ni.com/content/docs/DOC-3792

 

Everything seems to be working but, I have a few questions about its operation:

 

1. The timing on the output file produced by the "write to measurement" block starts off negative. I was curious to why that was. 

 

2. Is it proper to have any of the error pins connected to the "write to measurement" block or is it OK for it not to be connected in this situation?

 

3. I only intend to capture small segments of data with this VI, however I noticed if I were to accumulate large segments of data with large sampling rates, this program's run time is quite lengthy. Writing and reading from a queue I realize does require some time, however I was curious if the program's run time was completely related to that or if the "write to measurement" block had some significant effect in that.

 

Again, thanks for the help!!

 

-Matt

 

 

 

 

0 Kudos
Message 3 of 4
(4,089 Views)

Hi Matt,

 

1. From my first look at your VI I'm not able to tell why the timing of the output file is starting as negative, without being able to run this I can't replicate it.

2. As far at 2, it's always best to have your error wire connected to this, you can run error wires from this and use the merge errors function to combine them into your final error handling.

3. Write to measurement can be a pretty slow VI, I'm not sure if this is whats slowing down your program with large data collection segments, but if this becomes a problem you could consider saving this data in an array and then writing it to file at the end of the acquisition, or using TDMS write functions instead, which are faster than the Write to Measurement File.

 

Selene v.

Applications Engineer

National Instruments

Selene
Message 4 of 4
(4,045 Views)