LabVIEW

cancel
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,

-Joe

0 Kudos
Message 1 of 14
(4,965 Views)

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

 

Brian G.
0 Kudos
Message 2 of 14
(4,943 Views)

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:

 

USB-6211.JPG

 

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

0 Kudos
Message 3 of 14
(4,929 Views)

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?

 

-Joe

0 Kudos
Message 4 of 14
(4,919 Views)

Hi JoeDG,

 

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

http://support.microsoft.com/kb/969238


Brian 

Brian G.
0 Kudos
Message 5 of 14
(4,910 Views)

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.

 

-Joe

0 Kudos
Message 6 of 14
(4,889 Views)

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 

Brian G.
0 Kudos
Message 7 of 14
(4,876 Views)

Brian,

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.

 

-Joe

0 Kudos
Message 8 of 14
(4,873 Views)

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
(4,870 Views)

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.

 

-Joe

0 Kudos
Message 10 of 14
(4,856 Views)