The other day I ran into LabVIEW developer Phil Joffrain, one of my friends from my R&D days, and asked him to share some of his tips for serious LabVIEW development – we settled on three “random tips about under-utilitized development features” as the approach. Phil is a hardcore computer science major who has been working at NI for 7 years. He has worked on our LabVIEW SignalExpress project, which is a unique combination of a LabVIEW-built application running within a C/C++ application framework – so Phil is constantly switching contexts in terms of programming language – he is an expert programmer using LabVIEW for professional development.
Here are three tips for hardcore users – this may be something new for you to consider, or it may be old news.
1. Type Defs:
Large application constantly need to pass around bundles of information. Bundles of information obviously come in different types, but more importantly, the type of information can sometimes change either midway through development, or from release to release. An easy way to bundle information in LabVIEW is to use a Cluster. Clusters, for example, which contain a fixed number of items could in the future need to contain more or less items. But when a cluster being used by a large number of subVIs needs to update, it’s simply not feasible to open each and every subVI to update the cluster being passed in by hand (or by writing a tool to do it). Instead, turning that cluster into a Type-Def solves this problem since changes made to a type-def update all consumers automatically. It’s also important to note that there are 2 types of type-defs in LabVIEW: regular type-defs, and strict type-defs. The difference (as the name implies) is in the level is strictness and the frequency by which the type-def will update when changes are made to it. Strict type-defs contain the most information about its contents and force updates most frequently. Now type-defs are not simply a good idea for large clusters of data, they are also very useful for single item types. Imagine for example, an internal API where a set of subVIs take in a control reference. If this is a strict reference (meaning that extra information about that control is associated with that reference), making a change to the original control will change the strict reference type and break that input to all our subVIs. Having a strict type-def which simply contains that strict control reference means that only one place needs to be updated, to automatically propagate that change. When a number of subVIs take in the same type of input or produce the same type of output is when using type-defs makes sense.
2. User-Defined Events for the Event Structure
Most large applications have to process requests or provide the application with actions to perform. The LabVIEW event structure is an ideal tool to do this. The common use case for the event structure is often associated with processing control value changes on a User Interface, but this is only scratching the surface of the event structure’s usefulness. First of all, what makes the event structure such a useful tool, is that it doesn’t poll the UI for changes, nor does it steal the CPU waiting for things to happen. When no timeout is set on the event structure, it is happy to wait and wake up only when needed (unlike old-style state machines that comprise of a while loop and case structure). But the main feature of the event structure that is often overlooked is User-Defined events. A developer can create custom events that can be received by the event structure. This allows the developer to create a messaging system to process requests and define actions to be performed. The powerful thing about User-Defined events is that a developer gets to dictate what information gets sent to that event via the event’s internal terminals. A very simple example of this is: you can create an event called “save”, which has a path attribute. When the event gets called, the path attribute can be accessed using that events terminals, and the application can save its state at the path given. It is the caller of the event who would have gotten to specify what path to provide. Old and alternative ways of doing this was to use a LabVIEW Queue, who’s elements would either be a cluster of the data you wanted to pass around, or a variant so that anything could be passed. Both of these techniques have issues. One places a burden on the type of data that can be passed in the cluster, the other places the burden on the receiver of the data to extract it from the variant. The event structure removes both of these burdens by allowing each event type to have different data passed to them, and by giving direct access to that data within the event case via the internal terminals.
3. LabVIEW Classes
A relatively new feature to LabVIEW which is becoming mainstream very quickly is LabVIEW Classes. The fear with using a new feature is often the potential instability and performance hit, but a lot of time and effort has recently be put into LabVIEW Classes to make them more stable, faster and quickly becoming a mature feature of LabVIEW. The benefits of using LabVIEW Classes are the same as using any object-orientated programming approach to a large application; scalability and modularized components are among the top reasons. A lot of large applications today need an easy way to “plug in” new features, or new tools. When these new features or tools share common information and common abilities with the existing ones, having a base class with that information and ability that a new feature or tool can inherit from simplifies code greatly. A new plug-in no longer needs to start from scratch nor start by copying over half the code, it simply “plugs in”. Adding the extra functionality to that new feature or tool’s class is all that is left. In addition, new information and abilities added to the base class are automatically also available to the classes that inherit from it.
Posted by pasquarette 
Posted by pasquarette 
