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)!
NIWeek offers amazing opportunities. It is easy to think “I already use LabVIEW and NI Hardware, so why should I go to a trade show?” But, taking the trip to Austin is always worth it. There is a completely different level of learning available, on brand new products as well as improved hardware and software techniques. The show goes beyond LabVIEW training classes, or the technical information available online, and gives you real world examples of how users like you are using NI tools to make themselves more efficient at their jobs.
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.
The rhetorical statement seems to be what most system integrators feel is true. After all, if they remain the only ones able to understand the system or use the code, then customers will always have to go back to them, right?
G-Wizdom is a blog, resource (and an outlet) to automation engineering professionals specializing in the art & science of Graphical System Design. This blog was created and is maintained by engineers, for engineers. We commit to keep this blog simple, with a dedicated focus on entertaining, serving and empowering the people who automate our world.