CompactDAQ NI 9401 DIO PWM speed

[jyang72211]

I am thinking about using a NI9401 DIO to generate 4 PWM.  The module can do 100ns (10MHz).  If I want to generate 4 PWM, each at 1MHz with a CompactDAQ, I should be ok, right?  I assume I can do this, since the NI9401 is a correlated module, and I should be able to give the PWM waveform info to the module, and let it generate the PWMs without using software to toggle the line.  Since CompactDAQ is not real time like the CompactRIO, I am concerned that it may not have enough speed.  Comments?

[Renée · Accepted solution]

jyang72211,

From my understanding of your project, you should be able to do this.Keep in mind that for an update rate of 10MHz and a full cycle taking 1MHz, you can only change state 10 times per cycle (do 10 duty cycles). From the specifications found on our site for the 9401 it looks like the max clock rate is 10MHz, so that should be fine.

One thing to note is that you will probably have to use regeneration to get continuous output data, I doubt you'll be able to stream four waveforms at 10MHz over usb/ethernet. However, it is possible to get a glitch when you start trying to write a new waveform to the bugger when you are implementing regeneration in your project. This could be a problem for some applications, and not even noticed by others.

[jyang72211]

What did you mean by "I doubt you'll be able to stream four waveforms at 10MHz over usb/ethernet" and by "it is possible to get a glitch when you start trying to write a new waveform to the bugger when you are implementing regeneration in your project"?

What did you mean by bugger?  When you said regeneration, you meant the function of a correlated DAQMX module that can regenerate the same waveform over and over again through the hardware without software intervention, right?

[Renée]

jyang72211,

In regards to streaming over usb, the throughput of a typical usb would not be able to handle those signals.

I apologize for my mis-type on the last post. Bugger = buffer. To explain further, your device will continue to write the data which is currently in your buffer. If you are using regeneration, it will write the same data and therefore a glitch will occur. When you are updating your data, you cannot tell where in the buffer the device was just reading from, and therefore where the new data will be put. Because of this, the 'glitch' will give you either an unexpectedly short or long pulse due to the failure of the buffer pointer. This is especially important when through AO you have a step between two portions of the waveform where you were needing a smooth transition.

And yes, the regeneration can be done through your hardware. To do this, simply use a property node in your LabVIEW code.

[bstreiff]

If you're using the NI 9401 in a cDAQ-9171, 9174, 9178, 9181, 9188, or 9191 (basically, any cDAQ chassis that isn't the 9172), you also have four counters available on the chassis that can be exported through the 9401; you can use those for generating pulses without streaming a digital waveform, which may be considerably more bandwidth-efficient.

If you're generating pulses at a fixed 1MHz, look at the LabVIEW DAQmx example Gen Dig Pulse Train-Continuous.vi. If you need to vary the frequency and/or duty cycle, then the example Gen Dig Pulse Train-Buff-Implicit-Cont.vi demonstrates this.

(If you're using the 9172, then unfortunately you only have two counters; further, the 9172 is not capable of buffered counter output, so you can't use the latter example.)