Dunno about the rest of the motion system, but steppers will tend to give you some noticeable vibration superimposed on the average speed. The dominant freq is likely going at the step rate due to the torque impulses.
For circumstances where you don't want to see that vibration, you should derive the analog sample clock from the step pulses. This will tend to filter out all of the step response vibration -- much like sampling a sine wave at exactly the sine wave's freq, which just looks like DC.
On the other hand, perhaps you *do* need to be aware of how much vibration is being superimposed on your nominal motion. In that case, you should sample at ~10x or more of your step rate, and you'll see a much noisier looking response.
Now, other things:
1. It's pretty straightforward to use your step pulse as an external sample clock and take readings on every step. Personally, I'd start this way rather than trying schemes that sample on every 5th pulse. You can always discard or ignore 4/5 of the samples later in post-processing if you wish. (Aside: I know the older driver that isn't compatible with M-series boards had a method allowing you to specify an integer divisor of an external timebase for analog sampling. I've never explored whether that capability is available under DAQmx. If so, that'd be the cleanest implementation to use.)
2. I agree that you should track your commanded position with 1 of your counters. I would also recommend some kind of method for repeatably establishing a reference ("home") position somewhere. If the system has been designed and spec'ed well, commanded steps should reliably produce actual steps of motion. If not, then maybe not, and you'll need to verify or re-establish home now and again.
3. If 1 counter is tied up with counting steps, the other counter will need to do continuous generation. You won't be able to move exact distances because you'll need to issue software-timed task stoppages. But since your other counter is counting pulses, you'll at least know where you *did* stop.
4. A possible sneaky trick idea if you can get a DAQ device with analog output. If you can route the AO task's sample clock to one of the PFI terminal pins, you could generate exact #'s of step pulses with a finite AO task. Then 1 counter can count the pulses and the other counter could, if you choose, divide by 5 to create an AI sample clock.
Hope these ideas help. Sorry, I'm only a LabVIEW and hardware user and have nothing to offer on syntax.
-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.
