If the RT FIFO read is set up to have a -1 timeout (ie. a -1 to the timeout in ms input to wait indefinitely.). This behavior somewhat works. It does wait indefinitely but it waits indefinitely regardless of if another element is written to the FIFO. Therefore the program hangs and you can't read anything further.
If you set the r/w modes input to be (blocking, polling) then the program no longer locks up the both sides of the FIFO and the program runs as desired.
Can you post a simple test VI that shows this behavior? It seems likely that the Reader loop is thread-starving the writer loop since both were initially set to polling.
Richard
Field Sales Engineer, New Jersey National Instruments
I think you are correct in your logic. I've attached my quickly developed test vi.
Further Notes: If the timeout on the read loop is put to another number other than -1 say 10000, then the program is straved for that amount of time if when it enters the read no item is avaliable.
In order to view this behavior you will have to set the r/w mode to (polling, polling).
I hope you're doing well. I actually ran into this behavior yesterday as well, and came to the same conclusion that Richard suggested: the RT FIFO Read is polling so fast that it is starving the RT FIFO Write from enqueing the next element. We were able to solve it by simply changing the Read mode to blocking. In conjunction with an infinite timeout, the read operation will sleep if there are no elements in the FIFO and then wake up when an element is finally queued up. Let us know if this helps!
Thaison V Applications Engineer National Instruments
