Creating a subVI that can take any kind of cluster as input and return the same cluster?

[Stenbo]

I'm loooking for a way to create a subVI that can take any kind of cluster as input and return the same cluster. A kind of unlimited polymorhphy. To clarify I'm looking for a way to implement the automatic adabtability of file IO functions, which adapt to the data type you wire to them.

Is this in any way possible?

Best regards

Stenbo

[tst]

The file I/O primitives are most likely not written in G.

To have true polymorphism, you will probably need to use scripting, which isn't supported by NI, and even then, it probably won't be instantaneous, like in those primitives.

Go to the LAVA forums scripting board (you have to register first). You will need to do some reading and thinking.

[Dynamik]

Hi Stenbo,

   Not sure what you're trying to do, but the following Morph.vi will take anything.

Modifying data inside Morph might be a pain, though it's not impossible to decode the Type array.  Did you expect to reference/change cluster elements inside your polymorphic VI?

Hope it helps!

[shoneill]

There's no easy way to do this properly within lanVIEW.  By properly, I mean with standard functions.

I have implemented something like this in the past for reading and writing INI files, and the best way I found was (contrary to the version on the OpenG website) to pass a REFERENCE to a cluster into the sub-vi, and then comb through the cluster (iteratively so that you can have clusters in clusters and so on) and parse the INI file (Main cluster.Sub-array1.Element for example).  This way, I was able to have an auto-adjusting INI file read and write function which adapts to any input cluster I throw at it.

I can't post it, because it belongs to my employer, but if you need tips::

1) You can list cluster contents via VI server, and get a reference for each sub-element.
2) You can cast them to the correct data type by reading out the Typedef and passing this to a CASE structure.  You can then access the correct properties for that data type.
3) Make very sure to close all Control references that you have opened.  This is probably the hardest thing to do, and gave me quite a few headaches due to the iterative (and linked in my case) nature of the references.

Oh, and performance can sometimes be a bit slow.

I am working on a newer version which should be significantly faster, but Sshhh.  That's secret.

Hope this helps

Shane.

PS: One thing which isn't very nice is that it's only possible to return a flattened cluster (String).  Re-casting this will allow data-flow to be retained.  This creates many copies of the cluster which may be a problem.  Otherwise you can forget data-slow and simply update the cluster without any inherent data-flow.  Then you need to read the cluster via the VI first (Sequence 0) and then read out the already updated cluster terminal itself (Sequence 1).

Message Edited by shoneill on 08-11-2005 09:21 AM

[tst]

Along the lines of Shane's answer (and more in the OpenG spirit), you can place the To Variant before your function and Variant to Data after you function so you can wire a variant into your subVI and get your data type back. The OpenG VIs do show one way of handling the different data types when converting to variants (although I haven't worked with them).

[akash189]

hi
how can i pass reference of a cluster as input to a subvi?
i tried passing application refnum to the subvi
thanks
akash