LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Subvi and input

The diagram function "Flatten To String" takes any datatype on its input
connector.
Is it possible to create a subvi that takes any datatype on its input
connector?

Thanks for yor answer

--
--------------------------------------------------------
Petter Kristiansen
Industriell Informasjonsteknologi AS
P.O.B 8208, Vågsbygd
N-4602 Kristiansand, Norway
Tel: +47 38 01 95 50, Direct: +47 38 01 95 53
Fax: +47 38 01 95 59, Mobile: +47 915 88 802
E_Mail: petter.kristiansen@initek.no
--------------------------------------------------------
0 Kudos
Message 1 of 9
(5,028 Views)
> The diagram function "Flatten To String" takes any datatype on its input
> connector.
> Is it possible to create a subvi that takes any datatype on its input
> connector?
>

Not directly. As the Flatten to String points out, a string can be
used to store any datatype that LV has. So for the moment, the best
solution is to make the subVI take a data string and a type descriptor
string, whatever the two outputs of the Flatten function produces. This
will allow for anyone caller to flatten the data and pass it to the
subVI. The subVI has a descriptor so that it can correctly deal with
the data for certain operations. This is far from ideal, but may be
enough to let you do what you are asking.

Greg McKaskle
0 Kudos
Message 2 of 9
(5,028 Views)

Amazing how 16 years later, that's still pretty much the only supported approach...

0 Kudos
Message 3 of 9
(2,079 Views)

@X. wrote:

Amazing how 16 years later, that's still pretty much the only supported approach...


That's not true at all.  LabVIEW is a striclty typed programming language so having flexibility in input is going to be a problem.  Of course this gives the benefit of knowing you'll never have any compile type syntax errors.

 

So you can flatten to a string, or you can convert to a raw array of bytes, or you can use a variant.  All of these options will allow you have an input that accepts multiple data types but they all have the same problem, which is that you need to code each data type you actually want by converting it to the strictly typed data you want so you can use it.

 

This is why most people when they need this look for polymorphic VIs which allow them to have a VI for each type, and then have the VI automatically select the type based on the wired input.  This works well if you have say 10 or less data types to support.  It can work for 60+ but managing those instances can be a pain without proper scripting.

 

But the magic bullet in my opinion is XNodes.  They are nodes on the block diagram, that create code, as you interact with them.  They have easy type adaption for inputs and outputs, and can allow for things like resizing, adding inputs or outputs.  The regular expression function is an XNode which is just a collection of VIs in a specific library, which says when to run each VI as you interact with it.

 

XNodes development is not something NI wants non-NI developers doing, but some amazing things can be done with XNodes where the code to interact with something is written, as you wire it up.  It has the flexibility of variants, but the strict data typing of polymorphic VIs.

 

Remember XNodes are very experimental and NI will not support code written with them, that being said XNodes are made by NI and shipped with LabVIEW, so they are considered stable in some cases.  They are also a lot of fun to play with and make, here are some of my favorite examples.

 

https://lavag.org/files/file/250-circular-buffer/

https://lavag.org/files/file/260-find-references-xnode/

https://lavag.org/files/file/248-variant-repository/

https://lavag.org/files/file/169-openg-array-xnodes/

http://forums.ni.com/t5/LabVIEW/Truth-Table-Node/td-p/1293680

https://decibel.ni.com/content/docs/DOC-13859

Message 4 of 9
(2,035 Views)

XNode is precisely what I was referring to and it is still not officially supported. QED.

0 Kudos
Message 5 of 9
(2,012 Views)

What is wrong with using Variants?  There are functions that will tell you the type of the Variant, allowing you to extract the data in the proper format (though admittedly this can get recursively messy if the Variant is, say, a Cluster or Array).  In other cases, you can use Polymorphic VIs.  I think it depends critically on What Needs to be Done ...

 

BS

0 Kudos
Message 6 of 9
(2,005 Views)

I've heard a couple NI people state XNodes will never see an official release, and I've heard some say that a release could happen someday and NI is working on it.

 

They are so damn powerful, I don't know how NI couldn't be at least considering it.  Only time will tell.

 

EDIT: @Bob there is still lots of things XNodes can do in terms of terminal adaption that a Variant can't.  You can have an XNode terminal be adaptive and be any type, that is allowed up stream.  So internally if you use a Search 1D array function and that XNode terminal is adaptive, then that terminal accepts a 1D array of any type and is broken otherwise.  To handle this there is one block diagram constant that needs to be set to True.  Much easier than using a Variant, and reading the type, and converting.  The XNode is also clear what types it accepts.  If the wire is broken it doesn't accept it.  With the variant you'll get a run time error which can be harder to debug and understand.

 

I think I really like the reusability of XNodes.  Spend a little time up front and it can be used everywhere.  Polymorphic VIs are a bit of a pain, spend lots of time up front and it can be used in a few more cases.

0 Kudos
Message 7 of 9
(2,002 Views)

BTW, my comment was not supposed to trigger any response.

I just had some fun looking at the forum's post in reverse chronological order.

There are some nostalgic stuff there...

0 Kudos
Message 8 of 9
(1,983 Views)

@X. wrote:

BTW, my comment was not supposed to trigger any response.

I just had some fun looking at the forum's post in reverse chronological order.

There are some nostalgic stuff there...


Fair enough, but looking back you do get to see how much, and how little has changed.  Also I think 16 years might be a new record, but it was intended so I'm not counting it.

0 Kudos
Message 9 of 9
(1,960 Views)