I think you were already on your way to the answer. Because the 9172 has a shared sample clock for the whole chasis, it is actually not possible for the modules to sample at different rates. To synchronize them all you need to do is include them in the same task and set your timing to the slowest rate (in your case 50 kS/s/CH). Hope this helps!
Because of the oversampling nature of these modules and the way they are designed, you can actually run both of them together at either 50 kS/s/ch or 51.2 kS/s/ch. The difference in the modules is discussed here. I believe by default they will both use the faster timebase and run at the faster (51.2) rate. Actually, from the NI-DAQmx Help:
When the NI 9234 is in a task with a C Series device that has a different sample clock timebase, NI-DAQmx always chooses the sample clock timebase with the highest frequency. To override this selection, you can set the sample clock timebase in the Sample Clock Timebase Source attribute/property.
Doug is right -- they do need to run at the same rate, but you should be able to choose which one. Let us know if you have more questions.
Hi Guys,Thank you for your prompt answer, although I still have some questions.I know before wrote you that I can run all the modules at the same sample rate.I've done it before; actually I have also another module 9201 which I think has 100kS/s for all the channels.
Today I run them all at 50kS/s. I know that will not be a problem for NI-9239 because is it's "native" sampling rate, and I'm not concern very much about synchronization with the 9201 module. My only "demand" is that to synchronize 9239 and 9234 samples. I read, but maybe I understand wrong that if you select an "invalid" sampling channel for 9234 module it will automatically sample with the next supported sampling rates (in my case 51.2kS/s). Also I know, but for this time I might be wrong that if you sample an higher sampler rate that the module clock can do, it will automatically copy the last value sampled available (for example, if I might sample with 51.2k the 9239 module in one second I will have 1200 "dummy" values, is that correct ? ).
Thank you for your support,
You bring up several good points. Let me call out a couple of things individually, so hopefully this thread will be a clear reference for people with similar questions in the future:
1) If you ask any task to run at a rate that is 'invalid' (cannot be generated from whatever timebase is being used), NI-DAQmx will round up to the nearest supported rate. You can check what rate it's using by reading the corresponding property node.
2) Only very slow modules (like the 9211, 9219...modules that can never sample faster than ~1 kHz) will return repeated ('dummy') data. This will never happen on a 9201, 9234, or 9239. That's important if you're doing frequency analysis on your measurements with those modules.
3) The 'valid' rates for the 9234 change when a 9239 is in the system, and vice versa. Because each of the modules contains a different timebase, the system can use either timebase to clock both modules. So your 9239 will actually run at 51.2 kS/s if you use the timebase from the 9234, or your 9234 will actually run at 50 kS/s if you use the timebase from the 9239.
4) As we've established already, if you're using both modules at the same time, they have to share a task, a timing engine, and a timebase, and therefore must run at the exact same rate.
5) NI-DAQmx will by default choose the faster timebase. (Faster is better, right?) You can override this with the attribute in my previous post.
And here's the important conclusion: Because of (1) and (5) particularly, if you use both modules together, and request a sampling rate of 50 kS/s, NI-DAQmx will choose the faster timebase and round your sampling rate up to 51.2 kS/s. You'll have to use the attribute if you really want to run at 50 kS/s. While this might seem odd behavior at first glance, it's actually a lot harder to figure out what the user might want to do when the rates aren't nice round numbers like 50,000, and these rules turn out to be a pretty reasonable way to deal with a confusing situation. Take my word for it 😉
I'm not sure why you're not seeing the error, but I did check the behavior with a simulated 9234 and 9239, and got the expected result. See attached screenshot. It sounds like you understand now, though. If you figure out why yours doesn't overflow, I'd be curious to know.