Requesting suggestion for possible software architecture design with PC- RT-& FPGA

[XM43]

Hi, I have run into a situation where I am supposed to make changes in existing architecture of a Labview application.

Given the case that I am new to this and do not have any help except you guys, I was hoping if someone could direct/ suggestion in the right direction for the following case:

Hardware: RT myRIO, FPGA and PC

Software's purpose: Send and acquire high frequency analog/digital signals using FPGA. Assess acquired signals in real-time and display results on screen (front panel- PC).   

Problem statement: Data updated on the main screen has lag to it and the lag increases when the data size/signal frequency is increased.

Existing architecture: Is divided in 3 parts (Previously there was no concern about updating data on main screen at a faster rate, thus the existing architecture)

1) Bit files that get deployed on FPGA to send and acquire signals

2) Data is collected on RT target (DMA FIFOs)

3) Data is sent from RT target to a PC, analyzed and results are shown on computer screen

Currently notifiers (problem?) are used to send data from RT to PC via TCP/IP. RT target collects data coming from FPGA using DMA FIFO and then this data is sent to a PC. PC has VIs that converts raw data into useful values. Works great only if signals/data changes at say about every 100ms. But fails to respond when say data updates every 5ms

Possible solution (that I could think of ): Use only two components

1) Continue using FPGA to send and acquire signals

2) Eliminate data collection on RT target

3) Collect data directly on a PC (DMA FIFOs), analyze and display (Tested the proposed solution, shows no observable lag so far. Not aware of caveats)

It almost seems like that current case of data transfer from FPGA-RT-PC can be simplified to FPGA-PC. I cannot think of caveats at the moment.

More question and information:

1) Due the nature of the application, PCs will be different based on end user(Slower PC may affect data transfer rate?)

2) RT target will always be connected with the PC, RT is not expected to run headless

3) Should queues be used on RT side in existing software to have loss less communication

4) What would be a better way to communicate data in this case?

I tired to provide as much information as I thought is required for this situation. Sadly it is not possible for me to upload my project here, but I would be happy to provide more information and discuss it here.

Any help/suggestion is much appreciated.

Thanking you for taking some time to read this.

[Bob_Schor · Accepted solution]

Look into using Network Streams to send data from the RT Target to the Host.  We ran some behavioral experiments involving sampling 24 analog channels at 1 kHz for minutes at a time -- as the data were acquired on the PXI (this is older, pre-FPGA technology, with the Target running on dual-core Intel chip, don't remember which one, and PharLap), they were transferred via Network Streams to the PC where they were streamed to disk.  We added a "clock" channel to ensure that we didn't lose any data along the way.

I'm sure similar code could do the same on the myRIO.

Bob Schor

[XM43]

---

@Bob_Schor wrote:

Look into using Network Streams to send data from the RT Target to the Host.  We ran some behavioral experiments involving sampling 24 analog channels at 1 kHz for minutes at a time -- as the data were acquired on the PXI (this is older, pre-FPGA technology, with the Target running on dual-core Intel chip, don't remember which one, and PharLap), they were transferred via Network Streams to the PC where they were streamed to disk.  We added a "clock" channel to ensure that we didn't lose any data along the way.

I'm sure similar code could do the same on the myRIO.

Bob Schor

---

Thank you so much for your response, I would for sure look into it.

Also, I'm curious if I should use RT at all by that I mean:

1) Sending data directly to PC from FPGA using DMA FIFOs

2) Or as we currently have it here, that is, FPGA - myRIO - PC

[Bob_Schor]

I may be wrong, but I don't think that there is a direct route from an FPGA Chip on an RT-Target and the PC Host connected to the same RT-Target.  I think the order is Tinkers to Evers to Chance.

Bob Schor

[XM43]

---

@Bob_Schor wrote:

I may be wrong, but I don't think that there is a direct route from an FPGA Chip on an RT-Target and the PC Host connected to the same RT-Target.  I think the order is Tinkers to Evers to Chance.

Bob Schor

---

May be I should first develop a better understanding about routing. But I have for sure observed a major difference in reading values:

1) By running FPGA VI from PC being host by using invoke method (Faster data transfer, no lag) (Streaming high speed Data using DMA FIFOS) https://www.youtube.com/watch?v=SzeTRC-w7aA&t=5s

Please review the attached youtube link if possible. It demonstrate what I am talking about.

VS

2) By running FPGA VI from RT being host and then send data to PC using either network stream or any other method. 

Thank you for responding back and I learned something new "Tinkers to Evers to Chance."

[Bob_Schor]

... and thank you for making me watch (again) the discussion by Ed Doering, which clearly discusses a direct FIFO transfer from FPGA to the PC, bypassing the Second Baseman.  It still seems a little "magical" to me to do everything in one step, as I think of FPGA sub-systems existing on RT Targets, and RT Targets connected to PCs via TCP/IP (as is the Project shown in the link), and would think that each transfer would need to be handled separately.

     But I'm fairly new to the intricacies of FPGA (my previous LabVIEW Real-Time programming was with a PXI, non-FPGA, Target), so thanks for pointing this out to me.  I'd be very interested in what you find comparing Tinkers to Evers to Chance versus Tinkers to Chance, directly.

Bob Schor

[XM43]

---

@Bob_Schor wrote:

... and thank you for making me watch (again) the discussion by Ed Doering, which clearly discusses a direct FIFO transfer from FPGA to the PC, bypassing the Second Baseman.  It still seems a little "magical" to me to do everything in one step, as I think of FPGA sub-systems existing on RT Targets, and RT Targets connected to PCs via TCP/IP (as is the Project shown in the link), and would think that each transfer would need to be handled separately.

     But I'm fairly new to the intricacies of FPGA (my previous LabVIEW Real-Time programming was with a PXI, non-FPGA, Target), so thanks for pointing this out to me.  I'd be very interested in what you find comparing Tinkers to Evers to Chance versus Tinkers to Chance, directly.

Bob Schor

---

So, I found reasons as to why I was getting slower updates on values with the existing architecture:

1) Most basic, event structure had a 100ms timeout wait time, so there was no way using any communication method I would get the most recent values on front panel in real time

2) Data acquisition loop was not running continuously ( it was like: Collect- check data - collect) (Now it is collect & in parallel check, instead of doing it in a sequence ) Which caused a slight delay as well.

3) Network Streams works the best for FPGA- RT- PC, other methods to transfer data were not as responsive in my observation

4) RT has limited processing power so was running out of both memory and processor at times thus, VI had to be optimized