LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 50400 occurred on FlexRIO example "FFT Co-processor"

Solved!
Go to solution

As the title states, I tried to run "FFT Co-processor" example found in LabVIEW 2013 FlexRIO examples with PXI-7954R FPGA but kept getting "ERROR -50400 occurred at Invoke Method: FIFO.Write in FFT Co-processor (Host).vi. Possible reason(s): The transfer did not complete within the timeout period or within the specific number of retries.".

 

I am using LabVIEW 2013 SP1 with Xilinx 14.4 Compiler. I didn't modify the code except copied the FPGA vi to the newly added PXI-7954R target and recompiled it; and change the FPGA VI Reference in the host vi accordingly.

 

I tested the code in simulation mode (i.e., execute FPGA VI on Development Computer with Simulated I/O) and it worked fine. However when running on FPGA Target it doesn't work. I monitored the "Empty Elements Remaining" on "Host-to-FPGA.Write" in the host vi and the value was 5. And "Elements Remaining" in "FPGA-to-Host.Read" in the host vi was 0.

 

Does it have something to do with the FIFO buffer size? Any suggestions/comments are greatly appreciated.

 

Thanks,

Bing

0 Kudos
Message 1 of 9
(3,748 Views)

Update: The same code runs fine on PCIe-7842R. I am really confused as 7842R and 7954R both use Virtex-5 FPGA chip and their performance should be similar. Only difference I can think of is 7954R sits inside PXIe-1073 chassis which has up to 250MB/s bandwidth while 7842R is directly inserted to the PCIe slot inside the host PC. 

0 Kudos
Message 2 of 9
(3,731 Views)

If you post your code i can help you rule out any obvious msitakes

0 Kudos
Message 3 of 9
(3,724 Views)

Hi David-A,

 

Thanks for offering help. The code is attached. It was directly copied from \LabVIEW 2013\examples\FlexRIO\FPGA Fundamentals\Co-processor\FFT. I only added two indicators to monitor Element Remaining and Empty Element Remaining. Also I mentioned above, the same code works on PCIe-7842R.

 

Thanks,

Bing

0 Kudos
Message 4 of 9
(3,718 Views)

Hi David-A,

 

I just tested the code on LabVIEW 2014 SP1 with Xilinx 14.7 complier. Same as LV2013, the same code runs fine on PCIe-7842R but still NOT working on PXI-7954R. I might be wrong but it seems the code is not compatible with PXI-7954R somehow, regardless of LabVIEW version or complier version.

 

I also tried the CLIP Adder and Floating Point Multiply found in NI examples and they all work fine with 7954R. So I have no idea why the FIFO example doesn't work.

0 Kudos
Message 5 of 9
(3,697 Views)
Solution
Accepted by topic author iron_curtain

Theres a race condition in the host code. If you try to read before you write then the FIFO times out. If you make sure that you write before you read then the timeout never occurs.

 

Attached is a version of the host code that writes then reads using a state machine. 

0 Kudos
Message 6 of 9
(3,671 Views)

Hi David-A,

 

Your code works on 7954R! Thank you so much for your help.

 

One more question: why does the race condition only occur on 7954R? I tried the orignal code dozens of times on 7842R and it always works.

 

Thanks,

Bing

0 Kudos
Message 7 of 9
(3,663 Views)

The timeout occured on all flexrio devices i tested it on, not just the 7954. What I'm not sure about is why this previously working example consistently doesn't work now. This race condition was always there, but apparently the stars had aligned and all previous testing and even now on the R series device you tested it with the write loop executes before the read loop and the race condition never mannifests. Using a state machine instead of two seperate while loops completely eliminates the race condition.

0 Kudos
Message 8 of 9
(3,657 Views)

@David-A wrote:

The timeout occured on all flexrio devices i tested it on, not just the 7954. What I'm not sure about is why this previously working example consistently doesn't work now. This race condition was always there, but apparently the stars had aligned and all previous testing and even now on the R series device you tested it with the write loop executes before the read loop and the race condition never mannifests. Using a state machine instead of two seperate while loops completely eliminates the race condition.


That's good to know, as I was worried that something was wrong with our FlexRIO FPGA card or the chassis Smiley Wink

Thanks again for your help!

 

0 Kudos
Message 9 of 9
(3,650 Views)