Hi Kochise,
Let me first appologize for what you have been given and the impresion that a "certified..." aftually is capable of developing well structured easy to maintain code.
You have been mislead.
I am not allowed to let you see the code we develop so I am limited in the extent of my assistance.
I too came from "another" programming language. It took me time to get a handle on the difference between LV and C and macro etc. I would like to encourage you to wok at the paradigm shift needed to make the jump.
Programming in LV is a lot like riding a surf board. When surfing we do not think about the dynamics of the water etc. but have to think abou tthe "Big Picture" like what wave is coming how to get into the curl etc. If we were thinking about the low-level stuff, we would be wipping out.
LV presents an interface that is wonderful at expressing thoughts and intension in a single image. If we try to make that image too complex by introducing low-level details it can be "hard to tell the forest from the trees". SO I urge my fellow developers to keep their digarms structured such that it relates simple straight froward ideas. The low level details are abstracted away using sub-VIs that encapsulate related concepts.
So since I can not post an image I will try to paint with words.
Top level "MAIN" VIs are typically composed of the applications components. If you look at the main diagrams we often find a bunch of sub-VIs that all run side by side. The purpose of each sub-VI are communicated via the icon and the help included for each. THe details vary from application to application but a typical Main may have;
Configuration
DAQ
Reporting
So if some poor sole has to dig into my code and fix an issue with how the configuration functinality works, they can make an educated guess.
When they drill down into one of those sub-VI they find code that is related to the function they handle. Depending on the complexity, they may find addional layers where the sub-functionality is handled.
LV introduced "multithreading" very early since the "Data Flow Paradigm" naturally adpst well to multithreading. With multi-threading LV is a natural for multiple interacting parts. "Active Objects" as it is described in OOP.
Multithreading works when components are able to safely inteact with each other. LV has a lot of options that serve a variety of interaction types. Queues, Notifiers, Events, Functional globals,... each have their own use and are great once we know how each operate. They all work in a multithreaded environment safely when used properly. There is no need to create mutexes to protect resources. LV abstracts those away so we can focus on the big questions.
A technically challenging part of realizing multithreded applications rears its ugle head when we turn our attention to GUIs since ther may be only one. LV addresse this best using a "User Interface Thread" which is single threaded. THis prevents issues with two components attempting to change the same GUI element at the same time. While solving the problem of multiples fighting, it introduces a situation that has to be understood and recognized.
THe best wasy that I have found to handle the bottleneck of the GUI is to recognize the GUI as a way to get information from a human operator and update that user. It is not a place to store data. There are better place to store data.
So to further attemp to help you, I would suggest you stop looking at that code you were given and trying to figure out how to nudge and coax it into a "more manable state" and rather start with a fresh white board and break down your applcaiton on a high level. Don't get down in the weeds, with too many details, let the while board limit you on how you render the application its components and their interactions.
THEN
Go to a new VI and create VIs that mirror your while board design.
I have been posting to this forum long enough to know that I may not be able to persuade you with a simple post and a big pile of words. I hope that this short diatribe is helpful to someone.
Trying to help,
Ben
