I am moderately experience in FPGA programming and got a new task of acquiring vibration data from a NI 9230 module and writing it to a file (DMA FIFO from target to host). When setting up the module in the project, Data Rate is defined by a drop down under the 9230 properties. If the Read I/O node is in a while-loop by itself, does the I/O node drive the loop rate? or do I still need to incorporate a Loop Timer as shown below? The examples for the 9203 show no Loop Timer present in the acquisition loop.
Historically, most of my efforts have been control based applications and using the NI 9205 to acquire PV sensor values. It always used the Loop Timer to drive acquisition rate in the While-loop. Communication between FPGA and RT was done via FPGA front panel controls/indicators and FPGA VI ref's on the RT.
I guess I'm looking for the nuts and bolts walk through on how the below loop operates with and without the Loop Timer. When is the loop timer needed for controlling I/O Node Read/Writes? In the case of the 9230 having the data rate set in the properties of the project, if a Loop Timer is used that is slower than data rate set in the properties of the module, do you risk an overflow condition on some buffer that is internal to the 9230?
Solved! Go to Solution.
With FPGA hardware it is based on the hardware itself. This because you are close enough to the hardware that it is unlike say DAQ where you can dial in very specific sample rates. I'd go back to the hardware datasheet and review any shipping examples.
I believe the description of the "loop timer" function already answers the question to some extent: It states that the function will control the loop rate based on the value you specify unless other logic within the loop exceeds this timer value.
In your example, if the combined time of the 4 IO nodes (which is defined using the properties dialog) exceeds the loop timer value, then this will be the actual loop time.
It is also interesting to know what those IO nodes represent.
Each IO node element represents itself a VI which is hidden that provides a synchronized communication path to another hidden VI that handles the module communication (SPI).
Typically, these IO nodes will transfer information to this hidden vi on how to configure the general purpose IO expander which controls the signal mux and amplifier stages inside the module using SPI, and block execution until this hidden vi returns the value of the ADC.
(and some other magic for calibration)
The Minimum time between conversions influences to some extent how long the input signal is supplied to the input of the ADC after the mux and amplification, which results in a stable measurement within the specification of the ADC.
When in doubt, try to measure the loop rate using the "Tick Count" function
Thanks for the input. That basically answers my question.
Im just trying to understand what happens in the background for polling data from the C-series Modules and what controls data rate/loop rate and how best to structure my code. Based on what I have seen, it seems like the answer varies quite a bit depending on the module (and if it uses SAR or DSA ADC architecture)? Then you also have user controlled I/O sampling outlined in the link below.
"With FPGA hardware it is based on the hardware itself. This because you are close enough to the hardware that it is unlike say DAQ where you can dial in very specific sample rates. I'd go back to the hardware datasheet and review any shipping examples."
We have used the NI 9230 on a RT cDAQ programmed using DAQmx to acquire data. It wasnt till we post processed the data that we discovered that DAQmx wont coerce your sample rate displayed in the DAQmx task to one of the defined sample rates in the datasheet of the 9230. So if we requested 12.5kS/s in the task, the DAQmx task would display 12.5kS/s, but the actual sample rate would be 12.8kS/s, which is the closest sample rate defined in the data sheet.
So the sample rate get coerced at the modules, but the task setup does not.
It is indeed largely defined by the type of hardware.
The 9222 for example is capable of simultaneous sampling, so the module most likely has an ADC with 4 independent inputs.
That means that no time is lost on configuring a mux to set the proper signal path to the ADC input.
The physical link between an FPGA backplane and a C series module consists of 9 signals, which depending on the mode the module is in can have different functions.
(the NI-9401 for example exposes these signals almost directly to the output connector in normal mode, and uses auxiliary mode in which some of the pins are allocated to SPI functionality to control the muxes to set the input/output direction)
One of those pins is also dedicated to serve as a sampling clock source for the module's hardware.
The user-controlled IO sampling example most likely controls the output state of this pin directly from the "trigger" io node.
That means that all available SPI bandwidth can be spent on transferring those ADC register values to the FPGA backplane, using the auxiliary mode.
Which results in the fastest possible acquisition rate.