Malleable VIs in LabVIEW
By Henrik Hjorth
Mallable VIs were introduced in LabVIEW 2017 to implement generics and can adapt each terminal to the input data type. This allows you to create functions where the data type is not defined in the function itself but is determined during compile- or runtime.
I’ve found this feature quite useful to increase code reuse and often simplifies the block diagram implementation, both during development and afterward when reading the code.
A common use for malleable VIs is to make general functions for array manipulation, such as delete multiple elements from an array, search all elements in an array, or unique insert into an array (i.e. insert an element only if it is not already existing). Here’s an example of an implementation of delete multiple elements from an array.
A malleable VI is created by changing the file extension of a standard VI to .vim. The VI must also be configured to be inlined, have debugging disabled, and set to reentrant execution.
In LabVIEW 2019, property and invoke nodes were accepted to be inlined and supported by malleable VIs as well, making this feature even more useful (see Inlineable property nodes / Invoke nodes when apporopriate – NI Community). Below is an example of a simplified disable control function implemented in a malleable VI. Notice that there is no coercion of the reference and the strict type is kept.
Type Specialization Structure was introduced in LabVIEW 2018 and can be used to disable a specific section of the code based on compilation results. This is useful e.g. to handle both scalar and array inputs. The disable control function above can then be extended to handle an array input as well. The input control can be defined either as array or scalar type, both will work as seen below.
Each case in the type specialization structure is assigned either of these values
– Declined = subdiagram has syntax errors
– Accepted = first subdiagram to compile without errors
– Ignored = a previous case in the list is already accepted
To force a malleable VI to decline specific data types or only accept a subset of data types, the Assert Type category functions in the Comparison palette can be used.
Malleable VIs can in some cases lead to broken wires when a polymorphic input of a malleable VI is wired. This happens if the malleable VI cannot properly determine the proper datatype of the output, e.g. if type casting is used or a case structure outputs different data types depending on case. In this scenario, the easiest way to deal with this is to put the part that breaks the functionality into a standard sub VI and call this sub VI from the malleable VI.
This dummy example demonstrates this, the block diagram of the malleable VI is shown to the left. In this case, it will accept numeric
values but not e.g. boolean and string data types.
But if moving the case structure to a sub VI, all data types will
be accepted.
