The vast majority of LabVIEW applications, particularly in the broad test and measurement market, start with hardware configuration. Whether it’s installing the software components in the wrong order, default device name errors, or device discovery—the initial process of configuring the hardware is often an intrusive and unnecessary barrier to starting the application.
Among the many market research studies, focus groups, and customer feedback engagements that our group drives, strong hardware integration continues to be one of the top two benefits to LabVIEW users (along with the productivity of graphical programming). I can talk—or I guess write—for days about the benefit of our driver APIs, consistency in programming paradigms across hardware families, and the sheer number of devices that LabVIEW can communicate with, but I’d rather focus on where we can improve.
One of the aspects of my role in Product Marketing that I immensely enjoy is teaching our sales engineers how to demo LabVIEW. Every one of these engineers are experts in the product and can teach it all day long with their eyes closed, but demoing a product is a completely different skill than knowing it or even teaching it. It’s maddening to see how many of these demos actually start by opening Measurement and Automation Explorer. Gasp! As great as LabVIEW is at hardware integration, it’s actually quite lacking in the system configuration aspect of system design, so let’s focus there.
There are three key areas of system design where we’re innovating:
Initial Device Discovery
Some of the most consistent feedback I hear on LabVIEW typically sounds something like “I have to write code to do anything.” Even miniscule tasks, such as verifying a hardware target is discovered, require wires to be connected and the run button pressed. My response to this feedback initially was a nice, professional way of saying “Duh, it’s a programming language.” But, let’s be disciplined about separating how you accomplish a task in G and how you accomplish a task in LabVIEW. For a software that carries the torch for “world-class hardware integration,” you should expect to discover your connected devices without writing code. Sure, doing so in G requires coding, but the LabVIEW environment should empower this simple task.
Real-Time Feedback on Signal Connectivity
Human physiology is an amazing, beautiful thing. Our brain actually chemically rewards us with dopamine—a hormone that improves our cognitive ability—for things like being right, completing a task, or working out. This is one of the fundamental reasons that engineers derive emotional satisfaction from LabVIEW. Since LabVIEW is constantly compiling code, instead of a large explicit compile step at the end, you’re continually getting these dopamine hits while you’re building out the individual components of your VI.
We should be driving this instant gratification within the configuration of hardware. Beyond just knowing the hardware is connected and recognized, you
should also be able to validate its intended functionality quickly and easily—and without that pesky requirement of writing code.
To the right is a snippet of a screenshot from a super-secret prototype version of LabVIEW. This shows some of the concepts we’re driving towards, like integrating some “liveness” into the environment. What you see is a view within the environment itself confirming the signal input with a preview visualization.
Particularly for a graphical environment housing a graphical language, we can surely find a better way than a vertically organized tree to manage and display hardware. Imagine the world where you plug in a device (left) and open the software to see a physical representation that reinforces not only what the hardware looks like, but visualizes the connectivity and functional organization of the device (right).
This level of integration is made possible by NI’s platform approach, and the natural synergy that exists between our hardware and software. From plug-in hardware to deployed modular platforms, this level of insight and visualization would drastically simplify system visualization and configuration.
Now, if only this could display the next level of connections for sensors or DUTs.
Today’s Featured Author
Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at @TheLabVIEWLion.