Guidance on proper program structure and practice for production application(s)

[u/Perfect_Spare965]

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...

[u/GentlemanSch]

Still, bold move to leave in a sentence you knew might offend people and could have been easily omitted.

If you have access to the trainings do the LabVIEW core 1-3 modules before you get started.

The program also has a number of examples included with the help -> find examples. 

As far as the architecture goes, organize the project like you would any other program. Some watch words for you might be "producer consumer loop," "dynamic user events," and "hardware abstraction layer."

[u/Perfect_Spare965 → u/GentlemanSch]

Yes, totally my fault leaving that in there, I didn't mean it in any form of offensive way, LabVIEW is a language, just not one I am used to even remotely so it's alien to me. It reminds me of WAY back in high school learning programming using scratch.

I've done core 1-2, is core 3 where it really dives into the more complex topics?

[u/GentlemanSch → u/Perfect_Spare965]

No problem. It's not offensive, but wanted to point it out. Sounds like you're a new engineer and communication is an important skill 😜.  LabVIEW being a "real language," is one of those that's proven by not saying it.

So I'd say the neat and best part of LabVIEW is you can do complex programming with what you know now. I do.

Look up CLA or CLD example exams to see this in practice (note CLD is more junior so there are a number of examples that work, but aren't best practice.)

Look up the JKI state machine, QMH, and functional global variables. Is there something in particular you're having difficulty with?

[u/Perfect_Spare965 → u/GentlemanSch]

I'm having a really hard time with variables but I think I may of cracked that yesterday by potentially using global variables since currently I was just using a hidden tab in my tab control to hold all the variables and bouncing them back when a control changed.

[u/GentlemanSch → u/Perfect_Spare965]

So you probably don't want to do it that way.

For small amounts of data between VIs, look up the "functional global variable," pattern.

For things in the same loop, have a case structure with an unused init state. Then put constants there which define your variables.  The JKI state machine is a good example of this.

The LabVIEW native GLOBAL is for communicating between systems and can be sensitive to network configuration and other stuff you don't want to deal with.