implicit clock overwriting wired sample clock rate

[laurens17]

I have one implicit clock and two sample clocks in a VI code.  The top section of the code creates a line of square pulses at a “rate of trigger” (implicit clock), the middle section reads APD pulses from an input channel at a “rate of voltage” (sample clock) and the bottom section creates triangular waves at a “rate of voltage” (from “pattern”, also sample clock).  To get all of these processes to terminate correctly and at the same time, I connect “Terminal name with device prefix” – which is associated with the implicit clock, to the “source” of all the sample clocks.  (see pictures “Allsourceconneted_1” and 2)

Even though the bottom sample clock has its own frequency (rate of voltage), it still produces triangular waves at a rate of “rate of trigger”, due to, I am assuming, the connection to the implicit clock.  If I terminate the connection between “Terminal name with device prefix” and “source” for the bottom sample clock (see picture “disconnectbottom”), then it will produce the correct “rate of voltage”. However, the problem is that this bottom section will continue indefinitely and will never terminate the code, even after the “number of samples” exceeds “data” (see the while loop). 

How can I get everything to terminate at the same time, but still have different rates between my implicit clock and my two sample clocks?  Why does the bottom sample clock not follow the wired rate of "rate of voltage"?

[Kevin_Price]

First I'd like to get clear on terminology.   Under DAQmx there's a very clear distinction between a "trigger" and a "sample clock", and it'll be helpful if we can follow those terms consistently.  I have a feeling we're heading toward needing to deal with both.

In your description, it sounds like you want both the APD counting task and the AO generation task to sample at the same rate, probably by running off the same sample clock.  If that's the case, I don't understand the purpose of the upper counter pulsetrain generation task.  It sounds like you mainly want it to help you get the other tasks to terminate at the same time, but there are better ways to do that.

The code should terminate the first time the DAQmx Read call for the APD task returns the requested # of samples.   This kind of usage would usually call for setting up "Finite Samples" rather than "Continuous Samples", though your way ought to still work.  What are typical values for 'Rate of voltages' and 'number of samples'?   I ask b/c there's a chance you're asking your task for too many samples and generating an error instead of receiving data.  Even so, I'm surprised you don't get the loop to terminate, it looks like it should.  The request for samples should either return the # requested or produce an error, either of which should terminate the loop.  Are you getting errors?

Below is a snippet that you can use in LabVIEW 2013 or later.  (Save the image as a .png file, then drag the file onto a blank LabVIEW diagram.  Poof!  Real code!)  It shows a different way to sync your AO and APD tasks without needing the pulsetrain task.  You should be able to attach it to your loop code and get the expected termination.

-Kevin P

[laurens17]

Thank you so much for your reply!  You were right, the implicit clock was needed to be connected to be a sample rate to count the APD, and it reality wasn't the "trigger" at all.  I also tried a lot of different permutations playing with the "finite samples" rather than the "continuous samples".  The rate of voltages corresponds to the number of samples, but I needed to get a different "rate of trigger" that does NOT correspond to the number of samples, creating problems when I tried to go to finite samples. 

Turns out, to get it what I needed to do, I had to create a new channel for the "triggering" portion and leave the sample rate for the APD as it was.  Now I have two seperate rates and everything terminates propertly.  I just needed to leave it as it was and create a new channel. Below is my new code (messy yes, but I'll clean it up later, turns out that the "rates of voltages" and "rates of trigger" are related.)  

Thanks again!