07-23-2012 04:11 PM
Hi Jirav Fadia,
Have you checked the information available at the following links?
Check it and let us know if you could apply it to your code and what is the failure in your synchronization.
07-23-2012 11:59 PM - edited 07-24-2012 12:02 AM
07-24-2012 11:24 AM
Ok, the *real* problem's pretty simple then. For high-speed sync'ed acquisition, DON'T TRUST WAVEFORM t0 VALUES! They seem to be software calls to a low-res time-of-day clock. I would calculate my own relative t0 in seconds for each waveform chunk based on something like:
(#_previously_acquired_samples / actual_sample_rate)
If you want time-of-day, just store it once when you first start sampling and add that timestamp to the relative secs calculation above.
Be aware that if you are acquiring over a long period of time, the M-series board may show some drift relative to the S-series boards. The solution is to derive all sample clocks from a common timebase. DAQmx is already doing that behind the scenes to keep the 4 S-series boards sync'ed with each other in a single task. You'll just need to derive the M-series sample clock from the same timebase.
07-24-2012 11:56 PM - edited 07-24-2012 11:58 PM
Yes, You are correct.
But as you know as i am acquiring same singal on both M series card and S series card (as of specifiec requirement of application to find relative effect of activities happen).
My S series cards work on Ref trigger, while my M series cards work on continuous acquisition. So i cant match relative time stamp in both cards as M series card will continuously acquired all singals irrespetive of trigger, while S series cards acquire data only when trigger comes. So how should i corelated both timestamp online. There is no common reference of time stamp for me to compare or edit timestamp.
Hope you understand my problem.
Inform me if you need any more information.
Thanks for your help.
07-25-2012 07:29 AM
Ok, gotcha. Sounds like you might have to stop and restart the ref-triggered tasks in order to acquire separate chunks of high-speed data, right?
The next idea then is to use an M-series counter to "timestamp" the successive triggers. I'd "arm start" trigger the counter off the M-series 1 kHz sample clock. Thus, your timekeeping counter will have a t=0 that corresponds to the 0th element of your continuous analog array. I'd probably use the counter in period measurement mode so that the count won't roll over internally. Then in software you can convert all the 32-bit period counts to 64-bit ints before doing a cumulative sum.
Sorry, a bit in a rush and gotta go. Hope this helps to get you a bit further...
07-25-2012 07:35 AM - edited 07-25-2012 07:35 AM
First of all thank you very much for your quick response.
I somehow got the idea of your concept..
But It would be nice of you if you can send me some snippet or more illustration.
07-25-2012 06:22 PM
Tried to start simple... but then kept going. This seemed to work using simulated devices I already had set up (simulated M-series for counter and slower AI, simulated X-series for faster AI).
It's quick & ugly & will only be a starting point. For example, the timing sync scheme drives everything from the fast AI sample clock at 1 MHz. I realized when I tried to wedge in the Ref Triggering at the last minute that the scheme is flawed. Ref Triggering requires Finite Sampling, Finite Sampling means the task will stop and restart, stopping and restarting the task will mess up the continuous sampling and counter timestamping.
I can't fiddle with it any longer, but I'd be inclined to use the other M-series counter as a master 1 MHz clock by generating a continuous pulse train. The fast AI can use it directly as a sample clock, the slow AI can divide it down by 1000, the counter timestamping can use it as its timebase.
07-30-2012 06:32 AM - edited 07-30-2012 06:33 AM
Thanks for your help. Sorry for late reply as I was busy with other activities.
Actually I just resolved it as shown in snippet.
What I have done is, Give the reference trigger of PXI 6133 to Counter line of PXI 6255. So whenever counter detects new edge at that time I will fetch timestamp from RT, which is same as Time stamp when Trigger detected in PXI 6133 and that time stamp will be logged to file for offline plotting of that 6133 triggered data. So Time stamp acquired from DAQmx (which is fetched after sample acquisition) is neglected and replaced with this manual fetch timestamp.
Hope you got the idea..
Thanks again for showing path to me.