LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

synchronized analog input and analog output (error 200279)

Hi,

 

I use the X-series multi-function USB: USB- 6341.

 

in the analog output channel I need a sine wave at the frequency of 20 kHz. in the analog input channel I need to acquire the data at 100 kHz.

I have modified 2  existing vi from the NI example programs but both of them give me the 200279 error. 

I honestly don't know what is wrong....I have also tried to run this with lower frequency and rate but it still didn't work.

 

Please, any thought?

I have to solve this and I am quite new in LabVIEW

thanks in advanced.

Naama

Download All
0 Kudos
Message 1 of 11
(3,586 Views)

1. You can fix the first one by removing the unnecessary "Wait (msec)" from the loop.  It's overconstraining you and leaving no margin for Windows timing variability.  Once you remove it, DAQmx Read will already make your loop run at about 10 Hz (10000 samples at a time from a task with 100000 samples/sec).  When Windows hiccups and you start an iteration 0.15 seconds after the previous one, the DAQmx Read function simply won't need to wait as long to get its 10000 samples.  It'll wait the remaining 0.05, and then get you back on your normal timing pace.

 

2. Same thing can fix this one.  Remove the "Wait (msec)" and then read more samples at a time.  You're trying to iterate the loop at 100 Hz (read 1000 samples per iteration from a 100 kHz task).  It turns out (surprise, surprise) that the "Is Task Done" query on the AO task executes too slow for even a 100 Hz loop rate.  Once you reduce your loop rate to 10 Hz, you'll be ok again.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 11
(3,561 Views)

Hi,

 

thank you for your response!

I have tried to delete the "wait" but it still doesn't work...

Naama. 

0 Kudos
Message 3 of 11
(3,558 Views)

Hi Naama2110,

 

From the error you are getting, it sounds like your application is not able to keep up with the acquisition. Here is a document which talks about this error, why its occurring and possible solutions to the problem.

 

LabVIEW Error -200279 in DAQmx Read or Property Node:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KTeSAM

 

I hope this information helps.

 

Michael B.

Applications Engineer

National Instruments 

0 Kudos
Message 4 of 11
(3,535 Views)

Hi,

thank you for your response.

 

I am new to labview and I saw this document before.. I trying to figure if there is a "rule" about the relation between the rate (of the sample clock, hence- my sampling rate) and the number of samples.

I want a good program that will work for 100KHz sampling rate, but in the future I would like to improve my vi to 500KHz sampling rate (which the USB- 6341can do). 

 

I choose to work with labview because this is the software of NI, but I having a trouble with all the things concerning the high rate (generating the sine wave, sampling, filtering et cetera).

 

thanks in advanced.

Naama

0 Kudos
Message 5 of 11
(3,526 Views)

A pretty good general rule of thumb that I've run across repeatedly (and often follow) is to set '# samples to read' to be about 1/10th of the sample rate.  That'll make your data reading loop run at about 10 Hz, and 10 Hz is more than fast enough for human comprehension of any displays you update. 

 

So if you acquire at 500 kHz, request about 50k samples per read.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 11
(3,519 Views)

Hi Kevin

 

thank you for your response. 

 

there are two places in my code which I define the number of samples:

1) in the sample clock when I define the number of samples per channel (the sample rate is let say 500KHz)

2) in the DAQmx read function. 

 

one more question are those parameters need to be equal or they have different values?

 

thanks, Naama

0 Kudos
Message 7 of 11
(3,510 Views)

Hi Naama,

 

I think this knowledge base article explaining the relationship between timing and sample rates will be a good read for you. It clears up how all the settings in the Timing VI and Read VI can be used to configure your system. Here is the link:

 

DAQmx Timing and Sample Rates:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7KdSAK

 

I hope this information helps,

 

Michael B.

Applications Engineer

National Instruments 

Message 8 of 11
(3,506 Views)

Be sure to follow the link from MichaelB123, there's a lot of good info there.

 

Addressing your specific question:  no, you do not need to use the same value both places.  I usually don't.  When you do Continuous Sampling, the 'number of samples' value you wire to DAQmx Timing isn't even used.  Instead, a buffer size is automatically calculated based on the sample rate.  You can find more info in the extended Help for DAQmx Timing.vi

 

I personally will often follow a call to DAQmx Timing with a call to DAQmx Configure Input Buffer.  There I can explicitly define the buffer size for the acquisition and I quite often make it notably larger than what would have been set aside for me automatically.  I usually have plenty of RAM for it, and like moving the chance of a buffer overrun from small to infinitesimal.

 

Either way, DAQmx Timing or DAQmx Configure Input Buffer will only affect the actual size of the data acquisition buffer in application RAM.  The units are # of samples for each channel, no matter how many channels are in the task.

 

What you wire to DAQmx Read controls how many samples you will retrieve from that buffer at a time.  You can never get *more* than the buffer size, but you're always free to request a lot less.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 9 of 11
(3,500 Views)

still not sure how I suppose to apply this, but thanks!!

Naama

0 Kudos
Message 10 of 11
(3,476 Views)