SubVI to accept any input cluster and to output the cluster?

[Becky1]

Hi,

This is my first post on this forum. I have searched the forums and did not find anything that helped me out in what I am trying to do.  Not saying it isn't out there but I did not find it in my search and if I found something similar I still wasn't getting it. 

I am trying to clean up my block diagram so I don't have wires everywhere.  So I want to create a subvi that accepts any cluster input, does its thing (get/obtain a queue), then output the queue, input cluster and error cluster.  In my research it seems that I should pass in a cluster refnum to the subvi.  I have played around with it but still not confident I am doing something right.  Because when I try to pass the cluster out the main program doesn't act like it should and I guess that is probably because the cluster I am passing back out has flattened out or something.  I read that somewhere that happens.  Any away here is an image of my subvi that I wish to modify so it can handle any cluster and just pass the cluster on through. 

Also what do I need to do in the main vi to pass in this cluster refnum?  The cluster will contain a variety of controls (boolean, refnum etc..) depending on who is calling it

I am not modifying the cluster in here but would like to pass it through untouched.  My way of cleaning up the wires (if that makes sense) in the main vi.  I am using LabView 2014.  I have been teaching  myself LabView for the past year and have been learning from tutorials and forums.

[altenbach]

Does not make a lot of sense. Can you attach a simplified VI illustrating what you are trying to do?

What do mean by "any cluster input"? Are all clusters of the same type?

[Becky1]

Here is a snapshot of me calling the subvi from a main vi.  This subvi would be called by more than one vi.  Each vi has there own cluster (which are similar but one will have more elements in it than the other).

[GerdW · Accepted solution]

Hi Becky,

THINKING DATAFLOW also means that the datatype of a wire is defined at edit time!

So having a subVI supporting different datatypes is either done using:

- polymorphic VIs

- OOP concepts

- variants

Each possibility has their advantages and disadvantages…

Why do you have different clusters? Can't you define the "biggest" cluster to incorporate all needed elements, so each VI can use its own subset of the available elements? Or maybe arrays could help too?

[JÞB]

There is no such thing as a generic queue refnum.  all the queues would need the exact same data type.  (Its why a cluster of string and varient is popular as a queue data type)

You might be looking for something like the actor framework witch passes data by queues contained in the priority queue.lvclass.  but the AF is not for everyone.

[Becky1]

---

@JÞB wrote:

There is no such thing as a generic queue refnum.  all the queues would need the exact same data type.  (Its why a cluster of string and varient is popular as a queue data type)

You might be looking for something like the actor framework witch passes data by queues contained in the priority queue.lvclass.  but the AF is not for everyone.

---

Thank you for the response.  I will look into that but it seems that GerdW is probably the simplest solution.  I was making it more complicated than it needed to be.

[Becky1]

---

@GerdW wrote:

Hi Becky,

THINKING DATAFLOW also means that the datatype of a wire is defined at edit time!

So having a subVI supporting different datatypes is either done using:

- polymorphic VIs

- OOP concepts

- variants

Each possibility has their advantages and disadvantages…

Why do you have different clusters? Can't you define the "biggest" cluster to incorporate all needed elements, so each VI can use its own subset of the available elements? Or maybe arrays could help too?

---

You know there really is know reason I can't make it one cluster to encompass all possible elements since it is a typedef ctl.  That would be the less complicated approach that I was thinking I needed to take.  I had been struggling with it all day so my mind was boggled.  I knew what I wanted it was getting there that I was running into a road block.  Thanks

[nathand]

One more reason this would be a bad idea: you're likely to end up with queue reference leaks that will slowly eat up memory. When you use a named queue, every instance of Obtain Queue must have a matching Release Queue, otherwise you leak a reference. That is, every call to Obtain Queue obtains a unique reference, even for a named queue where the underlying queue is the same. By using wires, you avoid this problem. In general, avoid obtaining queues by name unless there's a very specific reason to do so.

[Becky1]

I just double checked I do have a Release Queue for each named Queue. 

I went with the named queue because I thought I was supposed to since that was the sample I found online.  I have a main vi which I will call TestManager (which has a producer/consumer event driven loops) who establishes a TCP/IP connection and calls a subvi that serves as the TCPServer.  Within the TestManager there is a TCP Listen so when I client connects then it calls the TCPServer VI to send continuous data.  Then I have another main vi which I will call TCPClient who connects to the port and start receiving data.  The TCPClient vi also has a producer/consumer event driven loops.  Both main vis call the subvi that obtains the queue.  So are you saying that I can drop naming the queues in each of the main vis? 

[nathand]

---

@Becky1 wrote:

I just double checked I do have a Release Queue for each named Queue. 

---

For clarity - you need one Release Queue for each instance of Obtain Queue, not just one per queue. If you obtain the same queue by name multiple times, you need to release each reference individually. If you put an Obtain Queue in a loop, and obtain the same queue by name, but you only release it once after the loop ends, you'll have a reference leak - your memory use will grow on each iteration of the loop.

---

Becky1 wrote:

I went with the named queue because I thought I was supposed to since that was the sample I found online.  I have a main vi which I will call TestManager (which has a producer/consumer event driven loops) who establishes a TCP/IP connection and calls a subvi that serves as the TCPServer.  Within the TestManager there is a TCP Listen so when I client connects then it calls the TCPServer VI to send continuous data.  Then I have another main vi which I will call TCPClient who connects to the port and start receiving data.  The TCPClient vi also has a producer/consumer event driven loops.  Both main vis call the subvi that obtains the queue.  So are you saying that I can drop naming the queues in each of the main vis? 

---

Not sure what you mean by each of the main VIs - you can have only one top-level VI (unless you are, in fact, running more than one VI at the top-level, that is hitting the Run arrow on it - that would be one situation in which a named queue would be useful since there would be no way to pass a wire to both of them). You should obtain the queue in the VI that calls the subVIs, then wire that queue reference to the subVIs, no queue names required. If that's not clear, try posting an image of your code.

If you really want a way to share the queue reference without wires, consider a functional global variable that obtains the queue reference on the first call, stores it in a shift register, and returns that stored reference on each call.