Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Simultaneous non-regen analog out + analog in (one loop)

Is it possible to do 2-channel non-regenerative analog output and a 2-channel analog input task in the same while loop?  Also using the same clock.  I have a rather large project and I was hoping to get away with a single Event Handling Loop that handles everything the DAQ is doing (it will also be doing digital output later).

 

Is there no way to avoid separate loops per task?  I keep getting read buffer overflow or write buffer underflow errors, and a few others, depending on how I set it up.  

 

*edit* This is using DAQmx by the way (PXIe-6356).  And I will attach a screenshot of just the "Generate" part that is happening inside the loop.

0 Kudos
Message 1 of 4
(2,524 Views)

 

If both tasks are set for the same sample rate and you write/read the same # samples per iteration of the loop, it should generally be fairly straightforward to have both in the same loop.  Very high sampling rates or high iteration rates make it trickier.

 

If you have different rates, you can still get there from here if you match up the time interval represented by the two tasks' # samples you write/read per iteration.

 

The fact you're querying each task for the "SamplesPerChannel" and using it as the # samples to write/read is likely your main problem.  Try dividing that # by 4 or 5 to give your tasks some breathing room.  The essential idea is that the AO write won't need to wait as long for buffer space to become available so that the AI read can take place before its buffer overflows.  

   You'd likely improve things *some* just by letting the AI Read occur in parallel to the AO calculation and write by removing the error cluster dataflow dependency.  But it'll be better in the long run to make the habit of writing/reading a smaller fraction of your buffers at a time.

 

 

-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 2 of 4
(2,483 Views)

Very informative answer, thanks a lot for taking the time.  I ended up breaking the AI into a separate loop (so now I have a main MHL + AI MHL + EHL in my DAQ sub-VI).  The data rates are moderate (100kHz at the moment, but I may need to go to 1MHz), so I'm not sure which option would be more stable in the end.  If I get to the point where things start to lag due to the number of parallel processes running I will try to squeeze the AI back into the main MHL and follow your suggestion for read/write elements.

 

Thanks again.

0 Kudos
Message 3 of 4
(2,475 Views)

Separate loops for AO and AI will make your life simpler.  I'd still advocate writing and reading in chunks that are smaller than the task buffer sizes.  A rule of thumb for AI is to read about 10 chunks per second, i.e., # samples to read = (sample rate / 10).   Good practice for AO depends a lot on whether you need to adjust the signal dynamically at run time and how much latency you can live with.   So there's no single rule of thumb.

 

 

-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 4 of 4
(2,473 Views)