LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Variant to cluster with subset of attributes

I have multiple clusters that have some of attributes that they all share (like name, channel nr etc) and some that are specialized (e.g. thermocouple type). I have a state machine wich handles a lot of the basic stuff, i would like to reuse that state machine for all of those clusters. Thus i pass the cluster in as a variant (i actually pass the cluster reference not the data itself as i want to be able to update the cluster control) - now i would like to convert it into a more generic cluster first that shares all attributes that are present in all the clusters (name etc.) so i can do a lot of the independant stuff (writing headers for log files etc) and then call a subvi by referenc to do the more specific operations (like converting the raw measurement into the final value for different sensors types). Is there anyway to use a "generic" substitite cluster when using variant to data to get a cluster that has all the shared attributes for the inital state machine? 

 

Here is a simplified example of what i want to do: 

image.png

This code doesnt run as it tells me incompatible types. Is there a way around this to make reuse possible? 

0 Kudos
Message 1 of 6
(765 Views)

Hi,

 

Your example is crying out for Object-Oriented Programming (OOP) with inheritance.

I encourage you to try learning OOP through the LabVIEW Core 2 lessons, the online documentation or the LabVIEW examples (search "LabVIEW classes" or "Dynamic Dispatching").

 

 


@alphaNOVA wrote:

I have multiple clusters that have some of attributes that they all share (like name, channel nr etc) and some that are specialized (e.g. thermocouple type). 


The "shared attributes" could be managed by a base class and "specialized attributes" could be managed by different child classes.

 

 


@alphaNOVA wrote:

now i would like to convert it into a more generic cluster first that shares all attributes that are present in all the clusters (name etc.) so i can do a lot of the independant stuff (writing headers for log files etc)


This can be done with LabVIEW classes using the "To More Generic" node. Also the other way around can be done using the "To More Specific" node.

 


@alphaNOVA wrote:

and then call a subvi by referenc to do the more specific operations (like converting the raw measurement into the final value for different sensors types).


This is naturally done with LabVIEW classes when you override a method in a child class via dynamic dispatching. No need to call VIs by reference !

 

 

Also about your current technique, using control references to store data is generally not a good idea, as you are mixing data handling (such as file I/O) with graphical component operations (such as display, user input...). This may be ok for simple applications, but can be problematic when you decide to expand the abilities of your application and try reusing some of its components. Too much coupling between the data handling and the user interface handling makes scaling up your application much harder.

 

 

Regards,

Raphaël.

Message 2 of 6
(729 Views)

Thanks a lot for the detailt reply. I stumbled across the labview oop when searching for possible solutions but hoped there was a way around it since i have never done it before and currently am really time limited. So i guess copy past will have to do it for this project and i will visit oop the next time i start over. 

 

Regarding the passing of the references: I only read from the references with one exception - a display of the value of each measurement channel (not the one to be logged, only a direct visual feedback for each channel, thats why i liked to keep it grouped). 

0 Kudos
Message 3 of 6
(720 Views)

Then another alternative could be to use the same cluster for all your "sensors" and put specific data in a variant:

 

raphschru_0-1701563293321.png

 

So you can reuse your state machine for all your sensor types:

raphschru_1-1701563346101.png

 

0 Kudos
Message 4 of 6
(702 Views)

I tried variants but didnt get them to work as i like with being a control. You filled the data into the variant in the block diagram, this works for that example. For me each typdef cluster is a UI input for the user. But the controls in the typedef cant nest directly into the variant but has to be done in the block diagram 

image.png

If this would work like in the picutre it would solve my issues, but nesting controls that way seems only to be possible with clusters not with variants.

0 Kudos
Message 5 of 6
(673 Views)

As I said, using the same typedef for your data structure and for user interface is quite limiting. And of course you cannot stick controls inside a variant control. Variants contain data, not user interface controls. An "equivalent" for controls would be a subpanel. But here on the opposite, it only contains another user interface, not actual data.

 

Anyway, with variants you can do a lot of things. Why don't you separate shared and specific elements in 2 subclusters ?

 

raphschru_0-1701619124439.png

 

Here I used a Classic-style Cluster for the shared subcluster typedef, so that I can make it borderless.

But remember all this is kind of an "architectural hack" to not use LV classes.

0 Kudos
Message 6 of 6
(640 Views)