"anything" In-/Output

[i2dx]

Hi Folks,

is there a way to get an "anything" Input or Output to a Sub-VI, which adapts itself to the type of the input? Or is this restricted to System VIs?

I don't think this can be archieved with polymorpic VIs, because you have to create an instance for e.g. every possible cluster type ...

thx,

CB

[Aitor Solar]

Well, you can set the input as variant, and anything will adapt to it. The problem arises when you want the output to be different depending on the input type (I think you'll need scripting for that).

Saludos,

Aitor

[i2dx]

Well, you can set the input as variant, and anything will adapt to it. The problem arises when you want the output to be different depending on the input type (I think you'll need scripting for that).

yes, I want the output different on the input type.

an other possiblity would be, if I could figure out, how to access the elements of a cluster tranformed into a variant.

e.g. if I connect an error cluster to a "to variant" vi on the left side and create control as a output, I can see the cluster elements in the Variant Indicator. If I could e.g. convert them into a string array {{'name', 'value'}} or something like that, that would help a lot ...

[Aitor Solar]

You can. It's hard, but just a matter of time.

Use the "variant to flattened string" function with the variant input. In the type string you'll get the cluster definition, including the element types and labels. In the data string you'll get the values. There are already some VIs to get the types (including one at least in OpenG), but the part of parsing the value string can be a mess.

Hope that helps.

Saludos,

Aitor

[LAVA 1.0 Content]

I've tried to dig this issue a few months ago. No, there is noway to do it, that's publicly accessible. I myself used scripting to create a few hundred VIs which I add to a polymorphic VI also using scripting.

There are two non-public ways to do this: New XNodes and old xnodes. New XNodes require LabVIEW 8.0 or newer and require a license from NI which you won't get. Old xnodes work at least in LabVIEW 7.1 and LabVIEW 8.0 and don't require a license, however they are not documented in any way. It's also probable that old xnodes will be replaced by new ones and the support for the old ones will be dropped. The idea with both new XNodes and old xnodes is the following. When you connect a wire to the diagram, XNode runs some developer defined code, which generates the actual diagram of the node. This way you can catch information from the wire type connected and generate a diagram for just that wire type. You get real polymorphism, although it's quite complicated to develop.

New XNodes are libraries, which can include special VIs called Abilities the same way as XControl special VIs are called Abilities. The XNode libraries are named with ".xnode" extension. You cannot write a library and make it an xnode by just changing the name, I've tried it and it didn't work. The templates for Abilities can be found from <LabVIEW>\resource\Framework\Providers\xi\xnode.llb. I don't know if it would be possible to modify one of the XNodes shipping with LabVIEW so that one replaces the Ability VIs one by one with ones created from the template. I suppose it won't work.

There are programming languages like Haskell in which functions can be defined so that they accept all the types for which the subfunctions inside the function are defined. This way you get ultimate reusability. For example you can define '+' operation for some new type. Then anything you already have written that relies on existence of '+' operation would be functional to your new type. This is really cool, it's a pity that we don't have this in LabVIEW. This is real polymorphism... I'd really like to see this kind of typing system in LabVIEW. In addition I'd like to see all other features of Haskell programming language like lazy evaluation and wires that carry diagrams in LabVIEW. Haskell monads wouldn't probably be needed since in dataflow language one can define the order of operations by connecting some wire from one operation to another. The wire defines the order even when it doesn't carry data (well this is almost exactly the same thing that Haskell monads do).

What you can do in LabVIEW 8.20 is to use classes and inheritance to get support for multiple types. Still you have to define what type you'd like to support.

[i2dx]

You can. It's hard, but just a matter of time.

Use the "variant to flattened string" function with the variant input. In the type string you'll get the cluster definition, including the element types and labels. In the data string you'll get the values. There are already some VIs to get the types (including one at least in OpenG), but the part of parsing the value string can be a mess.

Hope that helps.

Saludos,

Aitor

jopp, I did this - 2 or 3 years ago, and I called that "dynamic cluster" - a cluster which existed only by reference. You have to figure out how the type descriptor array works, then you can create clusters in a way you want. the only drawback is - if you want to access them, you can do this only if you convert them into a variant. You cant create any bundle or unbundle nodes on the BD with this cluster.

ok, Xnodes could be a solution - but - there is the license / documentation issue. Because I'd like to have this feature for my ADO-Toolkit I better not use Xnodes, I don't want to get in trouble with NI ...

thx anyway,

CB

[Aitor Solar]

jopp, I did this - 2 or 3 years ago, and I called that "dynamic cluster" - a cluster which existed only by reference. You have to figure out how the type descriptor array works, then you can create clusters in a way you want. the only drawback is - if you want to access them, you can do this only if you convert them into a variant. You cant create any bundle or unbundle nodes on the BD with this cluster.

But you can create an object if you have the type descriptor... Anyway, the problem is always the output type. You need a VI that executes when put in the BD, and that's a Xnode (a solution I don't like either).

Wait a minute, what about this: have a running VI in memory that checks what you're doing in another VIs BD (easy). When you connect a wire to the "variant VI" input, this daemon reads what type of wire it is and modifies the "variant VI" output indicator to be the same as the input. That would work, but the "variant VI" should be constructed to allow its output manipullation.

Do I have explained mayself?

Saludos,

Aitor

[tnt]

an other possiblity would be, if I could figure out, how to access the elements of a cluster tranformed into a variant.

e.g. if I connect an error cluster to a "to variant" vi on the left side and create control as a output, I can see the cluster elements in the Variant Indicator. If I could e.g. convert them into a string array {{'name', 'value'}} or something like that, that would help a lot ...

Hi,

maybe a stupid question, but have you tried the openG vi's??

I think

- Cluster to Array of VData (Variant as input)

- Get Cluster Element by name

- Get Cluster Element names

come close to your "other possibility"

good luck.

TNT

(In the past I've once made a logging/debugging vi with a variant input

which filtered out any variant input into a readable string-format)

[Kevin Boronka]

That's exactly what a polymorphic vi is for. Yes, you do have to create a bunch of VI's (one for each type), but I think it'll be faster then any varient type casting.

[LAVA 1.0 Content]

That's exactly what a polymorphic vi is for. Yes, you do have to create a bunch of VI's (one for each type), but I think it'll be faster then any varient type casting.

Hmm... Have you ever tried to create more than 1000 VIs and add them into a polymorphic VI manually ? And then find that you have a bug or that you want to change something and make the change to all of the VIs? :headbang: And when you place such a polymorphic VI on a block diagram, all of the VIs are read into memory... and it takes a while... and it consumes memory. But at runtime, it's fast, and thats why I use them yes. But I must say it's not fun and without scripting it would be impossible.

[jpdrolet]

Hi,

maybe a stupid question, but have you tried the openG vi's??

I think

- Cluster to Array of VData (Variant as input)

- Get Cluster Element by name

- Get Cluster Element names

come close to your "other possibility"

good luck.

TNT

(In the past I've once made a logging/debugging vi with a variant input

which filtered out any variant input into a readable string-format)

Definitely you need OpenG Data Tools to manipulate variants. The input will convert to a variant but the output will stay a variant that you will have to convert back to typed data on the calling diagram. On the diagram it will look like that:

This OpenG VI parses the elements from an arbitrary cluster and read their values from an INI file and returns the cluster as a variant.

The caller converts the data back to the type of the cluster.

[i2dx]

Definitely you need OpenG Data Tools to manipulate variants. The input will convert to a variant but the output will stay a variant that you will have to convert back to typed data on the calling diagram. On the diagram it will look like that:

This OpenG VI parses the elements from an arbitrary cluster and read their values from an INI file and returns the cluster as a variant.

The caller converts the data back to the type of the cluster.

that looks close what I want to do:

a little explanation:

I want a "UPDATE Simple" and an "INSERT Stimple" VI for my ADO-Toolkit. As log as the data come in an Array, it's easy to create an INSERT/UPDATE SQL Statement. But if the data are a cluster or an array of clusters, things become more difficult.

I know the NI Database Connectivity Toolset uses a polymorphic VI for the common types (String Arrays, Number Arrays, etc) and a Variant input for the other types. But I wanted to be better. My first idea was to use an "anything" input - like the "to variant" VI does, but it seems - that will be hard to archieve - if there is a way (maybe Xnodes would work ...)

If I had a "anything" input, I could flatten anything to XML, parse that XML and get an array of Type + Data which could be easily converted into the desired SQL UPDATE or INSERT Statement.

Variants - or better - flattended variants - are a crutch which could work, but it's alot of word and - as the type descriptors change with each LV version, I'd like to avoid that.

I'll think about that and thank you all for the input!

cb

[Jim Kring]

that looks close what I want to do:

a little explanation:

I want a "UPDATE Simple" and an "INSERT Stimple" VI for my ADO-Toolkit. As log as the data come in an Array, it's easy to create an INSERT/UPDATE SQL Statement. But if the data are a cluster or an array of clusters, things become more difficult.

I know the NI Database Connectivity Toolset uses a polymorphic VI for the common types (String Arrays, Number Arrays, etc) and a Variant input for the other types. But I wanted to be better. My first idea was to use an "anything" input - like the "to variant" VI does, but it seems - that will be hard to archieve - if there is a way (maybe Xnodes would work ...)

If I had a "anything" input, I could flatten anything to XML, parse that XML and get an array of Type + Data which could be easily converted into the desired SQL UPDATE or INSERT Statement.

Variants - or better - flattended variants - are a crutch which could work, but it's alot of word and - as the type descriptors change with each LV version, I'd like to avoid that.

I'll think about that and thank you all for the input!

cb

Take a look at these:

OpenG LabVIEW Data Tools Examples

• Cluster to SQL INSERT Statement
  
• Get Object Attributes as XML
  
• OpenG Flatten to XML
  

[i2dx]

Take a look at these:

OpenG LabVIEW Data Tools Examples

• Cluster to SQL INSERT Statement
  
• Get Object Attributes as XML
  
• OpenG Flatten to XML
  

I knew you have an inspiration 4 me

thx

cb