Generic Queue?

[dkfire]

---

@Jared7 wrote:
...

Since this VI is pretty small I may go with the copy & paste approach. Since I'm somewhat new to LabView I wanted to ensure I'm not missing something obvious before doing this. I'm more familiar with C# where this problem could be solved with a single parent class containing the "obtain a queue, fill the queue, pass the queue into a SubVI, destroy the queue" logic, and several child subclasses that call different subVIs and handle the different data types.

 ...

---

So why not do that in LabVIEW ?

LabVIEW has classes and OOP.

[Jared7]

I thought of that, but I'm having trouble enough learning how to do basic operations in LabView. But you`re probably right I should look into this. Thanks!

[Mark_Yedinak]

OOP in LabVIEW is very similar to other languages. The biggest difference is that LVOOP (LabVIEW OOP) is by value and not by reference. So, if you fork a wire and modify the private data on both wires the other wire will not see the modified data. Forking the wire of an object is effectively cloning the object. There are methods to make an object act more like a by reference object but I will refrain from discussing that. By vlaue and by reference objects is a long running debate in the LabVIEW community.

Polymorphic VIs should have different connector panes. The correct VI is selected based on what is wired to it. Think of the Add primative. It automatically selects the correct addition operation depending on whether you wire a U8, U18, I32 or whatever type of number. the only constraint is that all of the VIs in a polymorphic VI need to have the same connector pattern.

[DFGray]

I believe you can do what you wish to do using the command pattern and inlineable subVIs.

1. Create an empty class.  It has no data and no methods.  It will be the parent for all the data you pass in your queues.  You can easily expand it in the future to include data and methods if you find you have a common set.
2. Create a reentrant subVI which allows inlining.  In this subVI, place your enqueue code.  The queue type will be your empty class.
3. Create a similar dequeue subVI.
4. Create code to acquire and dispose the queues properly.
5. Create a subclass of the empty class for each data type.  The data is the data type and methods are simple read/writes of the data.  You can include more complex things, as well.

You should now have a relatively generic set of code for passing data around.  Any time you need a new type of data, create a new subclass of the empty class.

This is once over very lightly.  If you need more info, let us know.

[JÞB]

---

@DFGray wrote:

I believe you can do what you wish to do using the command pattern and inlineable subVIs.

....

This is once over very lightly.  If you need more info, let us know.

---

Actually,  that would make a very nice Community Nugget

[Jared7]

Hey all,

Attached is a picture of the VI I modified to use LVOOP. The SubVis Get Array Size, CreateQueue, Enqueue Element, and Execute SubVI are all overriden by child classes using queues with different clusters. 

So I could do what I needed using LVOOP - thank you all! The problem with doing it this way is both parent and child classes have several VIs (1 VI per method), but at least I got my end goal of not copying and pasting the operation: "obtain a queue, fill the queue, pass the queue into a SubVI, destroy the queue". As you can see, LVOOP.jpg looks similar to my initial attachment TestVI.jpg. LVOOP.jpg is just more generic.

[Jared7]

I found an old post that would address my problem the best: http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/259/page/1#comments. Unfortunately the most recent post states they're a long way off in getting this feature implemented.

Coming from a primarily C# background I find this lacking feature a really turn-off to LabView. I've worked with LabView just a short while (less than 1 month) but have seen A LOT of copy and pasted code because this feature is lacking. Since I`m writing LabView unit tests I need to copy and paste many unit tests to test copy and pasted code. More code == more problems. It doesn`t feel right.

I hope this feature is still in the NI feature horizon. Sooner the better.

[Yamaeda]

Nice to hear you got it working. I also see alot of copy+paste code, usually it's the effect of people not knowing all the abilities of LV, more or less creating Rube Goldberg Code (check Breakpoint section of forums).

2 comments, the Get array size should result in an Integer, not Double, and the sequence is unnecessary. 🙂

Still i wonder if this is a path to success:
(Hmm, couldn't insert, attach it instead)

/Y

[Jared7]

Thanks for the feedback and solution, Yamaeda. I don't see how I can pass queues containing different clusters into the different VIs though. Is this possible? Thanks!

[Yamaeda]

I'm back at your original thought "testing vi's". With my suggestion you'll have the queue input in the Call by ref-vi assuming it's connected. I also assume (as i think you mentioned) the connector patterna is identical between the VI's.

Just change the Static vi-ref to your tested VI and see what turns out.

/Y