LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sub-vi with different data output formats

Trying to create a sub-vi that uses .NET constructs to access various types of data from a database. I would like to have this single sub-vi handle all cases of requests for different types of information (via enumerated control input to the Case) so that in the event that changes are made to the C# dll, I only have to update the .NET Assembly References in one vi and then rebuild and deploy the application.

However the data returned from the sub-vi can be in many different forms depending upon the data requested; such as an array of clusters, a single Boolean, a cluster of doubles, etc. Was planning to use Bundles with a Case structure, but any data piped out of each of the cases must be in the same fixed format, so this appro
ach does not appear to be feasible.

Any suggestions as to a solution? I was eyeballing VI Server (Get Indicator Values?) or Property nodes as potential solutions by keeping the indicator data within each case (as opposed to piping it out), but no experience with these approaches (yet). Am I on the right track?

Thanks
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
0 Kudos
Message 1 of 6
(4,006 Views)
Hello AnalogKid2DigitalMan,

This sounds like the perfect situation to use variants (All Functions >> Advanced >> Data Manipulation >> Variant). You can convert any data type to a variant, pass the parameter out as a variant, and then convert it back to whatever type it was. Have you already looked into variants? There may be some aspect to your situation I am not taking into consideration that would rule out variants.

If none of these suggestions help, or if I�m not correctly understanding your issue, please reply with comments or answers to the discussion above and any additional information that may help, and I�ll be happy to look further into it.

Have a nice day!

Robert Mortensen
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 2 of 6
(4,006 Views)
Hi,
I am not sure if I fully understand what you are trying to do but I'm going to take a swing at it.

I think what may interest you is something known as polymorphism in LabVIEW. Polymorphic VIs accept different data types for a single input or output terminal. A polymorphic VI is a collection of subVIs with the same connector pane patterns. Each subVI is an instance of the polymorphic VI.

This will allow you to change the output of the subVI to what you want. However, you will have to create multiple subVIs for all the different datatypes that you would like to output and include these VIs when building the polymorphic VI.

To learn how to build polymorphic VIs, please use LabVIEW Help. Go to Help >> VI, Function, How-to Help >> Search Tab >> Search fo
r "Building polymorphic".

I hope this helps.

Feroz
0 Kudos
Message 3 of 6
(4,006 Views)
Robert/Feroz:

Thanks for the inputs, use of Variant data is a possibilty here. Am aware of Polymorphic vi's, but knowing firsthand what I am trying to achieve with this specific vi they will not work. Those will come into play in my math/filtering portion of the application.

I think I have eeked out the optimal solution. Use of a custom type-def cluster control and indicator. Could bundle all data fields together within a cluster. Pipe the cluster into the Case, and depending on what database action is to be taken, then unbundle by name, modify the data that needs to, then rebundle and pipe out of the case. Thus data format is the same for all sub-case tunnels. Added advantage is that if additional data fields are needed in the future, or existing
fields change, then just edit the custom type-def and save so that all instances of it throughout the entire application are updated.

Any drawbacks to this approach?

Thanks Again

-Pete
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
0 Kudos
Message 4 of 6
(4,006 Views)
Hi Pete,
I don't see any drawback to this approach. Making the custom control typedefined will certianly give you the flexibility you are looking for.

Since using variants works in your application, then that will get rid of the need to have a custom control. One thing to be careful when using variants is that when your .NET call is returning a variant, you will need to know the exact datatype for it in LabVIEW in order to convert.

Good luck!
Feroz
Message 5 of 6
(4,006 Views)
Pete,

Sounds like you might have a solution that works for you. I agree with Feroz that using a variant will eliminate the need for a type-def cluster, but you know best what your application needs.

Good Luck!

Robert Mortensen
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 6 of 6
(4,006 Views)