Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO DAQmx synchronize internal signals

Solved!
Go to solution

Hello guys,

i want to generate a clock and trigger signal. the clock signal should start when the trigger starts. i cant figure out how to synchronize them. i attach my code..

is it possibe to generate the clock signal dependend on the trigger frequency? i know that i always want 3600 pulse in one period of my trigger frequency.

 

thanks in advance

 

Eric

0 Kudos
Message 1 of 6
(134 Views)

Is the trigger frequency controlled by you or at least constant and known?  If so, then yes, a counter can be configured to generate 3600 pulses within the interval between two triggers.

 

If not, then no.  You need foreknowledge about the time of the *next* trigger to know the time window available for your 3600 pulses.

 

 

-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 2 of 6
(115 Views)

yes it is calculated in another VI. how do i do it?

0 Kudos
Message 3 of 6
(100 Views)

I can't open your LV 2024 code.  Can you back-save to LV 2020 version?

 

The way I'd approach this is to configure a counter for retriggerable finite pulse train generation and set it to generate 3600 pulses.  I'd set the pulse train frequency to be *slightly* greater than (3600 * trigger_freq) to leave a tiny bit of time for the counter to rearm its trigger after delivering 3600 pulses and before the next trigger arrives.

 

This will make 1 interval out of every 3600 just a little longer than the rest.  But the alternative is worse.  If you set up the timing to try to make 3600 pulses fit *exactly*, you risk a signal-path race condition where the counter can't rearm in time to be ready for the next trigger and you miss one entire set of 3600 clock pulses.

 

 

-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 4 of 6
(87 Views)

that sounds like a good idea. thank you very much

0 Kudos
Message 5 of 6
(73 Views)
Solution
Accepted by transp0rsche

That's a decent start but there's several changes I'd recommend.  I don't have time to do them in-place right now, so here are some brief thoughts:

 

1. Clock counter should be configured to be triggered by the *output* of the trigger counter.  And then sequencing should change to make sure the clock task is started *before* the trigger task.

 

2. All the conditional configuration inside the loop should be happening *outside* the loop *before* starting the task.  Note that you can write new frequency / duty cycle pairs to a counter task on-the-fly without stopping and restarting.

 

3. Better logic is needed for when and how to change the clock frequency.  For example, whenever the trigger frequency is changed, you probably should want to recalculate and change the clock frequency too.  If faster, then change the clock freq first, if slower then change the trigger freq first.

 

Out of time for now...

 

 

-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 6 of 6
(59 Views)