LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using TWO DMA FIFO target to host

Solved!
Go to solution

Hi I am using a cRIO 9004 unit for DAQ purposes. I am trying to obtain signals from the analog(NI 9221) and CAN(NI 9853) modules and transfer them from the fpga VI to Realtime VI using DMA FIFO, i.e, Target to Host. I figured I need to use 2 DMA FIFO's , one each for analog and CAN signals. When I tried to implement them , I put the two FIFO in the same while loop. I'm not sure if thats the sole reason, but it would generate Underflow error 50400. When I removed one FIFO, and put only one FIFO, it worked fine. So, I figured they need to run independant while loops, and implemented two while loops that would execute parallely. And it worked. I'm not sure If this is how it is supposed to work? Is it so that DMA FIFO needs to be executed in individual parallel loops? Are they written in such a manner that the FIFO function cannot be called for more than one instance in the same loop? It sounds strange. 

 

Also I need to mention that, I reconnected the wires on the analog, digital and CAN modules before putting them in seperate loops. And I know for a fact that the CAN FIFO would show underflow error if the input wires on the CAN port are not connected. Also I am NOT using Scan Engine mode(i think its not available in 9004) 

0 Kudos
Message 1 of 3
(2,687 Views)
Solution
Accepted by topic author rkkallur

You're right about the 9004 and Scan Engine support - or lack thereof, I should say...  Concerning the underflow error, this behavior is expected when you have two DMA FIFO writes in in the same loop.  What's happeing is both FIFOs are not writing in true parallel.  Thus, when you write to FIFO1, FIFO2 is waiting for FIFO1 to complete. Then, when you write to FIFO2, FIFO 1 has to wait on FIFO2 and the while loop to re-iterate before it can write more data.  So, on your real-time VI, if you try to access one of these FIFOs that has no data in it because it's waiting to write the next block of data, then an underflow error will occur. 

 

When you separate the two FIFOs, both can run independently of each other and write at a much faster rate.  This way, your FIFO reads on the realtime VI will not get caught in an underflow state where one FIFO is waiting to queue up data. 

 

Hope this helps!

0 Kudos
Message 2 of 3
(2,657 Views)

thanks Rory! thats what I thought. Needed a confirmation, so as to make a notefor future application development.

 

rajesh

0 Kudos
Message 3 of 3
(2,623 Views)