Using polymorphic VI as data selector for a Var_Tag array data type

[Mahbod Morshedi]

Hi all,

In the efforts to Have a clean data wire in my app I am suing a data wire such as this:

I Have a VI that reads and gets and reset the data on the wire and am using the RefNum for manipulating or storing the data on the wire meaning I only have a reference wire passed through my multiple loops.

To get variant and translate it into my data I decided to use a polymorphic VI and use the type as a data type selector for my convertor:

  

 

Is this proper or there is better or more efficient way?

Cheers,
M

[ensegre]

A malleable VI may be neater, but it's a matter of taste. Something along the lines of this:

 

[Neil Pate]

How do you look up the data in your array? Via --Tag?   If you are going to do that you might as well just use a map.

But anyway, I am not a huge fan of this approach. I think better composition into clusters or objects will also make your wiring neater, more testable, scalable etc

I do recognise the need for nice neat diagrams without wires going all over the place, but proper decomposition/architecture normally fixes this.

So in general I would have to say you are not on the right track with this approach, but this is of course just my opinion.

[ensegre]

I must admit that I may have misunderstood what the OP wants to do, hence my answer may have been completely off. Is he rather trying to construct an array of heterogeneous elements, by flattening all his possible data types into a variant?

[Mahbod Morshedi]

Thank you, Neil and Enserge,

I agree with you; however, while preparing my app, I realised that every time I needed to add a new function, I had to change data types or add a new cluster, which led to VIs breaking. This was the only solution I could think of to be compatible with every wire time in the terminals.

 

Cheers

[Neil Pate]

Have you looked into typedefs? This solves the problem of VIs breaking if you modify the data structures as there is then only a single instance of the definition of a data type.

[ensegre]

On 7/10/2025 at 8:44 AM, Mahbod Morshedi said:

 

  

Looking at the example of the OP, it looks he's already aware of typedefs. To him to say what exactly he meant.

[Neil Pate]

Well then I don't get the question I suppose.

[X___]

Maybe the OP is trying to achieve a generic storage container (functional global of sort) using a variant. 

Something akin to this:

Here I am using a typedef enum (Variable) to ask for a specific item, which is stored as an attribute of a single variant.

There is no  need to use a DVR to avoid copies of the variant (if that is the concern), as the only thing which is needed is a copy of the accessor VI (shown above) wherever a variable is needed.

There is no need to bother with a polymorphic VI as the output variant is of the requested type and will easily convert to the right type of wire with the drop of Variant to Data primitive, as long as the resulting wire is connected to a terminal. If not (for instance it is connected to a numeric primitive), then yes a polymorphic wrapper VI might be neat (but still a lot of work).

When adding a new attribute, simply modify the Variable typedef and add a case. No VI should break.

The only drawback of this approach is that that VI has to be non-reentrant and therefore, wherever it is used, this will interfere with parallelism.

This can be to some extent avoided with DVR read action, which might be the reason the OP chose that approach.

My 2 cts.

[Mahbod Morshedi]

Hi All, 

this is the VI I am using. Maybe it will be more clear this way.

 

Cheers,

M

Data Tag.vi

[ensegre]

Maybe the question is if you have to be committed to this array of clusters of string+variant for some specific reason, or if it is an attempt to implement some architecture which might have a different implementation. I.e., I don't understand if yours is a general question about design, or a specific question about the mechanics of converting variants to data.

[X___]

12 hours ago, Mahbod Morshedi said:

this is the VI I am using. Maybe it will be more clear this way.

Data Tag.vi 30.98 kB · 4 downloads

You are reinventing variant attributes and the corresponding primitives (see my post above).

This being said, there is a lot of things to be commented on your code from a G-style point of view :-) but I'll leave that to others.

As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle?

I have done that myself for a few common types (numerics, string, path, and array of such) and I find that very handy, but I wouldn't bother for types I use occasionally, and in particular, application-specific types. Just my opinion.

[Neil Pate]

3 hours ago, X___ said:

You are reinventing variant attributes and the corresponding primitives (see my post above).

This being said, there is a lot of things to be commented on your code from a G-style point of view :-) but I'll leave that to others.

As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle?

I have done that myself for a few common types (numerics, string, path, and array of such) and I find that very handy, but I wouldn't bother for types I use occasionally, and in particular, application-specific types. Just my opinion.

yup, completely agree with this ^^^^

I have done something similar in the past where I used a global variant as a data store, and then used attributes to store/get data (and some convenience VIs to convert to the known types). It was a bit of an experiment in a system that had many data generators (different interfaces to independent pieces of hardware) and several hundreds of data variables (tags) all communicated over OPC-UA, so had a fairly sophisticated method to set/get by name as I didn't want to deal with such a mega-cluster anywhere. It worked fine, but in the end I would not really recommend it for simple systems where you just dont want to make the proper data types.

Edited July 15 by Neil Pate

[ShaunR]

16 hours ago, X___ said:

As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle?

I think you'll find the polymorphic VI is used to get the data back out again. One of the issues with LV is that it's very easy to get data into a generic form but it's a bugger getting it back out again due to strict typing. I used the polymorphic method for reconstitution when I created a JSON parser that encoded to string (the ultimate variant) and one chose a polymorphic instance as to how you wanted it back out (string, U64, DBL etc).

Edited July 16 by ShaunR

[Neil Pate]

20 hours ago, ShaunR said:

I think you'll find the polymorphic VI is used to get the data back out again. One of the issues with LV is that it's very easy to get data into a generic form but it's a bugger getting it back out again due to strict typing. I used the polymorphic method for reconstitution when I created a JSON parser that encoded to string (the ultimate variant) and one chose a polymorphic instance as to how you wanted it back out (string, U64, DBL etc).

yes but I think X means creating polymorphic instances for all the unique typedefs/clusters inside, so not just the normal primitives that you can create once and forget about. 

[X___]

That's what I mean:

I think it should be a LabVIEW primitive for built-in types.

There is no error passing so if the input variant if of the wrong type, you get the default type, but that's fine for my purpose. I am supposed to know what I am doing when I lay down my wires, right?

[Mahbod Morshedi]

Hi All,

 

Thank you for all the help and helpful comments:
1 - You all were correct about redefining variant attributes. I realised that, and good god, it is easier to use.

2- For the polymorphic VIs, I appreciate the primitive data form of the polymorphic instance. However, I am a scientist in the lab, developing several software programs that facilitate the acquisition, display, processing, and exporting of data from various equipment and experiments. Since I am just learning all these tools and admittedly not a very good programmer, I occasionally make a tweak or add a new feature. Then I realise, 'Oh well, I need this extra data cluster for backup data, and it has to be labelled...'
In cases like this, a new data wire is created, and it is too much of a hassle to go back and fix things, add a new terminal, or change VIs to deal with this new data type or to accommodate this new wire. That made me look into variants and consider a single wire to rule them all. 
However, to extract the data (Unique clusters or any other types), I thought it would be best not to have to modify any VIs. I imagine I make a polymorphic VI, so for any new thing I want to add, I have to copy the same VI and change the data type of the variant to 'data'.


I hope that clarifies my intention. I agree that my lack of understanding of the correct procedures and jargon can cause a lot of headaches for you guys, and I apologise.

Cheers,

M

[Neil Pate]

@Mahbod Morshedi no need to apologise at all. This is a journey for everyone and all the opinions here are given with absolute kindness in mind, just sometimes the message gets lost in text.

If you add new features to your application, there is no need to make a new wire. Assuming you have some kind of core cluster you would just have a single wire through the whole application and you can add new stuff into this cluster. Now, that will start to get clumsy at some point (when it reaches what we sometimes call "megacluster" status). 

To prevent this from happening it is normally better to try partition your application into independent things, (loops) that contain just the data they care about. Then each thing becomes simpler.

Then you need to figure out how to communicate between these things and you go down a rabbit hole.

Have you looked at one of the popular frameworks like DQMH?

Edited July 18 by Neil Pate

[Mahbod Morshedi]

7 hours ago, Neil Pate said:

@Mahbod Morshedi no need to apologise at all. This is a journey for everyone and all the opinions here are given with absolute kindness in mind, just sometimes the message gets lost in text.

If you add new features to your application, there is no need to make a new wire. Assuming you have some kind of core cluster you would just have a single wire through the whole application and you can add new stuff into this cluster. Now, that will start to get clumsy at some point (when it reaches what we sometimes call "megacluster" status). 

To prevent this from happening it is normally better to try partition your application into independent things, (loops) that contain just the data they care about. Then each thing becomes simpler.

Then you need to figure out how to communicate between these things and you go down a rabbit hole.

Have you looked at one of the popular frameworks like DQMH?

Yes, I actually like the DQMH, but I haven't gotten used to it and am still learning. My goal is to rewrite all the apps in the DQMH framework eventually. I have a long way to go, though.

Cheer,

 

M

[ShaunR]

11 hours ago, Neil Pate said:

Have you looked at one of the popular frameworks like DQMH?

Any framework that needs scripting, wizards and inserts comments for you to update it; isn't worth the diagram space it consumes.

Edited July 19 by ShaunR

[Neil Pate]

12 hours ago, ShaunR said:

Any framework that needs scripting, wizards and inserts comments for you to update it; isn't worth the diagram space it consumes.

Phew that is a pretty strong opinion!

Although I personally am not a fan of the overall style of DQMH none of my problems are with the scripting/wizards or placeholder text. I think any framework that tries to do "a lot" will be complicated... your own personal framework (which you likely find trivial to use) is likely to be a bit weird to others. DQMH is extremely popular for a reason...

To paraphrase the words of a wiser person than I, "please don't yuck someone elses yum"

[ShaunR]

13 hours ago, Neil Pate said:

Phew that is a pretty strong opinion!

Although I personally am not a fan of the overall style of DQMH none of my problems are with the scripting/wizards or placeholder text. I think any framework that tries to do "a lot" will be complicated... your own personal framework (which you likely find trivial to use) is likely to be a bit weird to others. DQMH is extremely popular for a reason...

To paraphrase the words of a wiser person than I, "please don't yuck someone elses yum"

When have you known me to have a weak opinion? 

If you have to have a consortium to manage it and spawn an entire industry in order to use some code then it has just become a means to justify an ends. Wizards and scripting are symptoms of excessive boiler-plate generation, lack of reusability and, even worse, trying to hide it. I'm not against frameworks, per say, and In that respect I would argue that DrJPowells solution is the best of the bunch although it uses the OpenG tools heavily so it is not usable to me.

By the way. I don't have a personal framework as such. Services are communicated to and from with messages and all messages are strings. You don't need lots of framework for that-just a couple of VI's in a polymorphic. The Services themselves can be anything you like, as long as it works - choose your poison!

They come up with this kind of "solution" every few years and then run with it until it the next thing. First it was State Machines, then QMH, then it was Actor Framework. Oh and what about that silver bullet of Systems Software that I can never remember the name of? It's all "One Ring" software. In current years it seems to be this special QMH with knobs on (and committees, working groups and special events that everyone can go to to pat each other on the back). The sales pitch is usually that "this" framework will mean interns churn out the code of 20 year experienced CLAD's. It never does, of course. It always ends up as bug ridden 10,000 VI monstrosities that take 10hrs to compile. They've been trying to replicate experienced programmers' outcomes with processes for over 50 years. It has been such a failure (the philosophy rather than any individual framework) they had to convince everyone that continuous updates were the answer.

To paraphrase the words of a wittier person than I, "If the milk turns out to be sour, I ain't the kinda pussy to drink it." 

[Neil Pate]

1 hour ago, ShaunR said:

When have you known me to have a weak opinion? 

Literally never. Which is why I value your input into the community so much. (No sarcasm intended).

Would love to sit down and have a few beers/coffee sometime and muse about the state of many things LabVIEW-ish and other stuff.

[ShaunR]

On 7/20/2025 at 2:53 PM, Neil Pate said:

Literally never. Which is why I value your input into the community so much. (No sarcasm intended).

Would love to sit down and have a few beers/coffee sometime and muse about the state of many things LabVIEW-ish and other stuff.

I'm not sure that would be all that interesting (for you). Most of what I think is far more eloquently communicated by Alan Kay in his musings.

e.g.

 

"Computer Science isn't real science!"