Generic Queue?

[pjr1121]

---

@Jared7 wrote:

I don't see how I can pass queues containing different clusters into the different VIs though. Is this possible? 

---

This goes back to our earlier statements about using variants.  By converting the clusters to variant and placing the variant data in the queue, any data type or combination can be sent through the queue.  Each vi would be responsible for decoding it's own type though. this link is slightly related and will provide some good info.  http://expressionflow.com/2007/10/labview-queued-state-machine-architecture/.  This would be similar to your code except each of the states shown in this article would be related to one of your test vi.

Or you can make an intermediary subvi that "Decodes" the variant data based on the vi name.  This would be a helpful option if some of your vis accept the same clusters.

This is required with queues as you must declare the data type first and ONLY that type of info can be sent.  I'm not entirely certain if you can or can't use clusters of different elements without converting to variants first but my guess is no.

[Jared7]

Ah, that makes sense. The problem with a queue of variants is that I would need to modify each SubVI I'm testing to convert the variant to the required data type after dequeing the variant. I would prefer not to change the SubVIs I'm testing. There are quite a few of them. As I'm not fond of my LVOOP solution either, I think I'll go with a copy and paste solution. It's not a large VI so copy and pasting is not so bad. 

Thanks for all the suggestions and feedback.

[pjr1121]

You'd either have to modify the subvi's or create a single subvi who's purpose is to reconstruct the variant data.  This subvi would accept the Queue info as an input, and based on the Queue state, reconstruct the Variant data.  This may take some time to set up at first but once it's done there are a few advantages.  Adding new subvi's to test only require a new Queue state and a new Variant reconstruction state (both quick to add).  If a new subvi uses the same cluster as another one, you only need to duplicate the pre-existing state.

[DFGray]

My original suggestion of using classes as the queue element instead of variants still stands.  It gains you edit-time error checking instead of the run-time error-checking that variants provide.  The amount of code written in both cases (variant or class) should be similar.  It is also much more extensible at deployment time.

[Jared7]

After building more and more tests for different SubVIs, I found the most common operation I needed to replicate was to simply convert an array to a queue. I needed flexibility on when to call the VI-under-test and when to destroy the queue. Therefore I ended up creating a polymorphic VI to transform the array to a queue. The polymorphic VI requires a copy and paste for each data type though. I wouldn't have to copy and paste anything if this idea was possible: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi.... This idea is worth many Kudos!

Polymorphic VI attached. I think the polymorphic VI is simpler (ie. less code) than using LVOOP or variants. Plus I'm new to LabView and using a Polymorphic VI is quicker to grasp than learning the ins and outs of variants and LVOOP.

Thank you all! I am pleasantly suprised how active this forum is. Very helpful for a LabView newbie!

[Yamaeda]

That's a nice solution Jared! It can be done in a single VI if you use Variants as input and GetType from vi.lib/utility/variants, but that's a side note. 🙂

/Y

[Jared7]

I seem to run into this problem sometimes, where I find several nearly identical SubVIs accepting queues that are slightly different. The queues use different enums, although all the enums are in fact just 16 bit integers. To reduce code I would like to combine these SubVIs into a single SubVI. My only obstacle is this slightly different queue type used by each SubVI.

Is this possible without converting all VIs calling the SubVIs to use a queue type containing variants, like you suggested? I was hoping there might be a simpler solution since all queue types use the same underlying datatype (16 bit integer) even though the enum is different.

Thank you!

[nathand]

In this specific case, just make the queue contain a 16-bit value instead of the enumeration. You can do this even if the enumeration is part of a cluster; it will adapt automatically as shown here:

When you dequeue, you can treat the integer as an enum and let LabVIEW coerce it automatically, or you can do it explicity as shown here with variant to data.

[johnsold]

You will also need to know which enum is used in each case so that you can properly Typecast back to the correct enum.

In the attached VI the cluster contains an unsigned integer to transmit the enum value. The string passes the name of the enum (or perhaps the name of the typedef) which is used in the "decoder" to select the appropriate enum to recover the data. Note the coercion dots at the Bundle by Name "from_enum" inputs and that there are no coercion dots at the outputs.

Lynn