DAQmx Timing and Hardware Timing don't match

[kashi13]

Hello NI Forum,

I'm having difficulties understanding why my sampling rates don't correlate to the output on my DAQ. 

So, a little background: I am using an X-Series USB 6343 and trying to communicate to a chip with SPI. (Yes, I am aware that my hardware is not intended for SPI.) I'm attempting to follow the example found here: https://decibel.ni.com/content/docs/DOC-26290/version

My chip requires a clock input (DO) and chip select input (DO) to trigger the SPI output (DI) communication (see timing info). 

Currently I have my DAQ connected to an oscilloscope so I can monitor the output and the frequency being read on Labview and the Frequency being read on the oscilloscope do not allign. 

Any help or ideas would be largely appreciated!

[David-H]

Hi kashi,

When you say you are "monitor(ing) the output and the frequency being read on LabVIEW and the frequency being read on the oscilloscope do not align", which output are you referring to? The output of the 6343 or the SPI output?

Also, I don't see any DAQmx Counter functions in your vi... How are you realizing the frequency in LabVIEW?

[kashi13]

David, 

Great questions!

So, I am reading the output of the 6343 with the oscilloscope attempting to verify that the frequency is appropriate for the chip.

Secondly, I'm not sure I understand your question regarding "realizing the frequency in Labview". I am attempting to change the output frequency by adjusting the Sample Clock Rate, then checking it with an o-scope. Is this not correct?

[John_P1]

The hardware-timed digital outputs (in your case, the clock and CS lines) have to be combined into a single task assuming the lines are on the same 6343.

You must write data before starting the digital output task (otherwise the output is not buffered).  

Why this feature (hardware-timed non-buffered output) even exists in DAQmx I'm not 100% sure.  I believe it made its appearance before "hardware-timed single point" timing came about and now it is pretty much there for backwards compatibility (although I'm not even sure what the intended behavior is supposed to be when writing an array of data to a non-buffered task... to say the least it's a very strange use case).  For what it's worth, here's the reference to it from the DAQmx help:

Hardware-Timed Non-Buffered Sample Mode

In hardware-timed non-buffered sample mode, samples are acquired or generated continuously using hardware timing and no buffer. You enable this mode by using sample clock or change detection timing types and specifying a buffer size of 0. This mode is similar to hardware-timed single point sample mode but with slower performance and no error checking. Because there is no buffer if you use hardware-timed non-buffered sample mode, you should ensure that reads or writes execute fast enough to keep up with hardware timing.

Best Regards,