LabVIEW’s vast math and signal processing IP has been a benefit of the platform since its early days. Engineers and scientists frequently need these algorithms for their designs. As LabVIEW IP has evolved over the years, similar functions have been created to solve different workflows. For example, have you ever typed “filter” into the palette search in LabVIEW when simply looking to filter 60 Hz noise out of your measurement? If you have, you were undoubtedly met with a list of choices that could give even the savviest of G programmers some anxiety.
LabVIEW uses the polymorphic VI to allow API developers to create smaller, easier to use APIs. However, polymorphism conflates two separate user needs: the ability of the user to choose between similar functionalities like a filtering algorithm as well as auto-adapting to a wired input type. Moreover, the API developer must decide if they want the user to manually select the polymorphic instance or if the node will auto-adapt to the wired types. These capabilities cannot be combined in a polymorphic set. In LabVIEW NXG, we’ve created separate mechanisms to decouple these desired behaviors.
The DAQmx Read VI is an example of a polymorphic VI, with an option to select Double or Waveform datatype, 1D or 2D array, and 1 or N Channels and Samples.
Selecting Between Behaviors
In LabVIEW NXG, we added the internal concept of Modes, which allow API developers to create a decision tree for users like polymorphic VIs in LabVIEW. On node drop, the user receives configuration options that allow for an interactive choice. In the example below, the user can pick the frequency range and filtering algorithm after dropping the filter node. The image shows just some of the 28 different settings the user can select.
Some of the configuration options that are possible from the Filter node in LabVIEW NXG.
Automatically Adapt to Wired Datatype
Five different overloaded instances of the Lowpass Butterworth Filter nodes in LabVIEW NXGAn internal concept of Overloads makes it possible for API developers to create a group of GVIs that will automatically switch based on what the user wires to the inputs. The API developer specifies an Overload Group ID that governs which GVIs can be interchanged. The picture below shows five different overload instances of the lowpass Butterworth filter.
Eventually, we’d like to open the ability to overload some internal LabVIEW nodes by using Overload Group IDs.
The best part of these features is the ability to combine a mode hierarchy with leaf-level items that are part of an overload group. We’ve really taken advantage of this technology in our math and signal processing APIs. We believe the experience will make for a much more approachable and easier-to-use API.
In the filtering example described above, one palette entry has 28 different manual configurations. Combine that with the five different data type options in the overload group, and 140 different configurations exist from one palette entry.
Our filtering palettes have been reduced from 39 specific entries in LabVIEW to just 13 in LabVIEW NXG. In LabVIEW, these 39 functions only operate on a 1D numeric array. In LabVIEW NXG, they all operate on scalar numeric, 1D numeric, 2D numeric, waveform, and 1D array of waveform. The illustration below demonstrates how the filter hierarchy was built using both modes and overloads.
This is just one example of how an API can utilize modes and overloads to help the user. The ability to create modes and overloads isn’t publicly available in the newest version of LabVIEW NXG; however, we’re looking to extend these features to our user base soon.