Will,
You've got a fairly difficult problem. You want to:
a) ramp a frequency up or down
b) exactly control the total # of pulses
It's fairly straightforward to do either a or b, but both at once is trickier. The fact that you're using the pulsetrain to drive a stepper motor adds another complication.
1. You're ramping a stepper. So you definitely shouldn't plan to stop and re-start your pulsetrain. Any frequency changes need to be done on-the-fly. [see note 3 below]
2. The warning message occurs because you've defined a # of pulses for the "finite sampling" task. However, you are then stopping that task every 10 msec -- probably not long enough to allow all those pulses to be generated.
3. I also had an app for driving a stepper for a precise # of pulses. I also tried to ramp the frequency up by changing frequency on-the-fly. I got an error too. The reason is because of how DAQmx actually implements a finite pulse train. (Description based on inference and having looked under the hood at the traditional NI-DAQ implementation. Would welcome corrections from any NI person.)
When you ask for a finite pulse train, the counter is actually configured for a "gated" (traditional NI-DAQ term) or "pause-triggered" (DAQmx term) continuous pulse train. Then the board's other counter is used to generate a single pulse. In this setup, your counter only shows pulses at its output pin while the other counter is within its pulse's ON time. By precisely controlling this ON time, you can also control the precise # of pulses that reach the output pin of the main counter.
The problem is that if you change the frequency part way through, the original timing relationships would no longer be true, which could cause you to produce a different # of output pulses. So DAQmx gives you an error in order to make sure you get exactly the # of pulses you asked for.
4. I had an idea for how to implement a precise # of pulses with a varying frequency, but had to abandon it because the method required a minimum of 2 pulses. In my app, I frequently needed to generate 1 single pulse. (In the end, I had to live with constant-frequency stepping. The slower speeed was only an inconvenience for total test throughput -- it didn't affect the system under test.)
I never implemented and tested the idea, but here's an outline of what I remember:
A. Setup counter 0 for pause-triggered continuous pulse generation, using output of counter 1 as the pause trigger. I think the active pause trigger level should be Low.
B. Setup counter 1 for edge counting, using an initial count == total # of pulses. Configure it to count down (decrement) on active edges and configure its output to "toggle" on terminal count.
C. In your vi, be sure to start counter 1 before counter 0. You should also stop counter 0 before counter 1.
D. In your vi, you can query the count of counter 1 to determine how many steps are left -- this may help you decide when to start ramping down.
E. In your vi, you can vary the frequency of counter 0 on-the-fly without generating an error!
More Description:
Counter 1 is programmed to count down counter 0's step pulses. When counter 0 is started, pulses will appear at the output right away because counter 1's output starts low. Each pulse decrements counter 1 until counter 1 counts down to terminal count (0). On that edge, counter 1's output switches to high (because it's set to "toggle" on terminal count). At this point, pause-triggering stops counter 0's pulses from reaching the output pin. And counter 1 stops receiving edges to count down. By querying counter 1's output state, you can detect when this happens and stop the counter tasks.
-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.
