Wish list for Queues

[a.winslow]

A few functionalities I would like to see added to Queue functions:

1. The ability to queue up an array of elements all at once (rather than having to use a For Loop with the Enqueue Element function inside).

2. Given: A Queue with a set maximum number of elements.  I would like a boolean flag on the Enqueue Element function to allow addition of elements to a full queue (thus pushing out the oldest element(s)).

Granted, I can reproduce the above effects thru coding, but it would be nice if they could be handled by the existing Queue functions.

[tst]

Lucky for you, the guy who wrote the queue primitives is listening. Go over to the LAVA forums and search for "Lossy queues" to see a recent discussion just about this.

Unlucky for you, the way NI works, that does not gurantee that this will be implemented, as it might not be considered a priority.

[Jarrod_S.]

The LabVIEW 8.2 Real-Time Module does have a set of new RT FIFO primitives. They unfortunately don't handle your first wish, but they do implement your second of being able to overwrite the oldest value on a timeout. They lack a lot of the functionality of the regular queues, like previewing elements or storing custom datatypes, but you could use them in a non-RT environment for scalar or array numeric data and waveforms.

Just a thought!

[tbob]

Recognizing the need for advanced queue functions, we wrote our own and put them in a library in user.lib.  Just as convenient as NI versions.  The most used function is the Queue Multiline String function, which queues up a string of several entries separated by a newline character.  Very simple to write, and comes in very handy.  We have one that queues an array of strings, and the user has a choice to insert into queue at either end.

[a.winslow]

tbob-

Yeah, I've done something similar for myself. The main problem with it though is polymorphism. I often have Queues based on typedef enums or clusters which vary from project to project. I rarely use something as simple as a string-based Queue. It would be great for NI to put something together to handle this for us.

<crossing my fingers>

[tst]

For getting around this, what you can do is build your routines once and then use some hierarchy renaming tool so that you can have unique names for all the VIs. Personally, I occasionally do this with a modified version of a duplicating tool I downloaded from MGI - I simply take the base files I want to duplicate, make a copy of the hierarchy and tell the tool to change\add the prefix or suffix I want.

If you still want to keep the functionality in some base files you can modify, you can write the core using variants (place in the user.lib folder inside a folder beginning with an underscore and it won't appear in the palettes) and then only use the wrappers per project. Of course, you'll suffer some performance penalty with this method.

[tbob]

Now I'm starting to agree with a.winslow.  NI should incorporate this wish list in its list of queue functions.  Having a polymorphic vi that can handle strings or enums would be highly desirable.

a.winslow:  since it is your idea, please submit it on the NI wish list website.

[a.winslow]

I posted this to the Product Suggestion Center.

🙂