DAQmx Hardware Timing Analog output

[WillemNL]

Hi, I am using LabVIEW 2014 and i want write an aribtrary waveform to my NI cDAQ-9178 and module NI 9263 (for now simulated). The only problem i have is the timing, I am quite new in LabVIEW and with the hardware. I have already looked at the examples but this becomes not clear to me what i am doing wrong. I got the error 200077 and this says: Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property. 

If i change the order of start vi (so before or after the loop) I get the error 200547 which has something to do with buffer size. 

What I want is that the module generates a sample each 0,001 seconds i.e. 1000 Hz. How do i do this? And how do i make sure the module exactly generates a signal with 1000 Hz with simulated hardware? So how can i check this before i use non-simulated hardware?

I have two versions of this: one where i write 1 sample to the module each loop iteration and one where i write an array of 1000 samples to a buffer in the hardware. 

Thank you in advance! 

Willem

[Kevin_Price · Accepted solution]

I made a few mods to your 2nd vi to show how you'd generate your pattern exactly 1 time using Finite Sampling with a 1000 Hz sample clock.  Of note: no more looping, just write the data to the task buffer and let the DAQmx driver do all the dirty work!

---

What I want is that the module generates a sample each 0,001 seconds i.e. 1000 Hz. How do i do this? 

For precise timing, always aim first for a buffered task (either Finite or Continuous) with hardware sampling.  HW-Timed Single Point is a special mode that requires software and hardware coordination, is rarely used under Windows, and is not supported by all devices (such as anything that connects via USB).

And how do i make sure the module exactly generates a signal with 1000 Hz with simulated hardware? So how can i check this before i use non-simulated hardware?

Briefly, you don't.  Simulated outputs do *not* generate the signal you write to the task.  How can they?  Where would that signal be without an actual device to generate it?  They're further limited in that they don't exactly mimic a real world device with respect to triggering and (some) timing behavior.

  Simulated devices are still useful though as they let you confirm the general syntax and config of your task.

-Kevin P

[WillemNL]

Hi Kevin!

Thank you very much for your response and explanation. Is there a limitation for the buffer? 

---

Briefly, you don't.  Simulated outputs do *not* generate the signal you write to the task.  How can they?  Where would that signal be without an actual device to generate it?  They're further limited in that they don't exactly mimic a real world device with respect to triggering and (some) timing behavior.

---

The reason i asked this is because I want to make sure that the code is correct before purchasing the NI 9263 module. But if there are no errors i can be sure that it is correct?!

Willem 

[Kevin_Price]

The buffer is only limited by available system memory.  I wouldn't get particularly concerned until I was well into the 100's of MB where it can sometimes get a little more difficult to acquire that big a chunk of *contiguous* memory.

The simulated device will let you confirm that your DAQmx programming approach is supported and feasible.  That's a big part of being "correct", but there are some aspects of correctness you'll still need to verify with hardware.   Still, your usage is pretty straightforward so the lack of errors with a simulated device should let you order the real device with confidence.

-Kevin P

[WillemNL]

Okay great, thanks!!

Willem