What is the performance impact of using a LabVIEW class versus a cluster typedef?
Benchmarking on a range of computers shows the performance between these two is nearly identical. Refer to the question below for more performance information.
What is the performance overhead of a dynamic subVI call (vs. a normal subVI call)?
A dynamic dispatching subVI has some small overhead when LabVIEW looks up which subVI to invoke. The overhead is constant. It does not increase as you add more classes or as you add more dynamic VIs to a class. There can be a performance hit if the subVI call has to make extra copies of the parameters to match the functionality of the actual subVI LabVIEW invokes. You can avoid this by wiring the input front panel terminals to output front panel terminals even on dynamic VIs that you never expect to call (for example, parent VIs that exist only to define the connector pane for children to override). Refer to LabVIEW Object-Oriented Programming: the Decisions Behind the Design for details on how the dynamic dispatching is able to achieve constant overhead performance.
How do LabVIEW class libraries differ from project libraries?
A LabVIEW class is a type of project library. It is a project library dedicated to the task of defining a data type. Like a project library, the LabVIEW class defines scope and namespace for its member VIs, and a VI can be owned by one and only one LabVIEW class.
The LabVIEW class has a private data control. This is a control VI that defines the data values of the class. This special control is not part of other library types, and is actually saved inside the class file. LabVIEW classes have all the properties that libraries have, and some additional properties. You can see the additional properties in the Class Properties dialog box on the Inheritance, Probes and Wire Appearance pages.
The only ability that project libraries have that LabVIEW classes do not is the ability to contain sublibraries.
When using LabVIEW object-oriented programming, what gets loaded and when?
If a VI uses a LabVIEW class, then loading the VI loads the class, just like a VI loads all of its subVIs. A LabVIEW class in turn loads all of its member VIs and its parent class. Parent classes do not automatically trigger the loading of their child classes. Parents do not have any links to children. A member VI of a parent may use a child class and thus LabVIEW loads the child class.
What does "by-value" and "by-reference mean?" What are the pros and cons of each?
"By-value" means that the wire carries actual data of the type of the wire. "By-reference" means that the wire carries a reference to the data of the type, and LabVIEW stores the actual data in some central repository. Most data types in LabVIEW, including numerics, arrays, clusters, strings, Booleans, and paths are by value. Typically, the only types that are by reference are those that use communications or reflect system resources, such as file refnums, queue refnums, and VI Server refnums. LabVIEW classes are by value. In by-value syntax, each object has its own data values, which you can modify independently of other objects. In by-reference syntax, there is a single instance of data to which multiple objects refer. If one object modifies the data, it has to be careful not to conflict with other objects who are reading and writing that data. The primary pros and cons are:
- By-value is better in a highly parallel environment such as LabVIEW because it avoids race conditions.
- By-value allows the compiler to determine when copies of data need to be made, lessening the burden on the programmer.
- By-reference gives the programmer responsibility for allocation, which is sometimes a better model for single-instance resources and large data sets.
Why is LabVIEW object-oriented programming "by value?"
Refer to LabVIEW Object-Oriented Programming: the Decisions Behind the Design.
Does NI have UML tools for creating/managing LabVIEW classes?
NI does not have a native UML tool. Endevo makes a tool for generating classes from UML diagrams, and generating UML diagrams from code. The tool currently works for GOOP classes (refer to the LabVIEW Object-Oriented & GOOP Toolkit section above), but an upcoming release will support LabVIEW classes as well.
Why can't I use "Make Current Value Default" on LabVIEW class controls and indicators? Why can't I set the values of LabVIEW object-oriented programming constants?
Make Current Value Default is a valuable feature of LabVIEW. You might use it frequently for building test VIs. This feature is not supported for LabVIEW classes in LabVIEW 8.2 and later because of the complexity of providing a good user interface so that the user knows when the data is something other than the default-default, even though the user cannot actually see the data because the data is private. This feature is a high priority to be included in a future LabVIEW version.
Why can't I make a dynamic VI reentrant?
Reentrant dynamic VIs are not supported feature in LabVIEW 8.2. Because dynamic subVI nodes at edit time do not know which subVI LabVIEW will actually invoke at run time, each node would have to create clones of all the possible subVIs. This turns out to be prohibitively expensive in memory.
(LabVIEW 8.5) You can use reentrant dynamic VIs in LabVIEW 8.5.
You can configure a dynamic dispatch VI to be recursive, or to use itself as part of its own definition. Recursive VIs can call themselves on their own block diagram, including the block diagram of subVIs. Recursion is useful if you want to operate many times on the output of the same process. You can configure a dynamic dispatch member VI to allow recursion by setting it to be reentrant and to share clones between instances.
Complete the following steps to configure a VI for recursion.
- Open or create a dynamic dispatch member VI.
Make the VI reentrant.
Select File»VI Properties to display the VI Properties dialog box.
Select Execution from the Category pull-down menu to display the Execution Properties page.
Place a checkmark in the Reentrant execution checkbox and select Share clones between instances.
Develop the member VI to complete a recursive operation.
Note: Not accounting for infinite recursion causes unnecessary memory usage and might crash LabVIEW. To avoid infinite recursion, consider calling the recursive VI in a Case structure.