Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Use DAQmx Timing and Trigger Property Node together

Hello,

 

I was trying to do edge counting on my NI 6602 DAQ device and wanted to place both DAQmx Timing Property Node (to read the "Sample Rate") and DAQmx Trigger Property Node (to set up the trigger) after the DAQmx Timing Vi.

 

I tried to put two Property Nodes one after another. But then DAQ device stops performing the counting task. So I am wondering if there is a way to specify both properties (Timing and Trigger) at the same time?

 

Thank you,

Hiriam

0 Kudos
Message 1 of 7
(2,728 Views)

Yes, kind of.  There's a catch though.  Counter *input* tasks can't use a normal start trigger.  They can only use a special trigger known as an "Arm Start" trigger.

 

And there's probably another catch.  Most devices can't generate their own sample clock for counter input tasks.  You have to use some other external clock.  So a query for the clock rate probably isn't going to be helpful.

 

At the bottom is a pic to show how to set up an Arm Start trigger.

 

 

-Kevin P

 

Kevin_Price_0-1596411813485.png

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 7
(2,697 Views)

Hi Kevin,

 

I didn't notice the difference between Start Trigger and Arm Start Trigger before, so thank you!

 

Then I tried to place the two Property Nodes of "Arm Start Trigger" and "Timing" in sequence but it still gave me no counting, no matter which one I place right after Create Channel Vi. Any thoughts on this issue? Thank you!

 

Also, I was using an internal 80MHz timebase as the input of the counter and my actual signal from the physical device as the source of the Sample Clock, serving as the gate signal I presume. So whenever the Sample Clock ticks (ie, a gate signal is received), the counter value will be sampled at my specified sample rate, and transferred to PC memory then labVIEW software. And I wanted to check the sample rate to see if it was the same as what I specified.  Is there any error in my setup and understanding above? Please see the picture below for a brief illustration of my code. Thank you again!

 

Best,

Hiriam

0 Kudos
Message 3 of 7
(2,673 Views)

I don't see any particular problem with the config you showed.  Have you checked all your wiring and signal levels?   Maybe you could try generating your clock and trigger signals using other counters on your board to test.

 

The sample rate query isn't going to tell you anything.  Your task isn't trying to measure the timing of the external clock signal, it's configured for counting edges.  So it doesn't know anything about the timing of that external signal.  You'd need to use another counter and configure it to measure frequency.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 7
(2,643 Views)

Hello Kevin,

 

Thanks for your suggestions. I will give more thoughts on debugging this issue.

 

As to the Sample Rate, I thought this value was one of the internal parameters in the DAQmx function that can be directly output. Per your explanation, it seems like it isn't that simple and requires actual measurement. Thank you.

 

Hiriam

0 Kudos
Message 5 of 7
(2,630 Views)

Just to clarify: counter tasks are kinda unique in that sample clocks are almost always from some external source.  My comments about querying for sample rate apply to *any* task that relies on an external signal for its sample clock. 

 

The much more commonly discussed tasks like analog input and output commonly derive their own sample clocks from internal (and known) timebase clocks.  When DAQmx uses its own internal timing resources to generate a sample clock, then you *do* get a valid result when you query for the sample rate.   And it's sometimes a little important that you *should* because not all requested sample rates can be realized exactly.  In such cases, the query helps you to correctly identify the *actual* sample rate.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 7
(2,627 Views)

Thanks for your clarification. I was indeed using the internal timebase of the DAQ board as the source of the sample clock. 

 

I totally agree with querying for sample rate since the specified one may not be the actual one, especially if it is not a division of the timebase. And this is exactly the reason I wanted to know the actual sample rate.

 

Hiriam

0 Kudos
Message 7 of 7
(2,623 Views)