To measure time intervals of a digital encoder signal, you'd want to set up a counter task. I'll assume you have a multifunction device and an available counter because that's what you'll need.
1. Configure the counter task for edge counting. When you call DAQmx Timing for that task, wire into the 'source' input the same terminal name you used when calling DAQmx Timing for you AI task. Now you'll have a shared sample clock.
2. You'll also need to configure a DAQmx Channel property node on your counter task where you'll specify the signal whose edges you want to count in order to track time between the encoder edges. Depending on your device, the best choice will probably be either 80MHzInternalTimebase or 100MHzInternalTimebase. The higher the freq, the better the time resolution of your measurement.
3. Start your AI and counter tasks before the encoder is put into motion. (There are probably workarounds if this isn't possible, but it's simpler if you *can* do it this way.)
3. Your counter task samples will represent "total # cycles of the internal timebase" from task start until the sample # in question. The very 1st value is a likely meaningless offset that you can subtract off of all the count values (including the 1st, turning it into a 0.) If you were to divide by the timebase freq you'd get an array of "timestamps" in units of seconds relative to 1st encoder edge.
4. There are a couple subtleties related to rollover of the 32-bit counter. This is also referred to as the counter reaching terminal count. If you run for as much as a minute or more, you'll encounter this. (time of rollover = 2^32 / timebase_Hz).
A nice feature of unsigned 32-bit math is that a finite difference of the raw u32 count values will end up compensating for this rollover effect. The largest possible u32 value is (2^32-1). Add 1 to it and you'll get 0. Subtract 1 and you'll get (2^32-1) again. For the same reason, a finite difference of consecutive values will be correct even if there was a 32-bit rollover between them.
5. If you need to accumulate these interval times, you'll need to convert to a datatype that can handle a bigger range of values. You'll probably be fine going straight to DBL so you can work in units of seconds. I usually hang around in integer world as long as possible by converting first to 64-bit ints. It's mostly just a habit to avoid accumulation of floating-point roundoff error, but it probably usually isn't crucial. It tends to take quite a bit of processing to become non-negligible.
-Kevin P
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
