Labview project organization and management

[falkpl]

I am looking for advice/resources for organizing and managing moderate to large applications in labview. I have created an application with over 100 vi's and want to ensure the easiest management and maintenance of the code for the future. Does anyone have opinions on vi libraries, folder use or other methods for keeping projects manageable as the size grows. Most of my past applications were less than half of this size so code control was easy and I could be more sloppy. I have kept good practice in regards to coding and reuse in labview but have not found many articles or software management for labview. I am looking to make the transition from the lab to more commercial products. I have 8 years of extensive self-taught labview experience (10+ years or general programming c/c++ ...) so I am familiar with coding techniques but have not seen too many software engineering and architecture techniques applied to thsi language. Any resources would be greatly appreciated.

-Paul

[falkpl]

Any Ideas?

[Lee Robertson]

Hello Paul,

My group is also developing/maintaining a very large application in LabVIEW (over 1000 VI's). We are using CVS which is not perfect but we are still holding together, just barely. As with most software projects it is code organization and architecture that keeps things manageable -- this is particularly true when using labVIEW. Our CVS repository is running on a linux server and we have both PC and MacOS users actively contributing to it.

[tst]

Try look at the thread floated to the top of the LV board.
Also, try looking at LAVA's large application board.
The development guidelines document also refers to this.
Ultimately, there is probably nothing better than sitting and learning from someone who has experience.

[LV_Pro]

We are the ones representing the "one with experience" for most of the new developers. As to organizing/structuring a project, I usually have created a directory for each of my projects, with sub-dirs based on major program functional blocks (i.e. User Interface, Initialization, Instruments, DAQ, etc.) containing the code specific to those functional blocks, usually with a sub-dir containing the type def'd controls for that function. Once I've passed a certain arbitray chosen point in the development process, which usually is determined by the complexity of the code to that point, I start making a copy of the master directory every morning, renaming it with a date code or to a newer version ltr/number than the previous day's and do my work in that, giving me a "revert" path. On some projects, at some customers, I have used SourceSafe, or other configuration management programs, but much of the time I am the only developer, so it isn't _as_ necessary. I have had mixed results with the various CM programs, they weren't developed to work with a graphical language like LabVIEW, so a lot of the tools won't work. There have been a few threads devoted to the problems and solutions that others have implemented in multideveloper environments, so a search should turn up some info. The biggest CM issue that I have been running into is the addition of "stuff" (utilities, new instruments, etc.) to the developers local LabVIEW palettes. It is one thing to be "checking out" pieces of the project's code, but it becomes problematic if there are things unique to the developers individual environment vs. things that are in the project's folder. You go to load some code and it can't find the version of the HP666A that "Bob" has in his instrument palette.

Good luck,


P.M.

Message Edited by LV_Pro on 06-30-2005 10:28 AM

[Dennis_Knutson]

I can't recomend it because I've never read it, but there's a book called "A Software Engineering Approach to LabVIEW". You can get if from Amazon.

[falkpl]

Thanks for all the advice.  I actually use a method almost identical to LV_PRO ( I use the folder hierarchy as an organizational structure, what are the advantages to using .llbs?)  I have read "A Software Engineering Approach to LabVIEW" (easy to read book) and found some of the suggestions very helpful but some stuff seemed to be outdated.  I do have a few questions, is there anyway to make palette of the main folder of a project automatically (I guess a tool could be made which takes the directory and creates a menu file for a palette?)  It would be very useful and avoid having to insert subvi's through a "select a vi ..." click and directory search.  Also is there any UML like development process (I know UML is only OO specific and doesn't translate to LV well) in the works.  A higher level architecting graphical language would immensely improve the development of large scale projects ( I currently consider any project with 100 + custom vi's as large scale and 1000+ vi's are very large scale).  A LVML (Labview Modeling Language) would be very cool where there is a vi diagram instead of class diagrams and also incorporate use cases diagram, DAQ diagrams, state diagrams and many other features.  Such a tool allows for engineers to share prototypes and architectures more easily as well as the possible of code template generation to speed up development documentation and spotting architecture flaws.  Again I have no formal background in software engineering but do have a background in computer science and programming so if any ideas are not so good I apologize in advance.  Enjoy the 4th and the long weekend.

Paul

[tst]

---

falkpl wrote:
is there anyway to make palette of the main folder of a project automatically (I guess a tool could be made which takes the directory and creates a menu file for a palette?)

---

There is.

I think you need to be in dynamic palette mode. Then, you go to Tools>>Advanced>>Edit Pallete Views.

Go into the user libraries pallete, right click an empty space and select Insert>>Submenu. You will have an option to add a directory with all its subdirectories. All VIs will be placed in there.

[falkpl]

Thanks tst,  I will try the dynamic palette mode, that will save me lots of time.

[LV_Pro]

My nervousness about .llb dates back to the early days of LabVIEW on the PC, when .llbs were created to give us Windows users long pathnames like the Mac users were enjoying (Windows was just a "nice" interface to MS-DOS which had a 8.3 filename limitation). I had more than one instance where having a single file get corrupted (the .llb) caused me to loose a lot of work. I try to avoid them now, except when doing a save for "Development", but admittedly this is just a personal preference. I also don't like all of my vi's to be "lumped" into one "directory", prefering having them grouped functionally.

P.M.