Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Data transfer speed from FPGA to RT

I'm trying to transfer approx. 2000 samples of U32 data from FPGA to RT, at high speed, but I can't transfer data faster than 8kB/s(roughly). I'e tried two handshaking methods between RT and FPGA:

- Syncronous Display
- Boolean flags

If I remember it correctly, I think that the "Syncronous Display"- method were a little bit slower. If the problem isnt' in the handshaking, were could it be? Other parallell RT tasks?
What transfer rates can you expect from the FPGA code, if this is the only thing that code does?

Regards
//Ulf

ps. All data is stored in a FIFO-buffer when transfer occurs ds.
0 Kudos
Message 1 of 5
(7,494 Views)
A good first technique to employ is to separate your acquisition loop from your "synchronous display" or boolean flag loop. This allows the DAQ portion of your FPGA code to run free. This separation is done by setting up a FIFO buffer with block mode memory. The FPGA DAQ loop writes points to the FIFO buffer. The "transfer to RT" loop then reads data from the FIFO buffer and places it on the panel for the RT host to gather. I use synchronous displays in my demonstration examples. It has been my experience that I can get about 4kHz data for the 4 channels I am interested in. The NI cRIO team might have some additional benchmarks to share.

Preston Johnson
Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 2 of 5
(7,490 Views)


@preston johnson wrote:
A good first technique to employ is to separate your acquisition loop from your "synchronous display" or boolean flag loop. This allows the DAQ portion of your FPGA code to run free. This separation is done by setting up a FIFO buffer with block mode memory. The FPGA DAQ loop writes points to the FIFO buffer. The "transfer to RT" loop then reads data from the FIFO buffer and places it on the panel for the RT host to gather. I use synchronous displays in my demonstration examples. It has been my experience that I can get about 4kHz data for the 4 channels I am interested in. The NI cRIO team might have some additional benchmarks to share.

Preston Johnson




Mr Johnson,
Thanks for your reply. I've done the implementation almost the same way as you describe in your text. An image of FPGA-code is attached in this reply. 4kHz is not very fast, RS232 can transfer data at higher speed(I should perhaps add RS232-interface in FPGA-code and transfer data to RT over RS232 😉 ).

The reason I don't want to use synchronous display is that it's not sure that this feature works in future version of LV FPGA.
Looking forward to hear somethinng from the NI cRIO team...

Regards Ulf Nilsson, Endevo
0 Kudos
Message 3 of 5
(7,485 Views)
Ulf,

Which physical FPGA platform are your using? R series plug-in card or CompactRIO? For the R series, what is your host processor (PXI or desktop/PCI) and processor speed? Typical maximum tranfer rates depend on platform and host processor, as well as other operations performed in your host VI.

In any case you should be able to achieve a data transfer rate significantly higher than 8 kB/s to your host. The FPGA diagram you shared looks good, so can you also share the corresponding host VI?
authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 4 of 5
(7,476 Views)
Hi Christian
Thanks for your reply!
I'm using the following hardware:
• Chassis cRIO-9102
• Controller cRIO-9004
• I/O-modules
o 1 unit digital input module NI-cRIO 9425
o 4 units digital output modules NI-cRIO 9472
o 1 unit analog output module NI-cRIO 9263
o 1 unit analog input module NI-cRIO 9201
o 1 unit differential input module NI-cRIO 9411

I've attached the host RT code in this reply. First the program looks on how many elements that has been read. All data is read when "Number Of Elements" becomes "0" (except for the first loop iteration). If number of elements is the same as last iteration, no new data has been "published" and the program will wait for 5ms. If new data has been "published" the program reads the data and sets the boolean "PPS1 Read Buffer" to True. The read data is then splitted into two I16 and converted to correct metrics. One of the I16 gets filtred with "running average" algorithm.

I guess that the speed problem could be either:
- all the stuff I'm doing with the read element (metric conversion and filter)
or
- elements doesn't get published fast enough in the FPGA-code(so the program have to wait 5ms)

Regards Ulf Nilsson, Endevo
0 Kudos
Message 5 of 5
(7,471 Views)