Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronize counter outputs with second one inverter from the first

Your code looks like it will literally "trigger one counter with the output of the other".   However, tt doesn't seem to me like such a great approach in an app where you're striving so hard for sync because it *requires* one pulse train to start earlier than the other.  And then to sync them up will require some special matching of timing settings for initial delay and polarity settings for the trigger that depend on the polarity settings of the other counter pulse.

 

I'd just generate a trigger with DIO and configure the counters to "see it" as the corresponding PFI line.

 

To change freq/duty cycle on the fly, be aware that you must write a frequency value to make the duty cycle update.  It's a little quirk that would be hard to know about until after a lot of puzzling troubleshooting and subsequent online searches.

 

As I said before, I didn't even know you could combine 2 counter channels into a single task.  I *did* know that if they were 2 separate tasks, you would *not* be able to change the two tasks' freq/duty cycle settings simultaneously.  It would require 1 software call to each task and you wouldn't be able to force them to execute *truly* simultaneously at the sub-microsec level.

 

Since you also couldn't do it with 2 channels in 1 task, you're fairly stuck trying to do this through software.   This is the point where you should probably just generate 1 pulse train in software and add an inverting circuit in hardware for your 2nd pulse train. 

 

 

-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 11 of 13
(640 Views)

Thanks for the great suggestions Kevin.  You wrote "I'd just generate a trigger with DIO and configure the counters to "see it" as the corresponding PFI line." I did get this to work, as shown on my first snippet. Unfortunately this eats up a hard DIO line which we are scarce on and want to leave for future expansion.

Also, in my application, it is acceptable if the second counter's "sync" is delayed by a few microseconds, so in that sense makes the software trigger approach preferable over using up a DIO line. Even with two counters on a single task and using a DIO for the trigger, I can't seem to change the frequency on the fly without loosing sync. Should this be possible? If so, I might be able to make a case to use up the extra DIO. Otherwise this approach offers no advantage in my application.

Attached 3 snippets with note in each as to caveat.

Snippet 1: Single task, DIO line as trigger. No stop/start when Freq changed. Caveat is  2nd channel looses sync when Frequency is changed.
Snippet 2: Two tasks, counter 1 triggers counter 2. No stop/start when Freq changed. Caveat is 2nd channel looses sync when Frequency is changed.
Snippet 3: Two tasks, counter 1 triggers counter 2. Task is stopped/started when Freq changed. Caveat is counter output go low when Freq changed = undesirable.

 

Can any of these methods be "tweaked" to maintain sync when the frequency is changed?
==Counter Sync, 1 task with DO Trigger + Freq Change, no stop-startCounter Sync, 1 task with DO Trigger + Freq Change, no stop-startCounter Sync, 2 tasks with internal Trigger + Freq Change, no stop-startCounter Sync, 2 tasks with internal Trigger + Freq Change, no stop-startCounter Sync, 2 tasks with internal Trigger + Freq Change, + stop-startCounter Sync, 2 tasks with internal Trigger + Freq Change, + stop-start

 

 

 

 

0 Kudos
Message 12 of 13
(631 Views)

I'm afraid I don't know of a way to force an on-the-fly *change* of freq and duty cycle to happen simultaneously on two different pulse trains tasks.  If there was going to be a way to do I'd have thought putting both counter channels into a common task would have been that way.  Since that didn't work, I doubt there's a better way that will.

 

An external inverting circuit will probably be the better option.

 

 

-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 13 of 13
(627 Views)