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.
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.
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.
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.
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)!
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) baulk 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.
An action engine is my term for a functional global which includes extra actions other than just holding the data. I was originally exposed to the term “Action Engine” by reading the book “LabVIEW Applications Development A Course on Advanced LabVIEW Programming Techniques.*” But before I get into details of the Action Engine (AE), I would like to clarify some terminology.