cRIO DMA FIFO data streaming frequency

[bszabo]

Hi,

I'm working on a project where I'd like to measure some acceleration and process/display the signal with LabVIEW. I've looked at some examples and so far this is where I got:

(FPGA)

FPGA

(RT)

RT

I'm able to receive the signal but I'm confused about the sampling frequency and unsure how the timing of the FIFO read/write changes it.

If I understand it correctly:

In the FPGA the "Loop time" variable controls how often reads the FPGA my analogue input card signal and puts it in the FIFO, even if the data rate of the card is set higher, right? What happens when I remove the loop timer? Will the writing frequency of the FIFO match the data rate of the card? Can it keep up even when the data rate is set very high?

And in the RT side, let's say I define a big buffer size to prevent overflow and I control with the "frame size" how many element I'm reading from the FIFO. So if my frame size is 3000 that means that I have 1000 data for each of the 3 channels, and those are equally spaced out in time based on the loop time in the FPGA. So in order to display the data real time in a running chart for example, I'd have to make a loop in my RT that is timed accordingly to my sampling frequency and add the points 1 by 1 to the chart? (Actually I'm using a network stream to transfer the data to the PC side and process/display it there, but that shouldn't influence the timing that much, right?)

Are my assumptions correct, or is there a better way to stream a data?

[cbutcher · Accepted solution]

Hi bszabo,

---

@bszabo wrote:

If I understand it correctly:

In the FPGA the "Loop time" variable controls how often reads the FPGA my analogue input card signal and puts it in the FIFO, even if the data rate of the card is set higher, right? What happens when I remove the loop timer? Will the writing frequency of the FIFO match the data rate of the card? Can it keep up even when the data rate is set very high?

---

Yes - your "Loop time(uSec)" control may limit the rate of the loop, depending on how long the Analog Input takes (and what value you set). The loop will take as long as the slowest elements (because of course everything inside has to finish).

When you say "data rate of the card", I guess you mean the maximum sampling speed? With the program you've shown, you may or may not be able to achieve the maximum rate - take a look at these links to get some more details:

How Many FPGA Clock Ticks Will My Analog Input or Output Node Require? 

Why Does User Controlled I/O Sampling Acquire Faster than an I/O Node? (might not be relevant depending on your hardware, but worth reading)

---

@bszabo wrote:

And in the RT side, let's say I define a big buffer size to prevent overflow and I control with the "frame size" how many element I'm reading from the FIFO. So if my frame size is 3000 that means that I have 1000 data for each of the 3 channels, and those are equally spaced out in time based on the loop time in the FPGA. So in order to display the data real time in a running chart for example, I'd have to make a loop in my RT that is timed accordingly to my sampling frequency and add the points 1 by 1 to the chart? (Actually I'm using a network stream to transfer the data to the PC side and process/display it there, but that shouldn't influence the timing that much, right?)

---

Well, I suppose in principle that might be true, but it definitely isn't what you should do. If you want to display in a chart, you should send blocks of data (because Network Streams add some overhead to each transmission, but you should do this even locally) and set the X-Scale Multiplier property appropriately for the loop rate.

You can write a 2D array of points to a Waveform Chart, and they'll update all at once with much lower CPU cost than trying to do one point at a time. On PC, you have no hope of getting updates at microsecond speeds (and you wouldn't see it anyway).

Using blocks of a few milliseconds (10, 50, 100?) will allow you to vastly reduce the CPU usage and make your VI more responsive, whilst still updating the graph frequently. At 10ms, it will probably look very smooth but the CPU usage will be higher. At 100ms you will of course be able to see the updates, because there will only be 10/s, but that's still fairly responsive. You should try a few values and see what works well for you.

As a side note, if you use an XY-graph instead, you'll need an X-array, but you don't need to do them one at a time there either - in both the chart and {waveform,XY} graph cases, you should write blocks of data.

[MrJackHamilton]

I would add to the excellent response, that you'll need to use a Queue to pass the data from the FIFO receiving loop in the RT to another loop in the RT where your display graph is.

UI updates rates are limited..and if you put the plotting in the same loop as the FIFO read, there will be no end of pain, trying to get the FIFO buffer tuned to read at the graph throttled loop rate can run.

Decouple those loops with a Queue. You have to 'tune' the FIFO recevie loop on the RT even without the graph - its part of the FIFO RT coding in LabVIEWland. It something that you need to do, as the RT FIFO implementation is not interrupt driven on the RT. [I wish it was...NI are you reading this?...]

Jack

[cbutcher]

---

@MrJackHamilton wrote:

Decouple those loops with a Queue. You have to 'tune' the FIFO recevie loop on the RT even without the graph - its part of the FIFO RT coding in LabVIEWland. It something that you need to do, as the RT FIFO implementation is not interrupt driven on the RT. [I wish it was...NI are you reading this?...]

---

Hi Jack,

With regards to the RT FIFO and interrupt modes, you might get most of what you want by looking at the "blocking" mode, compared with "polling".

Maybe you already know this, but I think it's worth mentioning just in case - the default is polling, which uses 100% CPU whilst waiting for a timeout, whereas the blocking mode allows sleeping and behaves far more like a standard LabVIEW Queue.

Some description and similar issues can be found here:

Sharing Data Locally on an RT Target (Real-Time Module) (see about half way down - "Defining Read and Write Modes for Real-Time FIFOs")

RT FIFO results in 100% cpu load? (forum post) 

[MrJackHamilton]

The FIFO you are referring to are "RT FIFO' they are not FPGA-RT FIFO's which do not have the 'Blocking' property.

Reading the heading of the link provided is entitled "RT Locally FIFO's" Which are FIFO's that read and write only in RT memory space and not between FPGA and RT memory space.

I wish they did.

Regards

Jack

[mcduff]

If you are measuring acceleration, then I assume you are using a DSA card. These have their own internal clocks, thus you should get rid of the "Loop Time" in your VI as it is not needed. You set the sample rate, and the loop will run at that sample rate. (You set the sample rate earlier, so let it be.)

If you want to try to maximize throughput, resources, etc, you can do what I did below, that is pipeline the FIFO, although it is probably not necessary as accelerometers rarely sample above 50kSa/s. Note I had multiple modules that had different fixed point numbers so I converted to single point, if you have 1 or identical modules then this is not necessary and can be done on the RT side.

mcduff

PS Unfortunately from this browser I cannot insert a picture inline, I need to attach it. Sigh why does NI have their forums functionality change on a daily basis?