LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

digital continuous output error at higher sample rate

Hi there, 

 

I have a problem getting the sample rate above 1x10^6 using the digital continuous output example (error attatched). I am trying to alternate two lasers around 100KHz. One laser turns on for 45us then 5us rest then the other turns on for 45us and so on in a loop until I stop it. I am new to labview so please use language I might understand thank you!

 

I am using a NI X Series for usb which should be capable of faster frequencies.VI should be attatched.

 

Thanks for helping.

Download All
0 Kudos
Message 1 of 4
(1,201 Views)

1. You might want to look into doing this with counter pulse trains instead of regular DO.  The timing would get set up in the hardware device one time and there'd be no possibility of buffer undeflow.   The only "trick" is getting the two counters sync'ed up.   Keywords will be "Arm Start Trigger" and "Initial Delay."

 

2. One problem I see in your code is a very small task buffer (100 samples), putting too much demand on the driver to move data across the USB bus.   There's more than one way to solve this:

  • Make the buffer bigger.  The buffer size is set by your first call to DAQmx Write where you appear to write 100 samples.  Try replicating that 100 sample array enough times that you can write more like 100k samples to the buffer.  That'd be 1/10th sec at 1 MHz sampling, which is a generous allowance for the DAQmx driver to manage USB data traffic.  10k samples (1/100th sec) is probably likely to work, but why not give yourself more headroom when you can?
  • Configure the task to use only the device's onboard buffer.  This is described in the X-series manual on page 6-12.   Here's a snippet showing the somewhat obscure DAQmx Channel property:

onboard regen.png

 

 

-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 4
(1,169 Views)

Hi Kevin,

 

Thanks so much for your help. I will try testing this out. Just in case it doesn't work and I'd have to use the counter train pulses, would this VI work just using the initial delay of 50us? (VI attatched). I don't really know how to use triggers. Thanks.

0 Kudos
Message 3 of 4
(1,152 Views)

I made some mods in-place to get you closer.  The attached vi ought to work if you start it running and then send a triggering pulse to configured 'trigger terminal' (PFI0 by default).   Any easy way to do it is to open another shipping example for single pulse generation and use ctr2 and an output terminal of PFI0.

 

Both outputs are set to regularly have 45 microsec high time and 55 microsec low time.  They're both configured to use the same "Arm Start Trigger" signal so they can start up simultaneously.  And then their initial delays differ by 50 microsec to offset the pulse trains them properly.

 

 

-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
(1,141 Views)