There's another possibility that requires more manual configuration to generate the finite pulse train. However, it can be used for pulse train freqs that are too fast for the software polling suggested earlier. Be aware that it requires a relatively advanced use of the counters that'll take some learning curve time and effort.
The way finite pulse trains work "under the hood" is that one counter generates a single "gating" pulse and the other counter generates pulses only while that gating pulse is active. The DAQmx driver figures out the right duration for the gating pulse so that its active time produces the requested # of pulses.
You can also do this by configuring the 2 counters separately to perform the same function. By doing it this way, you'll have a separate task handle referring to the gating pulse counter, which you can use to query its "progress".
Another little factoid about pulse generation: the internal count register is alternately loaded with countdown values representing the low time and high time of the pulse. Each edge at the counter's source (usually an internal timebase such as 20 MHz) causes the internal count register to decrement. When it reaches the terminal count, 0, the output toggles state and the count is reset to the other countdown value.
So if you configure your gating pulse counter for an extremely short low time like 1 usec, then by the time you can make the software calls to start the task and query the count register, it'll be doing the countdown of its high time. Your knowledge of the timebase used, the max countdown value and the present count value and the other counter's pulse train freq can all be used together to determine how many pulses have been generated.
-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.
