What is appropriate: RTFIFO or QUEUE?

[Kjell-E]

Hi!

I guess the answer will be pretty obvious, but I thought to save myself some headaches by asking first.

I've used RTFIFO's a little bit on a previous project, so they sprang to mind quickly for this app, but when reading here on the forum, Queue keeps getting mentions. So far I have not seen or heard anything that singles out one over the other, so I'll ask here to see if there is any merit to one over the other.

I use LV 7.1 with the ETS RT and FPGA modules.

The application target will be a standard WinXP computer (no "true" RT environment in other words), but as far as I have been able to determin, I can still use RTFIFO on a windows target app... right?

The application goal/function (for the part concerning the buffer):
[estimate that a 1 to 2 second buffer will be plenty.. so, some 9600 to 19200 elements of "unsigned int8"'s..)
* Read serial port at 9600baud
--> log all data in "raw" bin file
--> search for header
-->extract (from header) packet length
-->read entiere packet and compare CRC16 to validate comm. packet
-->log data in a "high-level" way, using channel information etc.
-->present data as curves and indicators for user

What would be the recommended way to go here? RTFIFO's or Queue?

The way I'm thinking of doing it, is to read "chunks" from the serial port (using VISA Read), and branch the read string, one to the input buffer and one directly to a raw data file. Then in a sepparate loop, I'll poll the queue (to make sure I got enough elements) and search for "start of header sequence" etc.

The one thing I'm worried about, and which makes me lean towards the RTFIFO is how Queue handles "simultanious" writes and reads? Maybe I'm mixing in to many things from RT targets here, but it seems dangerous to "read" from a variable (the queue) in one loop, while another loop is potentially adding data. In the case of the RTFIFO, this is not a problem since it has built in "protection" to handle this, but with queue....?

I hope someone knows a bit more here and can recommend one or the other.. preferably with some "why's" to back up their recommandation.

(Maybe RTFIFO is more optimized and runs with a smaller overhead?)

[Kjell-E]

Hummmm..

As far as I can tell, now that I have looked into it some more on my own, the queue has some advantages since you can actually "ask" to see how many samples are currently in the queue, and from other peoples use of the queue, it looks like it is safe to use in a paralell environment (I guess that was obvious), and that I do not need to worry about reading/writing at the same time.

Still, if anyone can give me a good reason or two for one against the other, I'm listening!

Have a nice weekend!

[DimensionFinder]

Hi Kjell:

I found a pretty good link on RT FIFOs below:
http://zone.ni.com/devzone/conceptd.nsf/webmain/3a9b9598f6c4d06186256ab8004f6340

Basically, I would recommend using RT FIFOs. RT FIFO is an implementation of a queue that is designed for RT applications. From what I gather, RT FIFOs are queues of fixed sizes. Since there will be no dynamic memory allocation, there will be less memory jitter. This is the main advantage. Also, with RT FIFOs you will be able to use RT tools such as the RT Communication Wizard.

These are the 2 big advantages that I can think of.

Best,
Jaideep

[tst]

If I remember correctly, it was said somewhere that the shared variable in LV 8 can be used instead of the RTFIFO, because it has a buffer. If this is so, and it will become obselete, the queues are probably the better path. Incidentally, I'm sure the RTFIFO can not handle simultaneous reads and writes. What both the queue and the FIFO should be doing is queueing - if two requests are made at the same time, one will have to wait until the other finishes with the queue. The time it needs to wait should be minimal, but it can not happen at exactly the same time.