RT FIFO Reads not updating consistently

[TurboPhil]

I am using an RT FIFO to pass array data asynchronously to a timed loop that will 1) read the data off the FIFO, 2) act on the data, possibly modifying it, and then 3) writing the updated data back to that FIFO. The asynchronous write (i.e. the write command outside the timed loop) is done with a dedicated subvi that maintains the FIFO refnum in a shift register; individual array elements are written in this subvi using the same process: 1) read current array from FIFO, 2) replace desired array entry, 3) write the value back to the FIFO.

The problem is, when I run the (RT) application from the host computer in development mode, the data on the FIFO in the subvi does not always match the data being pulled off the same FIFO in the timed loop. Sometimes the updated values are read properly in the timed loop, sometimes not. I probe the array being written to the FIFO in the subvi, as well as the array being read from the FIFO in the timed loop--one updates, the other doesn't.

Is this a problem running it in development mode? I have not yet tested it as an executable--there are still some other bugs I need to work out before I can do so.

I have also considered the possibility that there was a race condition between the FIFO write in the subvi and the FIFO write in the timed loop, so I tried placing semaphores around both calls to prevent immediate overwrites. I also paced a comparison betwen the FIFO read and write functions in the timed loop (before and after the modifications may or may not be made on the data) to determine if those modifications were being made, and the updates were happening too fast to see on the probes, but that, too, was unfruitful.

Thus, I am inclined to believe that the problem is either with running it in development mode, or somehow my version of LabVIEW forgot how to use FIFOs.

Any ideas or suggestions would be greatly appreciated.

[Jarrod_S.]

The first thing that seems really odd to me is that you are reading and writing to the same FIFO from two places. You almost always want one reader and one writer per FIFO, or perhaps multiple writers but still one reader.

The situation you're describing sounds like a race condition. How can you control that the background process doesn't read back the data it writes to the FIFO before the Timed Loop has a chance to read it? I don't think there's any good way of controlling that. Since it's a race condition, it well describes what you're seeing. Sometimes it works, sometimes not.

I would strongly suggest trying this out:

Have the background VI write to one FIFO that the Timed Loop reads. Then have the Timed Loop operate on that data and send back an update on a different FIFO that the background loop reads. One reader per FIFO. Much safer. Hope this helps!

If this doesn't sound like it fits your situation, I'd recommend posting a much simplified version of your code that reproduces the problem.

[TurboPhil]

Thanks for the input, Jarrod. Yes, I was thinking about splitting up the single FIFO into two separate FIFOs, and I just might do that later. For now, to get the system up and running, I just replaced the FIFO with a single process shared variable (configured as an RT FIFO, no less!), and the problem went away.

You're also right that it sounds like a race condition, but I swear I tried everything I could to eliminate that possibility--and now that the same procedure works fine with a single shared variable, I don't see how it could be a race condition.