07-09-2010 05:56 AM
I have a cDAQ-9174 chasis with
AI---- NI 9205, NI 9205
AI---- NI 9219
DIO---- NI 9401.
''NI-DAQmx allows onboard clock routing to synchronize multiple data acquisition or generation operations. A single timing or trigger signal can be shared between multiple operations on the same device to ensure that the data is synchronized. These signals are shared by simple signal routing functions that enable built in connections on the DAQ device.''(from http://zone.ni.com/devzone/cda/tut/p/id/6829)
When I check the 'The Device Routes tab in MAX' for chasis and c modules individually, I found lots of clocks with the green blocks(Direct Route). ''Once a physical connection is determined, the NI-DAQmx driver allows the user to quickly and easily use this connection to synchronize operations.''
Now my question is how to choose from these available clocks. What is the frequency of these clocks? The higher frequency the better? What is the difference between /Ctr0SampleClock, /Ctr0InternalOutput, /Ctr0Source, /Ctr0A?
For example, why to choose /Dev1/ai/SampleClock or Ctr0InternalOutput or many others specially as the source for the DAQmx Timing (Sample Clock).vi?
Thanks a lot for all your help
Bing
Regards
Solved! Go to Solution.
07-13-2010 12:06 PM - edited 07-13-2010 12:09 PM
Hello NCLbingji,
I believe you are mixing up instructions from different hardware manuals. The link you posted refers to synchronising multiple separate devices, while your cDAQ with its modules really is like having a single device almost. You would find more relevant information in your cDAQ chassis manual. For multiple devices you do indeed need a "physical connection", however with the cDAQ this is not necessary. You define these connections in software in a way, and this should get the routing sorted on the driver level.
Try identifying which channel will be your "primary" one, the one to drive all others and set the synchronisation, then set this channel's SampleClock as the trigger (DAQmx Trigger.vi) to the rest of the channels ("secondary"), then start all "secondary" tasks, and finally start your "primary" task. This will trigger all tasks at the same time. Have a look at the attached picture which is from another application I worked on, but I think it will help.
I hope this helps,
Kind Regards,
Michael S.
Applications Engineer
NI UK & Ireland
05-10-2012 08:11 AM
Dear all,
I am trying to figure out what am I doing wrong in attached Vis. So, I am trying to read data from two modules (cDAQ1Mod1 = 9201, cDAQ1Mod2 = 9205) simultaneously. I use 9174 chassis. Rate for the first module (9201) is 50k, for the second (9205) I used 10k.
I used methods for synchronization from old Topics here. In each Vis I measured time between start times of two waveforms from modules. On each start of application I get different time difference, sometimes that difference is big (aprox. few milliseconds) but sometimes is a few microsecond. But I would like to avoid that time shift (I would like to read channels (or tasks) at the same time, simultaneous). Is that possible with cDAQ equipment? Or I have to use something with simultaneous reading without modules with multiplexors. Now I am using solution test_1 (picture bellow) with few miliseconds time shift (sometimes when I am lucky at starting app. I get few microseconds.
Thanks and sorry if I didn't see that somebody already has solved this problem. I also posted that on
Regards,
Voltic
05-10-2012 06:18 PM
Hi Voltic,
You probably aren't getting any responses because you are posting in other people's threads. It would be better to start your own. That said, I have good news. Your application is synchronized and working as expected (sort of), it just looks like it isn't.
First off, have you tried measuring the same signal with both modules and detecting the phase difference? I bet you'll find it is pretty constant and small.
The actual problem you are having is that the t0 on the waveform is not accurate, especially for acquisitions that use a start trigger. The t0 time is when start is executed on the host machine, not when the trigger is detected. The milliseconds you are seeing is the time between when the starts execute.
If you want the times to match up, replace the second task's t0 with the first task's or ignore it entirely.
05-13-2012 08:15 PM
Hi MarkGrot,
So, as you said, my application is synchronized? Is that mean that measured sinus signals from both modules are in phase?
I measured the same signal with both modules and detect the phase difference. The time difference is pretty constant and small, but if I restart app again there are new time difference. Why this time is not constant? Because the time t0 on the waveform is not accurate? Is that a LabView bug?
Main question here is how can I achieve that that time difference is not too big i.e. I want that both modules start read tasks at the same time, simultaneous. Because that t0 time is important for me. Do I need to use some different trigger event? I know that those modules have multiplexer and it is impossible to start simultaneously, but It will be great if that t0 difference is a few microseconds (usually when I measure, it show me 80 microseconds, which is OK for me because I am sampling with 10kHz, that mean cca 1 sample of time difference between measured signals)
If you want the times to match up, replace the second task's t0 with the first task's or ignore it entirely. ---> I can do that, but first I would like to be sure that those signals I measured are in phase for real.
Thanks for your help,
Regards,
Voltic
05-14-2012 01:52 PM
Hi Voltic,
Yes, your application is synchronized. I ran your test VI but instead of comparing the t0 returned by the waveform, I did a phase comparison on the signals. I measured around 1us phase difference, though it depends on the signal you are measuring. You can also look at the sample clocks for the two tasks and verify that they are aligned.
If you detect a phase difference change from run to run, it's possibly due to the signal you are measureing, especially if you aren't acquiring enough samples when making the comparison. It can also be due to noise, the accuracy difference between the two devices, etc.
Ignore t0 if you are using triggers. This is not a LabVIEW bug. It's probably more accurate to say it is an unfortunate "feature" of DAQmx but working as intended. The t0 of the timestamp is not when your start trigger was detected. It is when you called start on the task. There is no way for you to get an exact timestamp for your start trigger.
05-14-2012 05:11 PM
Hi MarkGrot,
You can also look at the sample clocks for the two tasks and verify that they are aligned. --> how can I see those sample clocks? where are those? I would like to see them and plot them if it is possible.
Regards,
Voltic
05-14-2012 05:51 PM
Hi Voltic,
There are some topics in the DAQmx Help that might clear things up. First, you might want to read the Start Trigger Synchronization key concept page. This is what you are doing in your VI.
There are also lots of great topics and diagrams about how a sample clock works in the DAQmx Help. Just search for "sample clock". For example:
AI Sample Clock—The clock that controls the time interval between samples. Each time the sample clock ticks (produces a pulse), one sample per channel is acquired.
This means that you have one task that has a sample clock running at 50kHz and one at 10kHz. They are derived from the same master timebase so they won't drift. The start trigger gates your sample clock so you don't acquire any samples before the trigger occurs.
Because you are manually specifying your timing engines, your sample clocks are /cDAQ1/te0/sampleClock and /cDAQ1/te1/sampleClock. If you'd like to see the clocks you can export them through a PFI line on a digital module using the Export Signal property node and look at them on a scope. You can export your start trigger this way too. It is also possible to use a two-edge separation measurement to measure the time between the first sample clocks in each task. You should get a result in the 10s of ns.