Can I use FIFO to transfer data between FPGA and host at a speed of 300 Micro second

[kprabaka]

I am using an SBRIO 9642 for my application. I am measuring the voltage at a rate of 66.675 Micro seconds in the FPGA side. I am transfering this data back to Real time using FIFO. RIght now, It is updated at a speed of 4 ms.

I have attached a minimal working example with this.

Any help would be appreciated.

Regards,

Kumaraguru Prabakar

[BMac]

Transferring data at that rate (3.3 kHz) should be no problem. You might want to check out this new GPIC reference design example code. (Requires LabVIEW 2013 SP1.)

Here are some performance benchmarks with different networking connections (remote wireless with VPN, local wireless, and local copper Ethernet). In this case the application is transferring 15 channels of double precision (8 byte) data:

The application is written so that even if the network doesn't have the bandwidth to transmit all the data, the DMA FIFO in the LabVIEW Real-Time application will not overflow. However, there will be a "Transmit Backlog" meaning that not all of the waveforms have been transferred to the desktop computer. By default, the transmit FIFO can store 20 waveforms. As long as the transmit FIFO doesn't overflow, the data transfer using LabVIEW network streams technology is lossless.

However, at a certain rate the CPU usage on the real-time VxWorks PowerPC processor is too high, and the DMA FIFO will overflow. In general, it's a good idea to keep CPU usage under 80% on any real-time operating system (LabVIEW Real-Time) application. A real-time operating systems is intentionally designed to be unforgiving because it prioritizes the execution of high priority control loops above networking, datalogging and other lower priority tasks.

Here are some screenshots of the desktop user interface application running. Based on the performance benchmarks, we decided to make the default sampling rate 10 kHz (100 microseconds).

On the Status tab you can see the CPU usage of the sbRIO GPIC real-time operating system.

Click the Log Data button to turn on automatic datalogging to TDMS format. The log file automatically appears when you Disconnect or STOP. You can see the startup behavior of the 3-phase AC induction motor below.

The FPGA application keeps a RAM buffer of the internal register and I/O values which is retrieved by the real-time processor in the event of a fault. The data is captured before and after the fault event. The I/O data can be captured at rates up to 120 kHz (the maximum sampling rate of the GPIC analog inputs), and internal FPGA register values can be captured up to 6 MHz. In the example below, a 3-phase induction motor was running as a variable speed drive using voltage-over-frequency control. However, a sharp change in the speed setpoint (which could be filtered to avoid such a fault), caused the current in phase V to exceed a 10 Amp trip limit. The FPGA protection logic detected the over limit condition 25 nanoseconds later and disabled the pulse width modulation.

Note that if the sampling rate of the analog input loop (in this case 8.625 microseconds) is faster than the fault capture rate (in this case, 100 microseconds), you might not always see the captured waveform cross the trip limit threshold. But it's obviously an advantage that the FPGA control application is sampling at a fast rate and can trip off immediately in the event of over voltage, under voltage, over current, under current, over temperature or other faults (such as IGBT desaturation as indicated by the SKiiP3 or SmartPower Stack digital lines).

As you can see below, a variety of metadata is saved in the log files, which remain on the flash drive of the sbRIO GPIC until the desktop user interface application (automatically) retrieves them via FTP.