LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mallable VI - only accept Variant with specific structure/ data

I have a project where I want to build some VIs that only accept a specific class or a Variant with specific data both as a single object/ item or as an array. A polymorphic VI does the trick for sure but it feels like a malleable VI could do this in a more convenient way with less copy past code which is always a good thing.

 

Using the Type Specialisation Structure for the LV classes is pretty straight forward and works perfectly fine. The headache begins with the Variant cause I not only need to check the datatype itself (Variant) I also need to check if the data inside the Variant matches a specific typedef. I just can’t figure out how to do this in a better way than in my example below. Using the Variant to Data works just fine but it won’t break the VI like it should so I have to use the error out and check for an error as well. Maybe this is the way it’s supposed to work with Variants?

 

Jens_S_0-1636450889070.png

 

0 Kudos
Message 1 of 8
(2,083 Views)

Look at it this way:

  • At edit-time, type information flows through wires (this is what allows malleable VIs to break wires).
  • At run-time, data values flow through wires.

Of course it's not possible to have a wire break-or-not depending on what value will flow through it in the future, when the code runs.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 8
(2,048 Views)

Thanks for you answer.

 

I understand that the malleable VIs just do there stuff at compile time so they don't know anything about the data inside the wires. The Variant I use is a type def one as I was hoping that I can simply check if the Variant is a generic one, another type def or the type def I accept but the Assert Structural Type Match explicitly ignores type defs and structure names. So I was hoping there might be a way to check for the type def

0 Kudos
Message 3 of 8
(2,019 Views)

I'd wire the type defed cluster right to the terminal, then let the VIM turn the terminal into a cluster.  Then inside that have a type specialized structure with an equal to the constant of the type def you have.  The result doesn't matter just that you can't perform an equals on two clusters, if they aren't compatible with the data types.  This would generate a broken wire and so the VIM won't let you wire to it.  As a bonus if you don't wire the output of the equal to anything the compiler will remove it as dead code and it isn't used in the running of the program, only for compile time checking.

0 Kudos
Message 4 of 8
(2,004 Views)

Sorry but I don't get it 🤔 Can you post a little snippet or example?

0 Kudos
Message 5 of 8
(1,996 Views)

I started to then wondered why this is a VIM at all?  What are in your other cases?  Is this a single VI that can work with something like 4 different clusters?  If so then that seems like it should be a polymorphic VI, one for each type with Adapt to Data Type.

0 Kudos
Message 6 of 8
(1,990 Views)

It is a VI that should allow 3 data types to work with. A custom class, a array of the custom class and a type defd variant. I originally started with a polymorphic VI and was wondering if a malleable VI just could do the same but in a single file and not 4. The type def variant unfortunately is giving me more headache then it should.

0 Kudos
Message 7 of 8
(1,977 Views)

@Jens_S wrote:

Thanks for you answer.

 

I understand that the malleable VIs just do there stuff at compile time so they don't know anything about the data inside the wires. The Variant I use is a type def one as I was hoping that I can simply check if the Variant is a generic one, another type def or the type def I accept but the Assert Structural Type Match explicitly ignores type defs and structure names. So I was hoping there might be a way to check for the type def


Could be done with an XNode, but that seems like overkill.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 8 of 8
(1,975 Views)