LabVIEW
"there is not enough memory to load this vi"
@Susanne1709 wrote:
I understand, thanks!
That means a lot of work (I like) but don't have the knowledge to do this. Also I don't have time to try...
While Gerd's suggestion about reorganizing your VI makes a lot of sense, you're right - the task is daunting, especially for a LabVIEW novice - because this has all kinds of potential to change the way the VI operates. I would suggest instead that modularizing the code into "sensible" subVIs - that is, subVIs that are organized by function, not merely to save space on the block diagram - makes the code more understandable because your client can get a bird's eye view of how the whole thing operates and then zoom in on whatever they feel they need to know in more detail. This is assuming that you document your subVIs reasonable well - which includes a description so they can use the context help to see what each subVI does.
This is actually a version of what Gerd mentioned, but this is simpler and with less risk. You can start by selecting sections of code that belong together and select Edit --> Create SubVI. This is a fairly low risk way to organize your code after the fact, because usually you aren't changing the way the code executes - but there are some important caveats to that statement (but I think LabVIEW is pretty good about letting you know if creating a subVI will change the way the code functions). (But in the next project, I'd do it the other way 'round - that is, build the subVI first then drop it into the main VI.) If you want to make it really easy to follow, you would have one subVI for every major paragraph of your requirements doc, and then do the same inside that subVI for each subparagraph if it's a really complicated requirement. If you use the bookmarking feature, they can even go right to the very spot (or spots) where the requirement is satisfied so they can confirm that the requirement is indeed satisfied.
Having one big VI with wires running backwards and all over the place is akin to having C++ code with no functions and random indents.
Now if the VI was organized as Gerd mentioned, it would have naturally been organized somwehat like I had already described. The two suggestions combined would make for a very well organized, easily understood and easily debugged solution. The "easily debugged" feature isn't obvious, but if an error does happen, you'll get a better idea of where it happened. "Error xyz occured in Read Voltage from DMM.vi" is a lot more friendly than "Error xyz occured in Main.vi".
