Timeout expires when writing waveform to analog output

[KnicksFan]

I am using the Basic Function Generator to write a waveform to an analog output port. Even when I set the number of samples on the Function Generator to a large number (say, 2e5), I get a timeout error ("Error -200474") with the possible reason "Specified operation did not complete, because the specified timeout expired." 

On the DAQmx Write function I looked at the output of "number of samples written per channel", and it seems to max out at 18,208. 

Anyone know why all samples aren't written out and the program is getting a timeout error? None of the functions I use have a setting for when timeout should occur. I attached my vi for reference. Thanks. 

[testproggie]

I was unable to figure out why, but if I removed the "DAQms Start Task.vi" it seemed to run OK. I hope somebody more informed than I can tell us why.

[mj0541]

The DAQmx Write function has a default timeout of 10 seconds. If you right click on the timeout terminal on the DAQmx Write VI and select create constant, you'll get a double constant with a value of 10. To avoid timing out, you can set the timeout value to be greater than the time it takes to generate your signal. 

For example, if your sample rate is 1000S/s and you want to generate 20,000 samples, then it would take 20 seconds to generate the signal. Set the timeout to be greater than 20 seconds.

I'm not sure why removing the Start Task VI stopped the timeout from happening.

[Kevin_Price · Accepted solution]

Oops, wrote up this whole reply yesterday evening and then forgot to click the "Post" button.  Meanwhile, I find it surprising that removing Start made things better, particularly if that was the *only* change you made.  I thought you would have also needed to wire a True to the 'auto start' input of the Write call.  And then you'd have needed to add some kind of delay, otherwise you were stopping the task immediately after writing to it.

---------

1. With a hardware-timed buffered AO generation task, you need to write your data to the task buffer *before* starting the task.

2. The default timeout value for DAQmx Read, Write, and Wait is 10 seconds.  You're generating 20 seconds worth of signal.  You'll need to wire a more appropriate timeout value instead of relying on the unwired default of 10 seconds.

Attached are some minimal mods I made.

-Kevin P

[KnicksFan]

Thank you for your reply.

I also found other examples online in which the write function is within a while loop (here and here). I guess in this case data is being written multiple times (with each time taking less than 10 seconds). Any chance you can explain if this strategy is better, or if it's better complete the task without a while loop as you have shown in your image?

Also didn't fully understand why data has to be written before starting the task, but I can read up more on this.

[dsb@NI]

I recommend a finite task when you want to generate a known, limited number of samples. Use a continuous task (writing in smaller chunks) when you want to generate a signal for an extended duration and you don't need to generate an exact, reproducible number of waveform samples. Are you trying to write a function generator? Did you already review the examples at <LabVIEW>\examples\DAQmx\Analog Output ?

[Kevin_Price]

RE: why write before start?

In a buffered hardware-clocked task, calling DAQmx Start will start the sample clock.  Each sample clock pulse will "slide" the preloaded samples along 1 position in the on-board FIFO as 1 new sample gets D/A converted.  But that can only happen if you've written samples to the task buffer before starting the task.  (In the background, the driver manages the process of moving samples from the task buffer down to the board).

With an unbuffered unclocked task (which you get by never calling DAQmx Timing), the sequence gets reversed.  Samples are D/A converted on-demand in response to discrete software calls to DAQmx Write.  So in *that* mode, it's necessary to Start the task *before* writing samples.

It makes sense, but it *does* take a little getting used to.

-Kevin P