LabVIEW
Clean up block diagram using SubVIs
Solved!
Hi guys and welcome to my first post!
I´m kinda new to labview, so please be a bit patient if i dont understand everything right away 
Im working on an existing program which is used to control a MCU over BabyLin on my front panel, while i have a visualization to see the live changes of the system. The program is working fine so far, however i´m trying to clean up the block diagram. This should be realised by subvis, right? I´ve read a lot about the block diagram size shouldnt expand my screen. Well, im at a size of approx. 3x2 screens ( 24" !!) after trying to use subvis and shorten all distances between structures. The only things remaining are huge amounts of local variables and references ( they were already existing before i got to know the program ) , mostly for the visualization. If i create a subvi out of a part containing locals, it will change them to references which doesnt make the program more readable ( and smaller ), and i guess i cant put a new subvi over the references + subvi.
Do you have any ideas what to do? I hope i didnt forget anything, otherwise feel free to ask.
Kind regards,
Leo
@Bob_Schor wrote:
To get a handle on the structure for your Top Level code, write down (as though you were telling your Boss, or telling your Wife -- who knows, they might be the same Person!) what you are trying to do. Keep it fairly general. Did you specify a number of steps? Then maybe the Top Level should be a State Machine, or a Queued Message Handler. Did you describe something that runs at a constant speed, generating data that you have to handle "on the fly"? Maybe it is a Producer/Consumer Design.
Do you have a lot of initialization? Put it in a sub-VI, bring the 20 wires out in a bundle (that's "Boss-Speak" for a Cluster). Your main program should have a few loops, with values that persist (possibly changing) during the program running in Shift Registers near the top of the loop, with Arrays and Clusters used to keep related items "consolidated".
Don't be too embarrassed by the size of your routine -- I recently downloaded a 50-monitor Monster from the Forums (I didn't even try to figure it out), so 6 monitors is nothing!
Let "encapsulate function" and "hide the details" be your guide in thinking about creating sub-VIs.
Bob Schor
To expand on Bob's analogy, each talking point can be a SubVI. In other words, group related code into subVIs. The advantage of this is that it's much easier to troubleshoot because all errors will be localized to a subVI. No more chasing errors around the block diagram. I guess you can use your current VI as an example of what NOT to do on the block diagram. 😉
@mikeporter wrote:
Take little steps. Cleaning up bad code is am iterative process. Don't go crashing through the code, like Sherman marching through Georgia...
Mike...
That's sound advice. Messy code is often poorly written in other ways, too, and even a simple refactoring that would be harmless with well-written code may cause code to fail in subtle ways as the races in different race conditions start being won by different participants than had been the case in the past.
@mikeporter wrote:
One of the things you will be doing during the refactoring is learning how the code works -- which is often very different from how it is supposed to work, and even different from how the original developer thinks it works.
Race conditions can be a huge problem, as well as logical errors that cancel each other out.
Oh, yes. Use bookmarks to annotate thing you know are wrong but don't have time to fix right now.
Mike...
A word of caution before making changes to how the code works. Unless the object was to actually fix the code in that area, it's a good idea to ask permission or at least let someone know of your intentions before doing so. If this is test software, for instance, units that used to pass before may fail now, and vice versa, quite possibly leading to discrepancies between your company's test results and the customer's. Above all, unless the object was to fix a problem, the software should work as it did before - whether or not it was working as intended!
