LabVIEW
Proper architecture for LabVIEW Project
Have a really good idea of what you want to accomplish. Break it down into steps. Each step will be a subVI. If you're really thorough, maybe you have subparagraphs for each step. Those can be "sub-subVIs". This make figuring out where you went wrong so much easier, as you know the function of each subVI and can zero in on the issue right away. Especially since the error call chain will tell you exactly what subVI it occurred in. (If you have one massive VI, the call chain is meaningless because it just names your superVI and the error could be anywhere inside of it.)
@Kyle97330 wrote:
Well, one good metric specific to LabVIEW is that if you create a VI which has a block diagram that doesn't fit on your screen, you need to add some subVIs (or in some other way reorganize it) to make it fit on your screen.
For programming in general, anytime you find yourself repeating code you should make it into a separate function (or in LabVIEW's case, a subVI) so look for that as well, of course.
I think that, between what you and I said, your first paragraph issue generally takes care of itself. 🙂
@Ben wrote:
@Bob_Schor wrote:
... I then structure the Project so that its Virtual Folder structure mimics this physical folder Tree.
I take a different approach where I use Libraries instead of virtual folders. The libraries are in their own folder under the folder for the project and top-level VI. So the files/folder structure is sorta flat while the libraries inside the project have structure that mimics that hierarchy of the project. I do use virtual folders inside of libraries to hold the API, Public, Private, and controls.
Keeping the files/and folders on disk rather flat was recommended by AQ some years ago to make it easier for LV to find LVOOP classes. It also avoids an issue with Windows not liking to have a path with more than 255 characters.
The structure inside the projects does not have that limitation so the structure is created there.
I will also use multiple projects for an application when I have Re-Use code. Those are treated just like VIs from VI.lib in that they appear only in the dependencies. If I find that I need to enhance something in the Re-Use collection, I open the project for that collection, make the changes, and then return to the top level project.
Using multiple projects keeps the top level project lean and clean and free of the clutter of the support functions.
But that is just my 2 cents...
Ben
Edit:
Since I mentioned Libraries I should share this blog article I wrote about exploiting libraries in LabVIEW. After all I wrote it help people out and what help would it be if nobody ever learned about it?
Convergent evolution led me to a solution very similar to Ben's solution. I might add that when I name a VI, I'll have a common "surname" that kind of links it to other related files (usually associated by virtual folder). This way, if you view it in Windows Explorer you have an idea about how they are grouped together - although IMHO, LabVIEW files should never be viewed outside of their respective projects unless no other choice is available.
