LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading Zeros From an Empty DMA FIFO

Solved!
Go to solution

Hello,

I am having a problem using the DMA FIFOs to communicate between my real-time system and my FPGA. I'm using two DMA FIFO's, one to go to the FPGA from the RT system and then vice versa. I can successfully get data to and from each system; however, before, after, and sometimes inbetween my data, I will get a seemingly random assortment of zeros. In the lastest version of my code (which I have provided) I read the number of elements stored in the DMA FIFO and them read only that number to my RT system in an attempt to get only the data I want and not zeros, but that doesn't work either.

I am new to both real-time and FPGAs and so it definitely feels like I am missing something very basic. I have tried grappling with this issue by myself though and have had absolutely no success and would appreciate any and all help.

My hardware includes:
A Dell laptop (used as a UI host)
1082 Chassis
8133 Controller (running LabView RT OS)
7965R FPGA
5781 Adapter Module for FPGA (not currently in use)

LabView 2014 SP1

Download All
0 Kudos
Message 1 of 6
(4,012 Views)
Solution
Accepted by topic author RyanTheEngineer

On the RT Side, you should use a case structure so that you do not read from the FIFO if there is no data available.

 

I would also change that network stream to be inside of your While loop so that the UI can get each data point as it comes in (connect before the loop, close after the loop, and write as the data comes in inside of the loop).  This will save you memory (which is VERY important in an RT system) since you do not have to build up the array.

 

You are also only writing one element to the FPGA.  So any subsequence reads should give you an array of 0s, causing 0s to come back up.  You need to handle the Timed Out in the FPGA so that data only goes up to the RT when there is actual data to send.  Your FPGA code could be reduced to this:


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 6
(3,905 Views)

Since you mentioned you are new to LabVIEW FPGA, welcome!

 

Although LabVIEW tries to hide many of the subtleties of programming an FPGA, there are definitely nuances to each platform. I'd try to find some getting started training and work through that.

 

If you really want to dive right in, I would strongly suggest reading the documentation for each node you drop and at least at the beginning wire every terminal as needed to make sure you understand how things work. For instance, the Timed Out? terminals are pretty important. You'll be up and running in no time!

Message 3 of 6
(3,885 Views)

Crossrulz, thank you very much! After making the changes you suggested I no longer have zeros in my collected data. I really appreciate you taking the time to help!

Dragis, thanks for the warm welcome into the community! I have actually done quite a bit of reading on RT and FPGAs, but there is certainly a lot to it and I have had to dive into things pretty quick due to time constraints. I will definitely be taking your advice to more carefully examine every terminal when using new nodes.

 

Unfortunately, I have a new problem. After implementing these changes my "Close FPGA VI Reference" node now throws Error -63195. What is weird about this is that I have created quite a few practice VIs that all have used this node and this is the first time I have gotten this error. I've looked around online for a while and the only solution seems to be to uncheck "Automatically close VISA sessions" under options, but when I checked my VIs the option was never checked to begin with. Any ideas on what is going on and how I can fix this?

0 Kudos
Message 4 of 6
(3,858 Views)
Solution
Accepted by topic author RyanTheEngineer

That can happen if the green wire passed to the FPGA Close node has somehow been set to the default value. One way I've seen it happen is if it's wired through a for loop with 0 iterations, but there are some other ways it's possible, mostly with tunnels and loops / case structures.

 

If that's the case you should be able to track it down by probing the green wire throughout your code and seeing if there is a place where it goes from some non-zero value to zero. I suppose it'd be a problem too if the value changed to some other non-zero value, but in my experience I haven't seen that happen.

 

 

Message 5 of 6
(3,853 Views)

Speleato, thanks or your help! I actually just found the problem myself and it is exactly what you said it was. I didn't connect the reference wire in through one of my cases so it was using the default value which caused the error.

 

My VIs are now working exactly as I want them to! Thank you again for your help everybody!

0 Kudos
Message 6 of 6
(3,845 Views)