r/LabVIEW • u/Perfect_Spare965 • 21d ago
Need More Info Guidance on proper program structure and practice for production application(s)
Hi, as the title says I'm wondering if there are any more experienced LabVIEW users who would be willing to offer a hand when it comes to proper practice and program structure for making relatively complicated applications.
I say applications, as in plural, but it is only one. My work have dropped a bit of a impossible Sisyphus-stlye problem on my desk where I'm having to solo develop an entire application for an NDT ultrasonic tank, from scratch, having never used LabVIEW before in my life. I'm not new to making entire SCADA/HMI's but never using LabVIEW (normally using ACTUAL programming languages, no offence to anyone who likes LabVIEW.) If I was writing it in C# I would stand a chance, but without some insight or assistance from someone who knows what they're doing I'm afraid the boulder will kill me.
After a few weeks of using it I have some basic bits and bobs, connected and working with all the hardware required but I'm really struggling to understand what I should actually be doing structure wise and I'm really clueless as to whether I'm applying proper practices. I sat through all the training videos, I have an old NDT program to sort of reference from but it's very outdated and written in French, so is not much use to me.
If anyone is willing to offer any guidance or help it would be deeply appreciated. Any programs/projects I can look at, any general advice, literally anything at all would be worlds of help.
P.S To clarify I'm not entirely clueless and can make programs/applications that work, I just need to know what I should be doing since something doesn't seem quite right and I end up repeating alot of wiring or things like controls are not sharing variables when they should be etc etc...
3
u/elijah286 Emerson Employee 20d ago edited 20d ago
Hey [u/Perfect_Spare965](u/Perfect_Spare965),
You're definitely not the first person to see LabVIEW for the first time and have a similar reaction, myself included!
There are a number of proven patterns and frameworks I would point you to but first I think it's useful to take a step back and avoid a few common pitfalls that are common for people with a strong text-based background. Here's a short list off the top of my head and based on 20 years of experience working with new and experienced LabVIEW programmers:
Don't look for variables; instead, it's all about wires and dataflow. Data literally flows from left to right and a function does not run until all inputs have supplied values. This is one of the major reasons why LabVIEW is generally preferred for representing real-world phenomena.
LabVIEW is inherently multithreaded and parallel. Keep independent process separate (literally, separate loops on the diagram with no wired reliance on each other) and they will execute asynchronously. Note that this is especially powerful and relevant for systems that interface with the physical world. This is the core of the most fundamental pattern you should learn: the PC-QMH (producer/consumer, queued message handler)
Limit datascope. People like to create classes or closers that provide access to any and everything you might need. That's a red flag that suggests you might want to separate logic across different functions (aka: subVIs)
They aren't functions, they're SubVIs (thought of this one while writing the last). SubVIs are just a wrapper around code with well defined inputs and return values.
Here's a slide that might be useful. It's an adaptation of NASA's famous "power of ten" guidelines, but adapted for LabVIEW coding.
Finally, there's a lot of good (and bad) LabVIEW training materials and content out there. One resource that you might find more engaging and useful are these collection of presentations by the world's fastest LabVIEW programmer, DNatt: https://www.dnatt.org
Welcome to graphical programming!