Creating a new LabVIEW Project from an existing large LabVIEW program

[sydmil]

Hello everyone,

I have a large LabVIEW program (~ 100 VIs) that was developed by several people over the years and I need to get this program under control. My first idea is to utilize LabVIEW Project. Can a new LabVIEW Project be build from an existing large program such as this (which includes NI-DAQ control, as well as other USB controlled third party instruments).

Any advice or suggestion would be most welcome !

Cheers ! 

[crossrulz]

1. Start by making a good directory stucture to organize your code.

2. Make the project and just have it load the folders.  I hear arguments on both sides of the autopopulating project folders vs virtual files.  To get you started, I woul use the autopopulating folders until people get really used to the project organization.

3. Fix any crosslinking you might have by moving the VIs around and combining into a single project.

This is not hard to do and should not take very long based on your quick description.

Oh, and make sure all of this code is put into a source code control software (SCC) of some sort (SVN, GIT, Mercurial).  When something goes completely wrong, that will save your hide.

[JÞB]

---

@crossrulz wrote:

1. Start by making a good directory stucture to organize your code.

---

That I cannot agree with more.

Take it back to the "Drawing board" and identify the components of the code.

---

Tim missed telling you about Project Templates!  Project Templates allow you to duplicate existing "Generic" projects that have a common theme without screwing up the source code for exisiting projects.  You CAN create your own!  

Have you looked into the question of: Could an existing project template be a good starting point" for your needs?  Then duplicate the template and modify it for your use case!  It really is powerfull!

[Bob_Schor]

I've done this successfully with "large" projects with hundreds (but not thousands) of VIs.  I use the following Directory Structure:

• Project Folder
  • Documentation Folder
  • Resources Folder (includes Icons for .exes)
  • Sub-VI Folder
  • TypeDef Folder
  • Support Routine Folder (which may have Sub-VI and TypeDef sub-folders

I'll bet you'll start with empty Documentation and Resources (but, ideally, such data should be kept with the Project).  I put the Top-Level VI (or VIs) in the top level of the Project Folder, along with the Project File (MyProject.lvproj) when it gets created.  I typically organize my Version Control System (I use Subversion) on a Project basis, so I'll have a Repository that will have the Project Folder as the "committed" entity -- I CheckOut, Commit, and Update the entire Project as a single unit.

If your Project "divides" nicely into a Main Routine and "Support" Routines (for example, the Main Routine does Data Acquisition, the Support Routines do Configuration Management, Data Validation, Data Analysis, etc.), I usually isolate the Support routines into their own folder.  Similarly, if you have other "natural divisions", you may want to make additional Folder Trees -- it doesn't help if you have a Sub-VI Folder with 240 VIs in it -- hard to manage, hard to find things.  Sometimes additional sub-divisions can help (for example, have a Hardware sub-folder for hardware-related Sub-VIs or Types, or an Excel sub-Folder for code to manage reading/writing Excel Workbooks).

Once the VIs are safely stored in folders, create your Project, name it, and save it inside the Folder at the top level.  Close LabVIEW, open the Project again, and make all of the sub-folders "auto-populating" -- this will "suck in" all of their content.  I'd recommend at this point turning off auto-population (try it both ways and see which you prefer).  You now have everything except the (relatively few, I hope) VIs in the top level.  Right-click the top level of the Project, choose Add Files, and select the top-level VIs (don't select the Project .lvproj, .aliases, or .lvlps files).  Close (saving everything), save in your VCS, and you are Off to the Races.

Bob Schor

[sydmil]

Great, thank you all for all the suggestions !

Before I start anything I want implement source code control using TortoiseSVN with TSVN Toolkit and then I'll get started...

Cheers!

[AuZn]

Just a small tip: Always check the dependencies branch inside the project. It tells you the VIs that are used in the project but not yet added to.

For your purpose you may create a blank project, add the single main VI that calls all the other subVIs in your program, and look into the dependencies to see which are the VIs actually being used. 

[billko]

---

@AuZn wrote:

Just a small tip: Always check the dependencies branch inside the project. It tells you the VIs that are used in the project but not yet added to.

For your purpose you may create a blank project, add the single main VI that calls all the other subVIs in your program, and look into the dependencies to see which are the VIs actually being used. 

---

I think a caveat to this would be if you use dynamically loaded VIs.  I don't think they show up as dependencies.

Is this true?  I can't remember.

[natasftw]

You're right.  Dynamically called VIs won't show up in dependencies.  It's also why they won't automagically be added to an executable as well.

[mikeporter]

It depends on how the dynamic VIs are accessed. If the only thing you have to start with is a path the VI, then no, they will not appear in dependencies or be automatically included in builds.

However, another use case for dynamic VI is to include a static reference to it in your code. In that situation it will appear in dependencies and be automatically included in the build, but it will not be automatically reserved for execution when the calling VI starts.

In addition, because it is loaded into memory you don't need a complete path to the VI in order to call it. All you need is its name. However because it only appears as a static reference, it will not break your application if it is broken -- a potentially useful effect.

Mike...