How I learned LabVIEW
About LabVIEW
In short: Tech industry's most successful graphical programming language and IDE you have never even heard of.
Yes, we are talking nothing short of the underpinnings of projects like LHC and Hyperloop here. Sure enough, it's a widely used — albeit proprietary — engineering tool for test, measurement, and automation and that's where it has its focus area.
Fun fact: LabVIEW was never even shown to me while in college when it was already established in the industry for over 15 years and until recently I had the opportunity to teach LabVIEW NXG to mechatronics students at my alma mater just to get my feet wet with the next generation of LabVIEW.
About me
I'm a software-engineer and solopreneur serving R&D labs in automotive, manufacturers in environmental tech as well as various startups and hidden-champions around Stuttgart, aka Benztown, with development and engineering services specialized around the National Instruments LabVIEW development environment. My core work activities take place right where hardware and software collide.
There is quite a chasm between what a scientist or engineer with vs. without software background can accomplish with LabVIEW — that's where I come in to offer development, best-practices and code-reviews, and help prevent engineers, scientists, and students from getting stuck in unmaintainable projects.
Why I wanted to learn LabVIEW
Well, how do you develop the desire to learn a language you've never even heard about!?
Actually, I started my freelance career developing a J2ME app for public transit timetables back in the days when everyone would still freak when their phone would go online and rack up mobile data fees. To support that venture, I would also work at a small hardware company's manufacturing department building and soldering devices. I noticed that their software guy would scroll away miles in strange diagrams all day, cursing all the while at "scheiß LabVIEW." Eventually, that guy left the company as well as a pile of software rubble and management approached me if I wanted to pick it up as nobody else in the company had really fallen in love with LabVIEW (left brainers are they!).
LabVIEW immediately appealed to me for several reasons. Its graphical nature really does lend itself to a strong right-brainer — still its UI/UX really did need an overhaul, which resulted in recently released LabVIEW NXG.
LabVIEW projects always go hand in hand with hardware or a test-stand that needs to be ordered and built and therefore development cycles are slower than in pure software projects.
It is also the only programming language and IDE I know of that will allow for multiprocessing/multithreaded programming out of the box (just pop another While-loop) as well as handling distributed and realtime systems along with coding FPGAs (talk about full-stack). It offers a plethora of drivers and libraries for any kind of lab instrument, it compiles to native machine code, and you can decently build and distribute executables on Windows along with a free runtime environment.
How I approached learning LabVIEW
My software-engineering background quickly helped me realize that my predecessor's left over projects had evolved over years in sheer absence of even the most basic design patterns and programming style — not to mention any kind of architecture. They were just one big blob of code sprinkled with global vars and workarounds in a while-loop that would take up to five seconds to finish a cycle.
Searching online, I realized that there were various levels of certification to assess your proficiency — with the CLAD covering syntactical basics. Doing the prep questions quickly helped me fill in LabVIEW's specialties and gaps that hadn't previously crossed my path in other programming languages.
For anyone new to software development, taking the Core 1&2 courses in a classroom setting will be similar to drinking from the firehose and thus, won't be very effective. When your company is on a regular support contract with NI you can call in and ask anything you like. You can also access valuable online training materials that include and go beyond the foundations of Core 1&2 and study them in your own timing.
Last, but not least, here's the one book that helped me through my early LabVIEW days: Peter A. Blume's LabVIEW Style Book. Even after all those years, I can honestly say it still is well suited to introduce proper development practices to those new to programming.
Challenges I faced
Although LabVIEW comes with pre-loaded project templates featuring various architectures, lacking experience, you'll probably be shy to turn your legacy monster-while-loop project into a Queued Message Handler or even a Simple State Machine as you can't estimate their potential vs. inherent limitations.
So even after studying hard on CLAD prep questions, webcasts, and tutorials, it takes months to wrap your head around essential LabVIEW patterns, concepts, and architectures. For me, that meant to sit down with my stakeholders and discuss a strategy to get those legacy projects unstuck. Eventually, we had an NI field engineer come on site for a day and do a code-review that would second my impressions: The old code was not maintainable and any change could lead to breaking some other feature. He set up a Producer-Consumer project template for me, introduced me to Functional Global Variables, and from then on I went to fully rewrite an eight year old project within a few weeks.
Key takeaways
As a freelance LabVIEW specialist, I regularly get to see projects lacking even the most basic architecture or software-engineering — no matter if it's a start-up or a global player — jeopardizing maintainability of code along with extensibility. Scalability anyone?!
I'm convinced, however, that as a scientist or electrical engineer you and your team don't need to become certified to greatly benefit from LabVIEW's graphical programming paradigm. Once properly established in your toolchest LabVIEW will add significant degrees of freedom to your research and with minimal training you'll be able to code various customizations on your own, without having to call a consultant every time.
The only thing that will put you off as a small shop are the licensing and support fees that will run in the thousands per year depending on the LabVIEW package and modules. As long as you let your team build and maintain basic LabVIEW skills, and have someone experienced in LabVIEW around for code-reviews and guidance, it is an absolute winner and will give you results and a competitive edge in no time.
Tips and advice
As a student applying for an internship with an emphasis on LabVIEW coding, make sure they have proficient if not certified people already on board and available for guidance and code-reviews. Otherwise, you'll waste your time poking around in your superiors' stale code without picking up any interesting coding skills. Sound familiar anyone?!
Even bad LabVIEW code somehow magically "works," and that reduction to "works" is regularly confused for a measure of quality by stakeholders — which is easily explained when your stakeholder is the person who let the code go spaghetti over many years in the first place.
If the LabVIEW version on the development PC is older than 2016 and no one in the department or team can tell you what architecture pattern or template the project is based on, do yourself a favor and find a mentor to take a look or do a code-review (NDA permitting).
You could also run VI-Analyzer, but without fine-tuning the results will probably yield quite a bit of noise aside from the blatant faults like oversized diagrams or wiggled wires running backwards.
For a green field project, choose a proper project template like JKI's string-based state machine, and regularly refactor your code to maintain VIs below screen size and keep them tidy and readable.
At ni.com, you'll find webcasts, whitepapers, and tutorials spanning a wide range of topics well worth the registration, and, last but not least, LabVIEW comes pre-loaded with hundreds of examples accessible right from the IDE which are officially up for grabs to use in your own projects.
Now it's up to you to "Make it run. Make it right. Make it fast." and always remember: "Friends don't let friends code unmentored!"
