Simplified Queue functions

[Spectre_Dave]

The one problem with using the Queue functions is that they are all primitives. With that in mind MK and myself developed a Queue handler API that incorporates the primitive functions - as well as more advanced functions into a polymorphic VI.

We hope this improves your Queued State Machine experience.

[GovBob]

Could you mention what version of LabView this is written for?

[Spectre_Dave]

Sorry

This was written for LabVIEW 8.5  here is a LabVIEW 8.0 version.

It should be able to be saved for earilier versions also but I do not have LabVIEW 8.0.

[tst]

The contribution act itself is great, and you should probably also place it in places where people might actually look for it in the future (NI's code sharing section, the LAVA CR, etc.).

Personally, though, I'm allergic to VIs which only accept strings. My preference for something like this is to let all the wrappers have a typedef for the data and to have a piece of code which copies and renames all the VIs. Obviously, that it has its own disadvantages, but I like it. Alternatively, implementing this using LVOOP with dynamic dispatch or using more polymorphic versions for the common data types might help.

[altenbach]

Do I understand this right that it only works for strings?

Is there a reason that you are ignoring the errors is the real queue primitives?

(e.g. why does the error not go through the "enqueue element" inside "Queue Add Single Element.vi", see image)?

Message Edited by altenbach on 09-18-2008 11:29 AM

[Spectre_Dave]

We also used to use enums but to make a generic Queue handler we had to adapt to strings.  We chose not wire the errors into the primitives so that an error generated in elsewhere by the code will not impact the operation of the Queues.  

The main code error cluster is routed to the error cluster of the Queue handler so that we can trap on any error and redirect the queue to the error case. The error trapping is done be the Queued Error handler.vi which is placed to the left of the program cases.

In the Error case we look at the Queue element to tell if it is a programming error - misspelled string, missing case etc. or a genuine error from the program. We felt that there is a negligible chance for a Queue error since only the Queue handler vis interact with the actual Queue.

[Christian_L]

---

VADave wrote:

We also used to use enums but to make a generic Queue handler we had to adapt to strings.  We chose not wire the errors into the primitives so that an error generated in elsewhere by the code will not impact the operation of the Queues.  

The main code error cluster is routed to the error cluster of the Queue handler so that we can trap on any error and redirect the queue to the error case. The error trapping is done be the Queued Error handler.vi which is placed to the left of the program cases.

In the Error case we look at the Queue element to tell if it is a programming error - misspelled string, missing case etc. or a genuine error from the program. We felt that there is a negligible chance for a Queue error since only the Queue handler vis interact with the actual Queue.

---

Could you share an example of your main code to illustrate the use of your VIs and what you are describing here. I've been working on a very similar set of VIs to publish on DevZone as a reference design/design pattern for this purpose and at the ame time clean up/consolidate the myriad of different implementations currently posted on DevZone.

I agree with your use of strings for the queue element to make the tools more reusable and digestible by less experienced LV users, though using a unique TypeDef Enum and associated library to manage the queue for each application would be stronger SW design. In some cases I think it is appropriate to choose ease-of-use over robustness.

[Spectre_Dave]

I added the Queue handler code to the NI Developer Zone and I also placed a sample program there to show the use of the Queue handler.  The sample program is for illustration and may not be functional.

[Ben]

General not on queues:

One of the great features of polymorphic queues is that they can transfer the data using "in-place" techniques. So if you queue up data the data buffer holding that data is the same buffer from which it is read on the receiving end. This behaviour makes the polymorphic queues one of the most powerful data transfer mechanisms in LV apps.

By using a string version we are taking a step back to the pre-LV6 (?) days when all queues were only string based. At that time Action Engines could out perform queues due the fact the required flatten to and un-flatten from required buffer copies while the AE's could work "in-place".

If you can't tell, I am a big fan of polymorphic queues.

Ben

[Christian_L]

---

Ben wrote:

One of the great features of polymorphic queues is that they can transfer the data using "in-place" techniques. So if you queue up data the data buffer holding that data is the same buffer from which it is read on the receiving end. This behaviour makes the polymorphic queues one of the most powerful data transfer mechanisms in LV apps.

Ben

---

Excellent point. Now if we can find a way to make the Queue wrappers adapt to different TypeDef Enums to be able to easily reuse them in different applications and for different state machines in one application. A tool to copy and rename the wrapper, as tst' suggested, is what is needed. I also like the idea of a LV object for this purpose, but that won't work in LV RT which is one of my requirements.