Yes it's possible but I kinda think it's not particularly advisable.
I'm assuming 2 reasonably high-res quadrature encoders, like maybe 1/10 degree or finer resolution. I'd first approach this with a regular sync'ed position capture. Both counter encoder tasks should be configured for the same "Arm Start" trigger signal, and the tasks should be started before that trigger asserts.
This gives you *direction* information too. Odd little vibration thingies can happen in the first instants of startup and it's at least conceivable that merely timestamping the first edge seen on each encoder isn't telling you what you want to know.
A good position capture at a high enough rate will let you see the startup dynamics of this position error pretty directly. The physics of the system are straightforward enough that you can always interpolate your data to estimate "time to reach position X", "time to reach position Y", etc.
If you really want a direct timing measurement, you can do it by setting up edge counting tasks in a kinda inside-out way. You'd configure the encoder signal to be the sample clock while using some fixed clock as the edge count terminal. Each encoder edge buffers up a count # which represents # of cycles of a known clock rate, i.e., *time*. You'd still need the shared "Arm Start" trigger to sync the two tasks to have the same t0.
-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.
