01-15-2014 02:43 PM
Alrighty... thats definitely a useful piece of information. Based on this it seems my measurements are syncronized as once I remove the
t0(digital) - t0(analog)
---------------------------
dt
amount of samples from the beginning of digital signal then my signals are correct.
Now as I know this... is there a way to get rid of this math part and just get it right on the display right away?
thanks!
01-16-2014 07:35 AM
wait a second here... Sync supposed to mean that the measurements start at the same time (and go with the same sampling rate, in this case).
I dont really care about the t0, but if the digital signal has more samples before the event than the analog signal then it means the digital acquisition started earier than the analog, so they can not be sync'ed.
Let me know your thoughts.
01-16-2014 11:28 AM
It's because the samples you are throwing away were acquired before the start trigger. The digital input module is pretty straightforward. It gets a sample clock and produces a sample. For the analog input module you have, you can think of it like a 38 sample pipeline. When it gets a sample clock, that sample is put into the pipeline. When it gets the 39th sample clock, the first sample is available to read. It's more complicated than that but that's the basic data movement.
This means that if you were to create synchronized tasks for both modules and do a finite acquisition of say 50 samples, you would have ~12 valid AI samples and 50 valid DI samples.You would need to acquire an additional 38 samples of analog input data to have them align with the same number of samples. So if you did 88 AI samples and 50 DI samples, the 88th AI sample would correspond to the 50th DI sample.
As for tools to deal with it in LabVIEW, I don't think there's much other than the Sound and Vibration toolkit. There should be a number of examples dealing with it though.
01-24-2014 06:08 AM
I was able to resolve the problem completely by moving the start digital edge VI to the DI task and by its source to the AI sampleclock.
The solution is attached, the difference between the t0 parameters is in the nanosecond range!
Well done, Kudos to myself!
02-14-2014 03:04 AM - edited 02-14-2014 03:06 AM
1 facing much of the same problem but gets rhe error below trying to read the timing property node SampClk.src
2 what is appropriate to use as Trigger Source ?
using a NI-9205 and a NI-9422
Error -200983 occurred at Property Node DAQmx Timing (arg 1) in AI vs DI.vi
Possible reason(s):
You only can get the specified property while the task is reserved, committed or while the task is running.
Reserve, commit or start the task prior to getting the property.
Property: SampClk.Src
Task Name: _unnamedTask<F>