vi location move linking problems?

[jyang72211]

Hi all,

I have a few questions about VI organization, lvlib, and vi linking.  I am trying to structure my code in such a way,
so that I will have a couple of libraries that contains subvis that we can use accross a few memebers in our team.  I
am doing the code development on my harddrive right now, and eventally, it will be transfered to a network location. 
My questions are the following:

1. When I transfer all the files to another location, how do I fixed the linking among files, since the files are
going to freak when I moved all the files to another location.  Or, would you suggest that I take another approach?

2. Is the structure below the best way to organize my files if I want to create a bunch of subvis for future use?
Notice that the lvlib for a particular subvis is outside of the subvi's folder.  I just want to centralized all the
libraries.  If there is a better way, let me know.

Thanks!

LV Code
- Library
  - Subvi1 Folder
    - contains vi, ctl, and everything that pertain to Subvi1
  - Subvi2 Folder
    - contains vi, ctl, and everything that pertain to Subvi2
  - Subvi3 Folder
    - contains vi, ctl, and everything that pertain to Subvi3
  - Subvi4 Folder
    - contains vi, ctl, and everything that pertain to Subvi4
  - lvlib file for Subvi1 and subvi2
  - lvlib file for subvi3 and subvi4
- Test
  - Test 1
  - Test 2

[DavidMaidman]

Hi, when you move the VIs to the new location you so long as the relative paths are the same you should just be able to mass complie them (Tools>>Advanced>>Mass Compile).

If you are reordering the VI structure and LabVIEW can not find the VIs then you can specifiy the search path it uses on leading. Do this select Tools>>Options>>Paths and select 'VI Search Path' from the drop down. Add the top level location of you files to the search path for example "C:/LabVIEW Project/*". In this case when LabVIEW is restarted it will automatically search the folder "LabVIEW Project" and all its subfolders for any VI it needs.

Oce you have specified the search path you should be able to mass compile and open without problem.

Hope this helps

[JÞB]

OK First I have got to caution you to use a Source Code Control application

so that I will have a couple of libraries that contains subvis that we can use accross a few memebers in our team.  I
am doing the code development on my harddrive right now, and eventally, it will be transfered to a network location. 

---

Secondly I would challenge your folder structure.

At CCI My SCC database is structured:

LV_Vers

     >Projects         

          > Proj A

                >Main

                >Globals

                >UI

                >Tasks

                >Documentation

           Proj B

                >Main

                >Globals

                >UI

                >Tasks

                >Documentation

    Reuse

           Utilities

                  UI

                  Report

                  Error

                  Time

           Drivers

                  Device A

                  Device B

    Eval code

Allow the SCC provider to set the local path on each target machine (In VSS this is the "Checkout Folder") and provide some guidance to the users in your team to maintain consistancy in the root path for the SCC Database.

[jyang72211]

Thanks!  That was helpful.

Yik

[JÞB]

Not a problem!

<Personal account ahead>

In 2001 I started for a company that was expanding thier use of LabVIEW to automate device verification testing.  No SCC, many developers, multiple interelated projects, no common souce file structure.  The first device took about 12 months to get through all the testing and by the end some of the earlier code had been "reused" in such a manner that the old project would not run.

The lessons learned meeting generated absolute needs for, a well structured code repository, SCC program, Well structured project template.

It took some time but project development went from 2-3 weeks to develop a "test" to well the last test I wrote on that template took 4 hrs.  Mostly because I had a full suite of well organized reuse code.