Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

CO.PulseDone inconsistent between buffered and non-buffered counter output tasks

I ran into something interesting today I thought I would share--it seems unexpected to me (possible bug?).

 

The CO.PulseDone property shows different behavior for buffered and non-buffered finite counter output tasks.  For non-buffered, it switches to high upon completion of the entire pulse train.  For buffered, it switches to high upon completion of the first pulse in the pulse train.

 

Here's my simple tester VI:

 

BufferedCounterDoneTester.png

 

 

 

In the buffered case the loop exits after ~1 second, while in the non-buffered case it exits after ~4.5 seconds:

BufferedCounterDoneFP.png

 

 

It seems the behavior should be consistent (and I don't see any use for the current buffered behavior).  

 

I'm in need of the non-buffered behavior (toggle once all the pulses have been output) for a buffered task.  I can't use Is Task Done? or the equivalent property because in my case I have a finite retriggerable buffered counter output (being retriggerable it is never "done" according to Is Task Done?) and I need to know when all of the pulses have finished generating (I'd prefer to not have to burn another counter to monitor this).  Maybe it's just late in the day and I'm overlooking something but I can't think of any other way to do it--the property node seemed like it should work but it only does so for non-buffered counter output tasks.  I'm using an X Series.

 

Any chance this behavior would be fixed in a later DAQmx release (I'm actually still using 9.3.5 at the moment so if this is already fixed please let me know)?  Or, is there some other way to tell when a buffered retriggerable counter output task has finished outputting its pulses without using a 2nd counter (or other subsystem)?  If I think of something else I'll post back (might just have to bite the bullet and use a 2nd counter if I don't find another solution soon).  If this is indeed a bug could I have the CAR ID for tracking purposes?

 

 

Best Regards,

John Passiak
0 Kudos
Message 1 of 4
(3,154 Views)

Hi John,

 

Thanks for bringing this up. I have searched our CAR database and could not find any CARs related to inconsistent behavior between buffered and non-buffered counter output tasks. I will test out your VI with an X-Series card and NI-DAQmx 9.5.1 driver and let you know the results I get. Also here is a helpful KB that deals with your application: DAQmx Counter Output: Pulse Done Property

 

 

Mikhail
RF Toolkits, Product Support Engineer
National Instruments
0 Kudos
Message 2 of 4
(3,129 Views)

Hi John,

 

I have tested your VI on USB-6343 X-Series card (with NI-DAQmx 9.5.1) and I got the same results as you reported. Refer to the images below:


non-buffered.png

 

buffered.png

 

I have filed a CAR on this issue: CAR #: 364784

Mikhail
RF Toolkits, Product Support Engineer
National Instruments
0 Kudos
Message 3 of 4
(3,116 Views)

Thanks.  The only reason that the buffered case isn't outputting all 5 pulses is that the task is being stopped immediately in software once the Pulse Done property goes high.  The only complaint I have is that Pulse Done is going high when it shouldn't.  The 1 second time represents when the first pulse of the pulse train has completed (buffered counter outputs don't use the initial delay for whatever reason so the full low time is waited before the pulse is started, see here).

 

 

Best Regards,

John Passiak
0 Kudos
Message 4 of 4
(3,112 Views)