cRIO DMA FIFOs and their Timeouts

[jsedillo]

First discussion tee-hee.

Working on a cRIO project with an RT program that uses a RT loop (25ms loop time) and a parallel "main" while loop (100ms loop time). The RT loop is dedicated to DMA FIFO to RT FIFO data transfers for the "main" loops use. Seems like DMA FIFO reads with timeout values cause the cRIO to dedicate a substantial amount of CPU to polling that FIFO until either the data arrives or the prescribed timeout occurs. Since I have parallel loops that read from FIFOs (main loop reads from RT FIFO APIs, RT loop reads from DMA FIFO APIs and transfers to RT FIFO), it seems like this dependency with timeouts causes a CPU leak, with the effects worsening with larger timeouts. Although the code works, am I correct in believing that the DMA FIFO and RT FIFO calls with timeouts block parallel code from executing, thus leading to a potential CPU utlization and FIFO train-wreck in my code?

Any insight into what LabVIEW does here will satisfy my question.

Thanks.

[pylb]

you should have a look at this thread:

http://forums.ni.com/t5/LabVIEW/RT-FIFO-results-in-100-cpu-load/td-p/2808832

It looks like you have option when you create the FIFO.

[jsedillo]

Seems straightforward enough there. How about the DMA FIFO read, any idea on whether or not it blocks until timeout?

[DA.NI.LO]

I'm includig the response from our Application Engineer Noah D. below:

=========================================================

The short answer is that yes it does block. The longer answer is that the DMA FIFO will block until either there are at least the number of elements specific to read in the buffer or the timeout occurs.

Here is a Knowledge Base article that may provide some more insight: http://digital.ni.com/public.nsf/allkb/583DDFF1829F51C1862575AA007AC792

[jsedillo]

Thanks for that. One more thing...

If I apply what I've learned here to my project, I should ideally set the timeouts in my code to zero. However, issue 132979 mentioned here: http://www.ni.com/white-paper/13338/en/ has me concerned about doing so. Although this issue applies to NI-RIO 4, I'm uncertain as to whether or not this issue has been resolved in NI-RIO 12/13.

Thanks to all of you who responded.