LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx: write a finite number of samples in a loop but timing is not respected

Solved!
Go to solution
Solution
Accepted by topic author MAILFERTSeb

1. When configured for Continuous Samples, try setting your constant to "Allow Regeneration" (instead of "Do Not...").   Then you only need to pre-write once before starting the task, and never need to write again inside the loop.

    Note that the ending won't be hardware-precise because it'll still be based on software reaction time for loop termination.

 

2. The following *might* work, I'm not near hw to test.  But I think DAQmx has smartened up a lot over the years when it comes to repetitive outputs.  It supports some things at the driver level now that used to be more or less impossible at the application level.

    So I think you can now combine "Allow Regeneration" with Finite Sampling.  Write the pattern just once before starting the task, like before.  But now you specify the total # of samples to generate in the call to DAQmx Timing.  Ask it to generate 1.21 giga-samples or whatever and the task will then have a hardware-timed endpoint..

   I *think*.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 11 of 13
(1,543 Views)

Dear Kevin and the other guys who helped me.

Here is the solution: to send 10 times 10000 samples per example, we just need to "do not allow regeneration", use "finite samples" and say that we are sending 100000 samples. We pre-write sample and then create a loop with 10 loops and send 1000 samples at each loop.

Thanks for your precious help.

Solution.PNG

 

Best regards.

Sébastien

Message 12 of 13
(1,516 Views)

Your VI works as expected and demonstrates the output  you wanted.

It looks to me there might have been a mix-up between the sample rate of the DO clock sampling, and "sample rate" understood as number of pulses per second in one wavelet you create. As clock sampling is much faster than the frequency of your pulses in the wavelet, you might get much shorter "real time" if you compute it using clock sample rate times your number of pulses.

0 Kudos
Message 13 of 13
(1,463 Views)