Real-Time Measurement and Control

Showing results for 
Search instead for 
Did you mean: 

1 MS/s with cRIO FPGA

Go to solution


Hi to all. I'm pretty new with using LabView and CompactRIO system and actually this is my first post in the Forum. I tried to find out how to solve my problem but I haven't figure it out.


I'm using NI 9223 analog input module to aquire data. I have to measure 10000000 samples in 10 seconds, so that means I need to take sample on each microsecond.


I can't figure it out what is the best way to transfer the aquired data from the FPGA to my windows pc. So far I was using the FIFO to transfer data, and what I was doing was writing the aquired data to the FIFO in the FPGA VI, and then read the data from the FIFO in the Windows VI. But the amount of data was much less than the capacity of the FIFO, what is in my case 131000 elements.


Can you give me hints what would be the best way to transfer the data without loosing any sample?


Thank you very much for your help.



Kind Regards,

Nikola Todorovski

0 Kudos
Message 1 of 12



What you have to use to transfer data between your FPGA and your Host at high speed are the DMAs FIFO. 

Here I send you a link where you can find all the information as well as the creation and configuration:


That's the missing piece in your application!





0 Kudos
Message 2 of 12

Another thing to keep in mind is the size of your FIFO:

If you acquire data with 1 MHz that means if you don't want to lose any data that you will need to transfer 1 million samples per second!

What do you mean by Windows PC? Is there a PC connected via Ethernet? Or are you talking about the controller on the cRIO?

A Windows host is hardly faster than 1 kHz ("deterministically" - sort of). Your FIFO therefore must be big enough to hold enough values for the PC to capture them all else the FPGA will overwrite the data.

LabVIEW 2012 32 bit

I am not an expert!
0 Kudos
Message 3 of 12

Thank you for the answers.


Yes, I want to transfer the data via Ethernet to my host PC and analayze the data there, and I know that the problem is with the size of the FIFO. The size of my FIFO is 131000 samples. So, does it mean that I have to read 100000 values from the FIFO every 100 ms?


I'm also not sure how can I be sure that I've aquired data on every 1 us? How can I check that I haven't lost any data?


Thanks a lot of the help.



Kind regards,


0 Kudos
Message 4 of 12
Accepted by topic author ntmkd



  First:  for 9223 sampling at 1Mhz:   The 9223 (and 9222) do not naturally sample at the 1us (and 2us respectively) using just the I/O nodes.  This is explained in detail here:    The basic idea is that the I/O node that is typically used to read an analog channel actual calls two operations.  First, it requests the data, THEN it transfers the data.  These operations when occurring in sequence take longer than 1us.  SO... in order to get the 1us, you must request that these two operations occur simultaneously.  This is done using what is called user controlled I/O sampling, which will independently request the data at the 1us rate allowing it to be ready immediately when the I/O node asks for it.  See that link for how to do this.


 Second.  FIFO's and acquiring very fast data at large amounts.  So, when you create the DMA FIFO, there are actually TWO buffers that are important. One is the FPGA buffer (fairly small) and one on the HOST PC (which can be very big).  The small one is the one you configure in the project window when you create the FIFO.   It will have an order of 2^n and will use room on the FPGA, I recommend making this as large as possible while still having room (FPGA gates) left for the rest of your VI.  The buffer on the HOST needs to be configured in from the "invoke method" on the FPGA blocks, where you would select the FIFO name and "configure".  I would set this very large as well, but if it is too large, it will crash labVIEW.  You may have to play with this to get it right.  Then you also want to tell that FIFO to "start" on the HOST vi (also with the invoke methode block) BEFORE you actually collect data on the FPGA VI.  Then once all data is collected, then read the FIFO using the FIFO.READ and you can save that data to the HD or plot it or whatever.

    So, here is what is going on.  Basically, locally, the FPGA buffer is like a small bucket.  It can be filled instantaneously on the FPGA when you write to it, BUT that info needs to go somewhere or the bucket will get full, and you will then loose data.  So, you need to empty (send) the stuff in the FPGA bucket (buffer) to the HOST computer and store it in the host computer's buffer which can be a bucket, OR a swimming pool.  You can set that size.  Now, the important thing about a DMA FIFO, is that it can actually empty the FPGA bucket to the HOST swimming pool very very quickly, as long as you initiate the transfer (which you can do even if the FPGA bucket is empty, this is what the "start" FIFO invoke method does). 

Two problems can occur.  1) FPGA bucket is full.  If you do not start that transfer before the bucket is being filled this can happen.  NOTE:  This transfer will also begin when you use the FIFO.READ on the HOST, but if you are already sampling at 1Mhz, it might be too late. Problem 2)  The swimming pool gets full!, yes this can happen, especially when you are transferring large amounts of data at 1us rates.  This is where configuring of the host buffer to a large enough number is important.   There is of course a limit, which I have not yet been able to completely understand what that limit is or what restricts it.  But I know that sometimes when I set it too high (like 100000000) it may “freeze” labVIEW and the data is lost.


So, if you set the HOST buffer large enough, and initiate the transfer from FPGA to HOST BEFORE you begin filling the FPGA buffer, you should be ok.  Then you will use the FIFO.READ to take the data from the HOST buffer (swimming pool) to save it to the hard drive or plot it or whatever.

Also, if you want to know about lost data, include a time stamp of the data by recording the time at each data acquisition on the FPGA and include it in the FIFO.  This will double the amount of data that you are putting in the buffers.

0 Kudos
Message 5 of 12

Thank you very much AlexNCSU. You've made me clear with a lot of things. I've already tried to acquire the data with a timestamp and it works good.


Also thanks to everyone that tried to help me.





0 Kudos
Message 6 of 12

Hey AlexNCSU,


Thanks for your response, I just wanted to clear up one thing. You wrote,


There is of course a limit, which I have not yet been able to completely understand what that limit is or what restricts it.  But I know that sometimes when I set it too high (like 100000000) it may “freeze” labVIEW and the data is lost.


The reason there is a limit is because the driver has to allocate a buffer big enough for that many elements. If you make the buffer too big you will simply run out of memory




0 Kudos
Message 7 of 12

Hello Speleato,

Yes, I see, thank you for your response.

I am still unclear though on exactly HOW labVIEW (or the dirver) is allocated memory from the PC.  In theory, I should be able to allocate larger buffer sizes on a PC with more RAM.  But I have had labVIEW "freeze" sometimes on PC’s with 16GB of RAM even with relatively small HOST buffer sizes, If I stop the frozen VI, decrease the size of the buffer, and rerun, everything works fine.  I also have had situations where I start labVIEW, make a VI with a certain buffer size and run tests without a problem, but then the next day I can start the same VI and have it "freeze'.   Usually restarting LV will fix the problem without having to adjust the buffer size.

0 Kudos
Message 8 of 12

Hi there guys.


It was a while since my last questions about data transfer from the FPGA to my Windows PC.


Now I figure it out that I have another problem that I don't know where it comes from. Almost always when I'm acquiring data, the second sample acquired is always 0. Anyone else with the same problem, or even better if there is some solution?


I am using cRIO-9012 and the analog input module NI9223.


Thank you very much for your assistance.



Kind Regards,


0 Kudos
Message 9 of 12



Since this thread is marked as answered and hasn't been posted on since December, I'd recommend starting a new thread with your new question. Please provide a little more detail as to the problem and the community should be happy to help!

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 10 of 12