Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

multiple pulse generation off master, 6602

I would like to generate 4 pulse trains phased with respect to the master pulse train. The example vi I am working with shows phasing relative to the preceeding pulse train (counter), so changing the phase of only one channel on the fly requires rephasing all subsequent channels. I would prefer not to do this. This example uses a "counter group" of 2 and sets the nth gate to the n-1 output ("other counter output"). Can I use a larger counter group and refer all channel gates back to the master pulse train? In doing so would this alleviate the need to use the Route Signal vi in going from one counter group to the next? I am using an 8 channel, NI 6602 card.
0 Kudos
Message 1 of 3
(3,482 Views)
Hi stormin,

Unfortunately, the NI-DAQ driver does not support counter groups yet. Some examples have been created assuming counter groups will one day be supported but not yet. You will have to program each counter separately with its own group. However, you should be able to have each gate reference a specific counter. In LabVIEW the constant for the VI would be "other counter output". In C function calls in NI-DAQ it would be "ND_OTHER_GPCTR_OUTPUT" and you would specify the output.

If internally routing only allows up to 1 counter, you could simply route the output from the card and route it back in as the gate to several counters. Anyway, hope that helps. Have a good day.

Ron
0 Kudos
Message 2 of 3
(3,482 Views)
I'd like to try to give you an answer, but I might first need to ask some questions:

A. Is the "Master" pulse train an external signal or something you are going to generate from the 6602?

B. You talk about phasing, so I assume that the other 4 pulse trains need to have the same frequency as the master -- is this correct?

C. Do you need both rising and falling edges to be phased to the Master, or only one of the edges?

Here's an outline for how to handle an external Master, where the other 4 pulse trains are at the same frequency but only the rising edges have the desired phasing relationship. (You could also do it this way for an internally-generated Master.) They will be directly referenced to the Master, so you can change the phasing on any one of them without affecting the others.

1. Physically wire the Master pulse train to a legal Gate input. (If your Master is internally generated you could use RTSI and save the screwdriver work.)

2. Program the other 4 counters to be in "retriggerable pulse" mode, using max internal timebase as a Source, and the pin from step (1) as a Gate. Program Gate polarity to be sensitive to rising edges. Output polarity can probably left as default (low state during delay or when inactive, high state during pulse). Each one has to be configured separately, using a unique group #

3. Program the pulse parameters to use for delay, and a minimal pulse duration. The short duration allows the counter to be ready to be re-triggered as soon as possible after the needed delay, allowing you to approach 360 degree lag.

4. It sounds like you already know how to pass in a new delay parameter "Pulse Spec 1" and issue the "Switch Cycle" command when you need to change the phase on the fly.
(If you have an internally generated Master where you can know the exact period, you could also have passed in the new pulse duration parameter "Pulse Spec 2" such that the sum is always == Master pulse train period. This way you can maintain phasing relationships on both rising *and* falling edges.)

However, if you have an external Master and need phasing on both rising and falling edges, I'm afraid I'm stumped.


Regarding "grouping" the counters: I don't think it can be done yet. But you can set up 4 individual counters with each one mapped to use the same physical signal for its programmed Gate (used here for retriggering).
Since all 4 will be programmed similarly, you might clean up your block diagram a bit by carrying the task id's through as an array, over which you auto-index a For loop. Also think about whether to pass the error cluster through as an array (individual error chain for each counter) or a shift register (shared for all slave counters).

Regarding "other counter output." This is more restricted than it might sound. You don't get to choose which "other" counter you want. You get what NI has predetermined as each counter's "other." Specifically, they are paired on the 6602 as follows:
(0,1), (2,3), (4,5), (6,7) so that Counter #3 is the "other" counter for Counter #2, vice versa, and likewise for each other pair.
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 3 of 3
(3,482 Views)