Showing results for 
Search instead for 
Did you mean: 

Analog output using DAQmx: Re-using the same task to output another waveform.

I'm trying to use DAQmx to play a WAV file out an analog output of a DAQ card.  I'd like to be able to play two WAV files consecutively, using the same DAQmx task.  The problem I'm seeing is that when I go to play the second WAV file the task is immediately marked "done" so that the "wait until done" VI returns immediately, and there is no output on the DAQ card.  If I put a manual wait before the "wait until done" VI, a some of the data is actually output, but it stops after a fraction of a second.


The attached VI replicates the problem.  It attempts to play a WAV file two times.  The second time through, only a portion of the wav file is output.  If "Delay Time" is set to zero, nothing is output on the second pass.


Also, here's a snippet of the code:

Play WAV file twice.png


Thanks in advance,


0 Kudos
Message 1 of 14

I downloaded your VI and tested it with an 8 second WAV file on a simulated device.  I measured the time it took from the first write to stop, and then from the second write to clear using tick counters.  Both times were roughly 8 seconds with no delay function.  I also confirmed that the same number of samples were written to the buffer each write iteration.


Are you seeing these same results, or does your VI stop before the second waveform is played?  Also, how large is your WAV file?  Here is a snippet of the code and results from the test.


Play WAV file twice test.png


Front panel.PNG




Brian G.
0 Kudos
Message 2 of 14

Thanks a lot, Brian.  Using your unmodified code, and with a simulated device, I get the same results as you:

simulated device.JPG


However, when I use my actual hardware (ao0 and ao1 on a USB-6211), I get the problem I described in my original post.  You can see that all the samples are written during each iteration, but in the second iteration, the output stops after only 70 msec:




So it looks like it's related to the USB-6211.  Any ideas?

0 Kudos
Message 3 of 14

Just an update: I tried this on different hardware (a USB-6259) and evething works fine.  Both iterations output for 8 seconds as expected.   


So something is different with my USB-6211.  Is there some reason it would behave differently, or is my particular unit acting up?



0 Kudos
Message 4 of 14

Hi JoeDG,


Have you installed the USB hotfix for Windows XP?  It's a long shot, but this might be the problem.


Brian G.
0 Kudos
Message 5 of 14

Thanks for the suggestion, Brian.  I'm not positive that the hotfix was installed, so I installed it again, but it didn't fix the problem.



0 Kudos
Message 6 of 14

Are you able to write the same waveform with two consecutive DAQmx Write functions (with auto-start disabled), and then use a DAQmx Start Task function to output both waveforms sequentially?



Brian G.
0 Kudos
Message 7 of 14


Yes, I am able to write both waveforms before starting the task, and then when I start the task the device does output both waveforms sequentially.  


I need to be able to programatically switch between waveforms, and the order and number of waveforms will change after the task has already been set up and the first waveform has started.  (similar to a media player) 


Attached is another VI that plays two different WAV files, one after the other using the same task.  On the USB-6211, the second waveform does not output, and no error is generated.  If I use a simulated device, however, the output takes twice as long.



0 Kudos
Message 8 of 14

If you attempt to perform a hardware-timed generation with the Auto-Start parameter of the Write function/VI set to True either because you explicitly set it to true or because you are using a single-sample Write function/VI, the operation might fail (EDIT NOTE:Read "might fail" as there is no way you are going to be able to tell if it will fail and if it DOES fail- well with Real hardware- theres no error- simulated hardware of course never fails)  because the samples that you write are not transferred to the device in time to generate the waveform. As a result, when performing hardware-timed generations, always write at least part of the waveform to generate before starting the task.


- So saith the Priests of DAQmx in NI-DAQ Help "Using the start task function."


NO No don't use autostart for nSample Finite writes.

This is expected behavior because you can't really predict what any device will do.


(I don't like it either!  I wish this unexpected behavior would changeSmiley Wink)

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 14

Thanks, Jeff.  I hadn't noticed that in the DAQmx help.  Unfortunately, explicitly calling the start task VI doesn't solve the problem.  


It appears that the samples are being correctly written, but the "Wait until done" VI is not working properly.  It returns "done" immediately, before the waveform is fully generated.  Here's a VI that illustrates the problem:

Play WAV in loop.png


Here the number of samples written should be identical for each loop (they are) and the loop times should be similar (they are not).  For an 8-second WAV file, my first loop iteration takes ~8 seconds, but the second loop iteration takes slightly longer than the 1-second delay.  This is because "Wait until done" returns immediately, even when the waveform is not done.  It's important to note that the waveform is being output during the 1 second delay.  This tells me (along with the correct # samples written) that the waveform is correctly written to the device.  The problem is that DAQmx thinks the task is done, when it is not.



0 Kudos
Message 10 of 14