I think a deeper understanding of how the timing on the 9233 and 9237
modules work in conjunction with the I/O Node might be useful here.
The 9233 and 9237 incorporate Delta Sigma ADCs which are timed from
oscillators resident on the module (not from a clock generated inside
of the FPGA). This oscillator is divided by a limited set of
programmable intervals to produce the data rates presented in the FPGA
I/O Property Node. Once you tell the module to Start, it is constantly
converting data at the specified data rate for all channels regardless
of whether you call the I/O Node for the channel or not. The data rate
can only be changed by first calling Stop on the module and then
changing the rate in the I/O Property Node. When you call the I/O
Node, it simply waits for the next data point to be sampled and returns
that data. Based on this, here are a few suggestions I would
recommend for your program.
- The Sampling Rate control you are using to control the timing of
the loop is unnecessary and will potentially result in missed samples.
Since the I/O Node already blocks and waits for the next data point,
you should rely on it to control and limit the rate of the loop to the
programmed data rate.
- Do you want the 9233 and 9237 to always sample at the same rate or not?
- Yes. Since each module has its own oscillator, the devices
will not be synchronized by default and will drift over time. This
drift is likely the cause for why sometimes you see 50 kHz sampling
rates and at other times something lower. For example, let's say at
the instant where the I/O Node begins to execute the 9233 just finished
sampling the previous point and the 9237 is just about to begin its
next sample. This means the data from the 9237 will be available
immediately while the diagram will have to wait another 20 microseconds
for the next sample to show up from the 9233. To fix this problem,
right click on the module in the project and select properties. On the
properties page you should see options for selecting the master
timebase and for exporting it. On one module, you need to select the
check box that says export the timebase. On the second module, you
will now see the other module's timebase as a selectable option for
its timebase source. Select the other module's timebase and click
OK. Both modules should now be using the same clock and you will no
longer have to worry about drift.
- No. If this is the case, you will need a separate loop to read
from each module. Otherwise, the loop will only run at the rate of the
slowest module. At this point, you can either create a separate DMA
FIFO for each loop or multiplex the data from both modules across a
single DMA channel. I would recommend a separate FIFO for each loop
since the programming is usually more straight forward. If you find
yourself short on DMA channels, you will have no choice but to
multiplex the data. If this is the case, you will need to get rid of
the single cycle timed loop since your FIFO will now require
arbitration. You will also have to invent some data tagging scheme
such that the RT Host knows how to interpret the data on the other
end.
I hope this information helps. Good luck with your application.
