It is true that some applications can be developed using LabVIEW without training. National Instruments has provided features that help you assemble the most common functions that their hardware is intended to perform. The phrase “Acquire, Analyze, Present” is often used to summarize those operations. The built-in functionality covers many typical use cases for NI hardware.
I have seen many project opportunities that were “lost” due to the customer choosing the lowest bid without taking into consideration the costs involved to maintain the application or the skill level of the developer. I used quotes on the word “lost” because we often see these types of projects make their way back to DSA in order to fix the problems the original “lowest bid” developer could not solve.
Figure 1 Many applications require communications across multiple platforms.
This Nugget discusses a classic method that is seldom mentioned.
Two of the powerful features of an AE are that they provide both encapsulation and protection for the data stored in them. These features are not limited to a single application instance or a single machine. Utilizing a seldom used feature of LabVIEW (LV) your AE’s can expose the functionality of one or more AE’s to other applications or other machines with limited effort on the part of the developer. This approach will be shown in an application where I harnessed these strengths to deliver a multi-node application. I will first outline the challenge and then walk through the implementation.
I often find myself having to define cluster type def’s for use by sub-VI’s. On large clusters, the defining can be cumbersome because LabVIEW wants to add a number to controls that you control copy. The smart way to approach this is to control-copy the controls from the original GUI, and drop them directly into the cluster container. Since it is inside the cluster, LabVIEW does not change the name.
LabVIEW is an impressive development environment that caters to the novice, the expert, and those that fall somewhere in between. But that does not mean that novices are going to be able to develop expert applications using LabVIEW. Continue Reading →
Some people (like Guru) balk at certifications. They act as if they are meaningless wall decorations, or a ploy to get a promotion. The fact is certifications are a great way to quickly demonstrate skills that cannot be readily seen.
My first introduction to LabVIEW was from an early adopter of the graphical language in the condensed matter physics lab at the University of Pittsburgh. This person had taught himself LabVIEW, and insisted that those who worked for him gain first-hand experience in using a graphical language to increase productivity.
Believe it or not, there are many people, as well as companies, that would argue whether best practices are beneficial or should even be followed. While I can respect other points-of-view on the subject, in my opinion following certified best practices needs to be the foundation of any processes and procedures.
Queued State Machine, Queued Message handler, Master/Slave, Producer Consumer, Channeled State Machine … (the list goes on) are design patterns often used to develop applications in LabVIEW. They each have their own features and no single design pattern is correct for every situation and application. Choosing the appropriate design pattern or creating a customized variation is key to developing a robust application that will meet the requirements and grow as the application grows over the years.
Have you ever viewed a LabVIEW VI Hierarchy and become frustrated with not being able to locate a VI you needed to open?
Do you have large applications composed of similar modules but fear jumping, with both feet, into the learning curve of LVOOP?
Did you ever try to duplicate a sub-VI at the start of a new set of functions and find yourself deep in a nest of cross-linked VIs, or save a VI only to realize that the most suitable name has already been used?
Then using LabVIEW Libraries may be useful to you (see Figure 1)!