Extra 8-ball points to Jay for his hypothesis in spite of not being able to see your posted vi graph data from his phone!
To the OP: I'm inclined to amend my 110 msec remarks. They were based on a laser step function at ~0.53 sec and a force step-like function at ~0.64 sec with no other knowledge of what the system is all about. With more knowledge now, the interpretation changes.
Now I know that the force data is an impact with a maximum force magnitude occurring at ~0.67 sec. And I know the laser is measuring velocity. So the linear downward slope makes sense for something in freefall with constant (negative) acceleration. Not sure what's going on that makes it "come to life" at ~0.53 sec or the 2 brief dropouts. But the velocity starts showing non-linear curvature right around the beginning of the impact event. It pretty well flattens out a little after 1/2 way through the impact. I'd be guessing an inelastic collision as the velocity shows no sign of "bounce".
So now it seems to me that the timing discrepancy is pretty small, down in the realm of a handful of msec or less. Do you need to do better than that? You'll have your work cut out for you...
1. Although force Mod1/ai1 is first in the channel list, it appears to lag force Mod1/ai5 by ~3 msec. The effect of the convert clock mentioned by JÞB would account for only ~4 microsec and in the opposite direction.
2. I would expect Mod2/ai6 to align pretty closely to Mod1/ai1, probably using the standard minimum time from trigger signal to sample clock to convert clock. Even if I'm guessing wrong, any convert clock skew between the 2 tasks would be under 0.5 msec.
Something you *could* try is to use channel expansion to put all 3 channels in 1 task at the higher sample rate. But I doubt you'll be able to detect a difference.
3. Your data doesn't show any real step-function-like edges that let you compare signal timing to an extreme precision. My "handful of msec" remark is driven partly by the "fuzziness" of evaluating your data visually on the graphs, partly by the fairly apparent lag from one force measurement to the other.
4. Do you have access to an oscilloscope? That's a good way to capture simultaneously and compare to the DAQ results.
There's probably not much more I can do from afar. The true timing discrepancy seems to be pretty small and is likely to be mostly in your sensors or system, not the DAQ.
-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.
