From Friday, January 17th 11 PM CDT (January 18th 5 AM UTC) through Saturday, January 18th 11:30 AM CDT (January 18th 5:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Type Definitions Let You See Your Application in a Different Way
“THE ESSENCE OF TYPE DEFINITIONS IS THAT IF THE TYPE DEFINITION IS CHANGED ALL "MEMBERS" WILL CHANGE THE SAME WAY.” (Albert Geven LabVIEW Champion )
Type definitions are a wonderful yet under utilized feature of LabVIEW. They allow you to manage the data types of your application in controlled manner.
Type_Defs.png
In large applications they can save you hours of work. I have had the opportunity to work on large applications developed without type definitions. These opportunities are seldom quick and easy to change. I have found it to be well worth the time and effort (both of which were considerable) to introduce type definitions as the first step in modifying an existing application. If your application has more than one sub-VI, your application will probably benefit from the use of type definitions.
Type definitions (type def’s) are implemented in LabVIEW as custom controls. Type def’s allow you define the data types*** used by your application. Once a type def is defined and used on a front panel or block diagram, LabVIEW will ensure that all instances of that type def remain consistent with the definition. This means that if you edit a typed definition and save the changes, every place where that type def is used will be updated automatically. This is particularly useful in the case of enums when they are used to drive action engines**** or state machines.
Through the use of clusters, you can establish a hierarchy for your data if appropriate. As shown in Hierarchy1.png the hierarchy screen offers a button to control the visibility of type definitions used by your application. By using Type definitions consistently throughout an application a developer can easily determine which VI’s will be affected by a change to one of them.
Hierarchy1.png
In the case of the Demo shown above, we can see that the top level VI “Demo” needs to know about changes to the action provided by the sub-VI “Caller”. We also see that changes to the “Chan Name” (Channel Name) data type affect the definition of the “Chan Info” (Channel Information) type definition as well as the “Caller” but they do not affect the top level VI “Demo”.
We can determine all of the above without ever opening up the diagrams of any of the VI’s or type definitions. This is made more descriptive by editing the icons of the type definitions. The process is quick and easy.
You start by opening the control editor
Customize.PNG
... and choosing “type def” before saving the control as a unique name.
You can then open the default icon and select most of the default icon’s image
Select existing image.PNG
And slide it down to the left.
Slide down n left.PNG
Which gives me plenty of room to add text.
Structure Name.png
Since the icons retain the native LabVIEW look it is clear which objects on the hierarchy screen are type definitions. I have for the largest applications taken the time to add graphic that represent the data defined by the type def. This becomes very helpful to pick out the data type you are after from hundreds of VI on the screen.
View Data Hierarchy.png
In the application hierarchy screen snippet above I have illustrated how type definitions are very helpful when investigating how a possible type definition change can affect an application. The VI hierarchy screen, when used with type def’s becomes a “data definition hierarchy screen”. Looking at all of the VI in a type def’s hierarchy tells you which high level functions could be affected by changes. The callers tell you the VI’s that need special attention and will adapt to changes in the typed definition. In the case above, we can see (well I can because I can do a little scrolling) that of the 700+ VI used by the application, there are only 10 that use the definition (I shudder at the thought of trying to do this same analysis without type def’s. 
).
To get the hierarchy snippet I presented above I located** a top-level type def. By “top Level type def” I mean a type def that is not a member of any other type def. Once I located the icon for Equipment Group type def, I was able to right-click and choose Show VI Hierarchy
Show VI Hierachy.PNG
Followed by a right-click Highlight connections
Highlight Connections.PNG
Summary
Type definitions allow data structures to be defined and maintained across an application. Enums and clusters use benefit from being used as type def’s. The VI Hierarchy screen includes the option to view or omit type definitons. Consistent icon usage for type def’s makes it easier to find them in large applications. The hierarchy of type def’s define data dependencies.
Closing
I hope the above observations on type definition creation, use, and their power to be useful. I’d also love to hear about
1) How you have used type def’s to your advantage?
2) How you go about organizing your data structures?
3) What features of type def’s have I omitted?
If you have a Nugget you would like to present please post here to reserve your week!
A list of all Nuggets can be found here .
Ben
Notes
* Warning: changes to application containing hundreds of VI and were not developed using type def’s should be left to professionals. This kind of work has lot in common trying to remodel a house of cards. Every move must be done with great care and you should be not surprised if the entire enterprise comes crashing to the floor. In short, do NOT try this trick at home. 
** You will find that if you use type definition s in your applications they will end up decorating the bottom edges of your hierarchy.
*** Type def’s define the data type and not the default values. You cannot use type def’s to establish default values. If you modify a type def that is used as constant on a diagram, all instances of that type def will be replaced with new instances. Default values that were saved in the block diagram will be lost when the constant is replaced with the new definition. This is by design. The method I suggest for establishing a default value is to use a sub-VI to explicitly define the value. In the case of clusters use a bundle by name node to set the fields as required. In the attached 7.1 example you will find
Type_defd_Constants
Where I have illustrate the use of sub-VI’s to establish default values. In the example, there are two sets of default values of the type definition “Chan Info” (Channel Information) denoted by the green and grayed-out icons.
Documented_Constants
The sub-VI documentation also helps future developers of the application pick-out the proper default settings.
**** The attached example includes a simple example of an action engine. Stay tuned for a future Nugget where we may discuss action engines.
