From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-26-2007 03:50 PM
11-27-2007 11:33 AM
What you see is in the nature of how DAQmx manages finite pulse train generation. It actually uses 2 counters, where one of them is used to generate a single, hardware-timed "gating pulse" which controls how long the other counter's pulse train is generated, thereby also controlling the # of pulses generated. As an experiment, try performing continuous pulse train generation -- you'll see that the other counter no longer sends its output high.
Workarounds? That depends. I'm not near LV or hardware to experiment, but I *think* I recall reading a thread one time that discussed how to prevent an output pulse from being routed out to the terminal block pin. However, I'm not sure if that same technique would allow you to suppress the gating pulse in a finite pulse train generation. Ah yes, here's that posting.
If you can't suppress the gating pulse directly via the finite pulsetrain task, there *are* old-school ways to generate finite pulsetrains which should give you the ability to use the linked technique. You would configure for continuous generation but use the gating counter as a "pause trigger." You would also generate a single pulse with the gating counter after calculating the exact pulse width needed for the # pulses you want. After the single pulse task is done, you'd stop the continuous pulse train task.
-Kevin P.
11-27-2007 12:33 PM - edited 11-27-2007 12:35 PM