First things first. The "right way" to do this is to use the encoder as an external sample clock that drives an analog acquisition task. (Perhaps it would also drive a position measurement task, depending on overall needs).
Given what you've shared so far however, it doesn't sound like that's a feasible option for your laser displacement sensor driver. So you'll probably need to choose between using different equipment that supports the "right way", or settle for making a non-ideal method the "least wrong" that you can.
If there's no means to force hardware-timing correlation between the laser displacement values and your encoder, then you're stuck with imperfect software-timing correlation. The only good news there is that you can probably stick with your simple software-timed counter query since you're already in the imperfect realm of software timing.
How to *best* correlate that with the data you get from the mfgr's driver depends predominantly on that driver, which no one here knows anything about. About the only advice I can give is that careful attention to dataflow on your part will tend to help preserve that "least wrong" correlation instead of making it worse.
-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.
