Triggering Finite Buffered Counting and Stopping

[jstir]

Hello... still learning... I am trying to trigger the counting of digital events in LV 7.0 using an external TTL pulse. I have tried to modify "Count Digital Events-Buffered-Finite-Ext Clk.vi" that example with a trigger event. -See attached... I am getting the error that that is not supported? I just want to simply start counting when I get an input trigger...

Also, in this example, it continues to count untill the number of samples is reached. Though I can over-estimate this everytime, what is a simple wat to stop counting process if I see that I no longer need to keep collecting data? I am sure it is easy, but I have spent way too long getting nowhere;) 

And finally, what is the easiest way to output the data (counts) to a simple text format or somethign I can then import to Excel?

OK, then.. another question... in what version of DAQmx or MAX (or whatever controls that??) is duplicate count prevention the default? Do I still have to worry about setting that? And if so, how do I go about that?

Thanks

jeff

[jstir]

Just to clarify.. I have a 6601. I wish to initiate a digital train (no problem there) which serves as my clock, and then press "play" in the finite buffered counting, but not start actually counting until a trigger (TTL pulse) occurs. So, in this way I can be 'ready' to count, do other needed things to my detection system, and then when the trigger ocurs start counting. In this way I will not have thousands of data points in which there are zero counts.

Also, as I mentioned I wish to stop the process-which can be done via software (don't need to send a pulse). So, lets say my clock runs at 50 hertz, and I want to count over 5 min. So I set the # of samples to 15,000. But, I see that after 2 min. I no longer need to collect data, and therefore want to stop the counting and access the data up till I stopped it. If it were only a 3 min. difference everytime, it would not be a big deal, but in reality I dont know what the difference might be.

Thanks in advance

jeff

[Kevin_Price]

I can't open your vi from here, but I'll bet the problem is that you're trying to use a "Digital Start Trigger" with the counting task.  It turns out that this isn't the right way to set up triggering on counter input (measurement) tasks.  You'll instead need to use a DAQmx Trigger Property Node and configure an "Arm Start" trigger for your counting task.  This distinction isn't really treated as headline news in the docs and help, so it's easy to miss.

The key to stopping a task before its natural completion is not to rely solely on vi's that *want* to wait for completion.  The two most common would be the "Wait Until Task Done" vi and a call to DAQmx Read on a finite task without wiring a value to the '# to read' input.  I typically call a DAQmx Read property node to query '# available samples' in a loop.  The loop is wired to terminate on task completion, DAQ error, or user pressing a boolean 'Read Now' button.   If no error, I then call DAQmx Read, wiring in the '# available samples' value.

The easiest way to write your array of data to an Excel-friendly file would be to use 'Write to Spreadsheet File' or else 'Array to Spreadsheet String' followed by 'Write Characters to File.'

The default behavior of Duplicate Count Prevention has changed at different DAQmx versions for various types of boards.  Between that and the somewhat confusing name, I quit trying to keep it all straight.  I've rarely needed the feature, and when I do I simply run a few simple test cases on the particular board and DAQmx version in question.  Somewhere around 7.4 or 7.5 is where the default behavior became "the most likely useful" behavior so most apps won't require this property to be programmed explicitly.

-Kevin P.

[jstir]

Kevin P.,

Great! Thanks! Everything is working as it should now. I can start on a trigger, and stop when sample # reached or when I push a STOP button, and then it writes to a file. Thanks again!

jeff

And am i correct in this statement: these added WHILE loops will not slow down aquisition of counter data. IT will still count at rate of device and buffer data accordingly.

Also, in example there is a palce to set 'rate'. If I am using an external clock(gate), then I should just set the values equal. ie I have a 3333Hz clock (counts in 300 us 'bins'), so I should set the rate to be 3333 as well? If this is true, when would I ever have to change this value?

[Kevin_Price]

- correct, the counter data is collected by the hardware and won't be slowed down by your software loops.

- the 'rate' input is required, but I honestly rarely think twice about it.  I typically wire in a constant 1 which I intend to mean '1 Sample per clock edge.'   I really don't know how the 'rate' input gets used in a case like this or why it's a required input when specifying an external clock.   I suppose if you were measuring analog signals, then a rate input might be used as the 'dt' element of a waveform.  But there is no waveform read for counters, so...?  As long as you know your actual rate, it won't hurt to wire the correct value;  I'm just not sure it'll help either.

-Kevin P.