Duplicating .lvproj file and contents

[amaglio]

I am just looking for some input on the proper and most robust way of doing this:

I work at a Radio Frequency IC design company, and we use LabVIEW to design GUIs for the different chipsets that we develop. During the testing of the ICs we use the GUIs very heavily, and during this time period they are constantly undergoing changes and tweaks. Towards the end of the test phase, the GUIs by now are in a stable and functional state. Once the test phase is complete the GUIs will rarely be used. However, it is critical to keep the GUI in a functional state even after the test phase is complete in case we need to communicate with the chip again for any reason (which my be years later). On our network, we have a directory that is used to keep most of our LabVIEW VIs, there is no guarantee that these VIs will not change or even be deleted at any point in time. The main source of the VIs used for the IC GUIs comes from this directory on the network, the vi.lib directory, and the user.lib directory (mostly Open G VIS from user.lib). 

Once the GUIs are in a stable state, my current method for creating a stand-alone version of it has been to duplicate the .lvproj file and contents and move it to a new location. During this process I would usually include everything except the items in the vi.lib and user.lib. If I want these VIs to be operable at any point in the future, would it be more robust to include everything? Even the VIs in vi.lib and user.lib? I guess the questions is, will the NI VIs that I am using in these GUIs always be available in future version of LabVIEW?  And will I always have access to the Open G VIs that I am currently using from the VI Package manager, or is there no guarantee that these might change or be discontinued?

Kind of a side question, that will help me make a decision on whether or not to include the user.lib VIs. Is there a way to use the VIPM (Community Edition) and have it put all of its VIs on a network instead of C:\Program Files\National Instruments\LabVIEW 8.5\user.lib? Or can you change where <user.lib> points to?

Thanks for any help and input. I've read it over, it makes sense to me, but that doesn't mean much , so if any clarification is needed don't hesitate to let me know. 

-Anthony 

[Norbert_B]

Anthony,

the best and recommended answer to your need is:

Use Source Code Control!

In regard to your configuration, you can backup parts of user.lib as well.

vi.lib should not be part of that since this folder is used for NI internal sources. So making changes on yourself within this folder is highly not recommended!

If you need to write a tool on your own, the VI Server of LV 2009 supplies you a method "Save As" for the lvproj-class which does the requested, but as far as i know excluding components of vi.lib (due to the stated suggestion).

hope this helps,

Norbert

[amaglio]

Thanks for your reply Norbert. Source Code Control (SCC) is actually something that I have been meaning to set up, its just the initial time investment of setting it up and learning it I have been avoiding, but I believe it will end up saving me time in the long run. Although I have been planning on setting up SCC I did not realize it would be able to help out in this aspect of things. How will SCC help me out in this area? (I am not doubting your suggestion, just not too familiar with SCC). Also, I think its time to go for it anyway, do you recommend any SCC in particular. I have notices that Tortoise seems to be pretty popular. Thanks for your time and help 

[Norbert_B]

Anthony,

every SCC provider i am aware of includes automatic backup history when checking sources back in. So the only thing you have to do is: either keep in mind the versionnumber of the version you want to keep as reference or you have to create a branch.

Norbert

[Ben]

SCC control will only be part of the battle.

Check with OpenG or JKI about using the VIPM. If used correctly it should cover the user.llb stuff fine.

Where you are in danger is using VI's from VI.lib (see my signature). Those can and will change with LV updates so you should have them backed-up prior to any changes or updates there. I believe you can include the VIs in VI.lib as part of a Source Distribution. If you code is at a good state, do a source dist and stash it away. It seldom hurst to have an extra copy.

Ben

[amaglio]

Thanks Norbert. Wow, so when using SCC you can have VIs linking to different versions of a sub-vi? 

Hi Ben, I checked out that link in your signature about VIs in VI.lib, didn't quite have the time to finish up this morning but will surely be returning to it.  So you recommend that when the code is in its final state, I should even copy everything over, even the VIs in VI.lib? If I do that will it be a problem renaming every VI with the project name on the end of it (I have been doing this to avoid cross referencing). It works fine with my own VIs, but have never done anything like this with VIs from the VI.lib.

[Ben]

Since you will be continually updating this app, having backups of what is in VI.lib is a good safety check.

Ben

[Norbert_B]

---

amaglio wrote:

Thanks Norbert. Wow, so when using SCC you can have VIs linking to different versions of a sub-vi? [...]

---

No, since the version is only a SCC-information, it is not known to LV. You have the feature of backups and therefore can easily "relink" VIs to older VIs....

Norbert