Showing results for 
Search instead for 
Did you mean: 

Community Nugget 5-Mar-2007

Type Definitions Let You See Your Application in a Different Way


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.


 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.


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


... 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. Smiley Mad ).

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


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.


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 .



* 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. Smiley Wink

** 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



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.


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.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 1 of 46
5 stars for contents and presentation. Really excellent work.

With regard to your Closing:
1) How you have used type def’s to your advantage?
Yes. And of course: The same way as your nugget proposes (But my CTLs do not have that pretty icons ...)

2) How you go about organizing your data structures?
As soon as a data type is required to be unique and shared -> I create a type def. 
If possible, the type def and the associated VIs reside in the same directory (to make code re-usage easier).

3) What features of type def’s have I omitted?
I especially prefer to use strict type defs in conjunction with UIs. As soon as an application has to present the exact same type of information to the user e.g. in different dialog boxes -> The user should see the exact same presentation of the data.  This is done easiest by using a strict type def.

Message 2 of 46
Very nice Ben! I have found that usage of strict type defs keeps the code development process much cleaner. Your nice exposition and great examples shows why. I think I will adopt more of encapsulating constants into documented sub-vis. That is a nice use of context help! Now if only I could efficiently generate nice icons! It is just the one thing that I hate to do and put off.

Back to type defs. In a project I am currently working on, I have all sorts of instrument information that I want to display to the user. This is in a heirarchy of strict type deffed nested clusters. One of these items is an array of clusters describing data from an instrument. This is strict type deffed as well. And your nice expostition here made me go back and read the difference between type defs and strict type defs. This solves the UI problem I was having previously.

It might be nice if you could specify for each *connection* to a type def if that connection is strict or regular. In this case, I generally want a strict type def, but in one instance I want programmatic control over displayed array length so it has to be a regular type def. This means all connections to the type def have to be non-strict.


LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 3 of 46
Nice Nugget Ben,

I use type Def alot and it is very cool very munch with Enum and Cluster,Ben I saw your code and looks very munch like functional Global (LV2 Global)is that what you call Action Engine???
What is Action Engine??? another Desing Architecture???
Ben I can wait to read your nugget on Action Engine......

Thanks for  the Nugget.

Certified LabVIEW Architect
Certified TestStand Architect
0 Kudos
Message 4 of 46
Thank you all,
I noticed that I did not post a link to the help on creating controls, Indiactors and Type Definitions. Here it is.
It was either Jim Kring or Michael Avaliotis that said an "Icon is worth every second it takes to create it. Not every minute." Short and sweet techniques get us a long way.
Guenter wrote :"As soon as a data type is required to be unique and shared -> I create a type def. "
To you and others,
When does that happen in the product life cycle? I am wondering this out loud because the design of the data structures never seems to be mentioned. This strikes me as odd in a data flow paradigm language. Your thoughts?
Scott wrote;
... This solves the UI problem I was having previously.

It might be nice if you could specify for each *connection* to a type def if that connection is strict or regular. In this case, I generally want a strict type def, but in one instance I want programmatic control over displayed array length so it has to be a regular type def. This means all connections to the type def have to be non-strict.
What was the "Ui problem" you were having that was fixed, and
I'm behind you on the request to be able to specify the strict linkage!
Albert Geven and I are in the intitial phases of developing a Nugget on action engines. Action Engines are "LV2 Gobals on steroids".
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 46
Ben: My UI problem was a little involved and I started to write it up and decided it was too obscure. I then went back to looking at the difference in strict and non-strict and it hit me that I could sort of solve things that way.

In my case I am configuring a list of instruments. The instruments pop up in a sub-panel and show some standard info. That info is stored in an array of strict-type def cluster nested in a strict type def cluster. This whole thing is an array for all my instruments. As I change configuration of the instrument, I want to change the number of rows of the array of info displayed. BUT as a strict type def cluster I cannot write to the property number of rows. I simply disconnected it from the type def and would remind myself to update it manually. Admittedly a less than ideal solution.

In this case, I can make the inner cluster a strict type def, then the array becomes a regular type def, and then have the whole thing as a strict type def cluster. The key is breaking out a single extra level of type def of the array as a non-strict type def.

Actually inside the top level cluster there are strict type defs for private and public information about the instrument to keep things straight.

And making the type of connection dependent on the instance of the type def not the definition seems very logical since you may want the same type def to be strict for many cases where it is displayed and non-strict in instances when you just care about the actual data types.

Great Nugget.


LabVIEW ChampionLabVIEW Channel Wires

Message 6 of 46
Hello Ben.

To my opinion the idea of a type def is not linked to the specific design of any data structure.

In LabVIEW, we can easily take advantage of clusters by avoiding lots of wires on the block diagram. Making the cluster at the same time a type def is typically a good idea (and probably the most frequent use of type defs).
This results in good style, easy maintenance, ...

Consider another scenario where you need to handle a large amount of numeric data. As computer memory always concerns when dealing with large amounts of data starting an design or implementaion by using the data type SGL (4 byte only) is a good approach. Facing later the situation that the SGL wasn't a good decision e.g. when better accuracy of the data is demanded (and the data type is now used in tens or hundreds or ... of VIs): Hopefully the SGL is a type def and the job of updating the data type (and thus the entire VI hierarchy) to a DBL will only take seconds.
Again: Good style, easy maintenance, ...

Therefore, the data structure is not the matter No1. It is the application's object model that drives (or let me say: should drive) the designer to identify those and implement them as type defs.

Special thanks for your feedback on my icons. We have had a discussion in my company a couple of days ago and some colleagues complained about my black&white icons usually containing some text in it. I will take the next step and create satisfying icons.

And to the forum: I am looking forward to your comments.
Have a great and successful day, Guenter
Message 7 of 46

Woow Ben,

That's one colossal post Smiley Very Happy

And a great one too! Smiley Wink



Message 8 of 46
I also use Typedefs frequently in any program involving a UI.

I also use the cluster type def approach.  This allows me to be lazy when working with a state diagram because I can simply add the data to my structure as it's needed.  Of course this always leads to at least one revision where the data structure is streamlined, but I find the ability to change the cluster contents on-the-fly a great help in getting started.  Of course, throurough planning before jumping in head first would solve the problem too, but in my work at the moment, a quick response of "working" code (always a relative term) is most important.

In addition, I tend to use typedefs for more mundane things such as choosing ebtween a VISA Instr class and VISA serial class.  I have a collection of old VIs which I need to keep which are really mixed up with regards to whether they run as VISA:Instr or VISA:Serial.  I just typedef the VISA control and then I can change over if I need to without batting an eyelid.

Typedefs are really good when code is in a constant state of change.  Updating X Vis without Typedefs is a major pain.  With Typedefs, it's almost too easy (See "Lazy" remark earlier.....)

Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 9 of 46
My recent project involving TypeDefs and 'constant' VIs is about XML creation:

Where the red 'dot' is a formatter constant with the following content:


By using a enum for the XML-tag I can avoid mistypes since XML is case sensitive Smiley Mad
Using 1$s allows me to reuse the first input twice

And if I need to change the tag-creation I can edit my constant VI.


Message Edited by TonP on 03-05-2007 09:13 AM

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 10 of 46