Finite sample AO generation with external clock always reports one sample short

[Phamton]

I am using a PCI-6722 to generate a finite number of analog output samples.  I'm trying to use an external sample clock and find that it always reports one sample less than what was actually generated.  I first encountered this problem with a program written in C# which I am less familiar with, so I wrote a test program in Labview 2010 (NI-DAQmx 9.2.3) and also tried it using a MAX task.  

I monitor the external clock and the analog output on a scope and see that the correct number of clock pulses and analog output samples are generated.  However using a DAQmx Wait Until Done task times out and if I query the TotalSampPerChanGenerated property it reports one less sample generated (e.g. if I generate 10 clock pulses, I see 10 analog output updates, but TotalSampPerChanGenerated gives 9).  This seems to be true regardless of the number of samples (I've seen instances with other boards where multiples of various powers of two were required).  If I give the board an extra sample clock everything works fine.  Is this a "feature", a board problem, or am I doing something wrong?  I've attached the quick and dirty VI I used to test the problem.  I route the SampleClock from a digital board, Dev1, to PFI4 then externally connect this to PFI0 of the PCI-6722, Dev3.  Thanks,

Paul

[Joseph-S]

Hi Paul,

Based on how you have your error wires hooked up, It looks like the task for dev1 is starting before the VI reaches the 2nd row where the sample clock is exported. I'm still not entirely sure why the total samples would be reported as one less than what you are reading from the scope, but please try starting the task for dev1 first and adding the wait until done in again and let me know what the result is. You can do this by using a flat sequence structure as shown below.

[Phamton]

The order was purposeful.  I want to start the analog output task (dev3) and have it wait for an external sample clock to be generated by dev1.  I believe if I do it the way you've suggested and start the master board (dev1) which is generating the sample clock before I start the analog output task, there's a chance the analog output could miss the first clock pulse.

[Joseph-S]

Hi Paul,

My apologies, you are absolutely correct. For some reason I thought you were doing continuous pulse generation with dev1 and that synchronization was not an issue. Since synchronization is indeed an issue, you should be sharing a start trigger in addition to the sample clock. You'll need to export a trigger from dev1 to dev3. This concept is explained in more detail in this Developer Zone article: http://zone.ni.com/devzone/cda/tut/p/id/6829 under the section "Multi-Device Synchronization". Although the title refers to USB DAQ, the concepts are equally as valid for your case.

[Phamton]

Hi John,

  In the software I've inherited the triggering is software controlled- the slaves are all started before the master board which generates the sample clock.  I believe my test code above accomplishes the same thing.  Is there something further that I need to do for the triggering?

Paul

[Joseph-S]

Hi Paul,

Since you are reading the correct number of pulses on the scope, it seems like the triggering is not the issue. My apologies for making that assumption from the start. If you try to read the number of digital samples generated for dev1, what does it report?

[Kevin_Price]

I don't have the relevant daq hw here to test this, but here's a kind of oddball idea: try configuring your AO task for continuous sampling rather than finite.   Theoretically, it doesn't seem like it should matter since the finite sampling digital task controls the # of sample clocks anyway.  But hey, you never know.

(That's the construct I would typically use when one master task is doing finite sampling.  One reason is that it opens up the possiblity

to stop and restart sampling on the slave tasks without having to stop and restart the tasks themselves.  Sometimes that's really handy

and even when not needed, I've found it doesn't hurt.)

The only other thought relates to putting a short delay between ending the digital task and querying the AO task.  Possibly even going back to the DAQmx Wait Until Done with a sufficiently long non-default timeout value wired in.

-Kevin P

[Phamton]

Since you are reading the correct number of pulses on the scope, it seems like the triggering is not the issue. My apologies for making that assumption from the start. If you try to read the number of digital samples generated for dev1, what does it report?

I wait for the digital task is done in the example, and if I add a property node it does report the correct number of pulses.  Since the digital task works fine and I see the correct waveform on the scope I don't think there is a problem with the digital task (I think I even tried using a pulse generator a while ago and saw the same thing).  Thanks again,

Paul

[Phamton]

---

Kevin Price wrote:

...try configuring your AO task for continuous sampling rather than finite...The only other thought relates to putting a short delay between ending the digital task and querying the AO task.  Possibly even going back to the DAQmx Wait Until Done with a sufficiently long non-default timeout value wired in.

-Kevin P

---

Hi Kevin,

   Thanks for the suggestions.  Unfortunately neither worked, even with a timeout of tens of seconds.  But as soon as I send one extra clock pulse the analog tasks finishes.

I've found a way to hack the old code I'm using to ignore errors if the number of clocks is only off by a few which is good enough for now..  It really seems to be a bug either in DAQmx or my particular board. 

Paul