Move things to lvlib

[jyang72211]

I am creating a folder structure of code that I copy from another folder.  Both folders reside on the same PC, so I thought I would put everythign in the new folder in a lvlib to avoid naming conflict.  When I tried that, it didnt' work.  Some subfolder would refuse to get into the lvlib.  There is no error message, so I don't know why.  What is the best way of doing what I want to do?   

[tyk007]

By "folder" do you mean - physical disk structure? Project Virtual Folders? Project Auto-populating folders? Assuming you mean physical folders, don't forget that SubVI linking will probably point back to the old copy of the code <shudder>. 

I have had this problem with auto-populating folders being introduced into an lvlib; otherwise besides the gotcha of linking I have done this before. Care to detail further? 

[jyang72211]

when I said folder, I meant physical disk structure.  The reason I am doing this is because I am trying to do a branch of the code.  At the moment, code in both folder will be used in different occasion, but eventually, only th enew folder will be used.  

[JÞB]

Branching source on disk is not as easy as declaring a namespace on a .lvproj.  You need to seperate the code itself since the vis do not know what project they are being used on.

The EASIEST way is to declair that your "Source" project is a project template and use create project to script you up a brand spanking new copy of all the project members to a new location on disc.

Darren even nuggetized Project templates- and there is a great KB on how to... all traceable from links in this thread

[jyang72211]

let's say that I use a project template to create two project that contains VI with idential names but different content.  If they are both in memory, LabVIEW can still use the wrong VI, right?  If that's the case, I am not sure would using a project template solve my problem.  Or am I missing something? 

[JÞB]

Lets take the easilly reproducable case of a pair of instrument drivers -Plug-n-Play (Project style).

Call them "ABC.lvproj" and "XYZ.lvproj" and locate them in seperate folders inside <LabVIEW>\Instr.lib\

Each driver project contains a lvlib  The lvlib members know they belong to a lvlib (and their scope- but thats not important here)

Assuming each driver has a "Initialize.vi" (no real stretch there)  "ABC.lvlib:Initialize.vi" and "XYZ.lvlib:Initialize.vi" are located at different disk locations and have different fully qualified names.  Code within "Test.lvproj" will know they are different and load both dependancies.

Project Templates let you protect the fully qualified names too.  Creating your project template with good use of lvlibs (like you see in the examples) helps but is only part of what you buy with your own template project.  When creating your "use projects" from template you get to add to the namespacing.  Lets assume your template project contains some semi-reuse code like "Display Time.vi"  that you might want to appear slightly different in each project you create.  The project creation wizard helps by allowing an optional prepended rename.  So, "Display Time.vi" scripts out to the new project as "TestX_Display.lvlib:TestX_Display Time.vi on TextX_Test.lvproj/My Computer" assuming you just created "TestX_Test.lvproj" from template and "Display Time.vi" is a member of Display.lvlib on your template "Test.lvproj" and is targeted to My Computer.

That "Fully Qualified Name",TestX_Display.lvlib:TestX_Display Time.vi on TestX_Test.lvproj/My Computer,  is hard to mistake and not likely to exist in "TestY_Test.lvproj"

I probably could have been clearer.  But, you can avoid creating  projects that have vis with identical Fully Qualified Names but different code.

[jyang72211]

I understand that about lvlib.  That's what I tried to do, but it keeps giving me error, refer to the first post.  It seems to me you are trying to say that project template would solve the problem, but you actually mean lvlib would.  Is that the case?  

[JÞB]

Most project templates do contain libraries of vis by function.