LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What are developers' opinions on how best to handle upgrading large code libraries with multiple apps to new a labview version?

Solved!
Go to solution

I have a large set of code that I've painstakingly migrated from one labview version to another over the years.  I have lots of deployed applications that I need to continue to support.  From experience and interaction with other developers, I don't think I can continue to migrate every application to a new labview version when I upgrade going forward.  Every application seems to break in one way or another, the builds don't work right and need to be re-done, and its too much time to get all my applications working and tested again.  That opinion is solidified by NI's policies that make it impossible to install old toolkit versions on new labview versions, for example.  Compatibility is often being sacrificed so NI can develop labview in the direction they choose.  So I have to take the position that whatever version I write an application in will probably need to be maintained in that labview version throughout it's life.

 

In light of this, how are other developers managing older applicatiosn written in older versions of labview.  Right now I have a virtual PC on my system with 7.1, 8.0, 8.2, and 8.5 all running on different virtual PC's so I can keep each installation separate.  I strongly recommend this approach.  But keeping my large libraries of code separate is tough.  They are many GB, they all link to each other, and I always get worried even when I separate them in different directories that somehow labview will search in the wrong place and find the wrong version of a sub-vi.  Are other people also trying to maintain separate copies of all their code in different labview versions?  How are other people managing this problem?

-Devin
I got 99 problems but 8.6 ain't one.
Message 1 of 3
(2,859 Views)
Solution
Accepted by billings11

Hi,

The following directory hierarchy, coupled with a "hierarchical" VI naming strategy, have been effective (for me) at preventing "cross-linking" across projects and LV versions. The storage hierarchy was designed for use within an SCC environment, but works fine independently. Hierarchical-naming insures unique names for application-specific files. Use of Project Libraries (in LabVIEW 8.x) addresses the problem of having different VIs with the same name, still, it gives me warm-fuzzies to have app-specific files named uniquely, and I can't imagine not using Hierarchical-naming anymore - it's described at-length in section 2.1 of attached .doc..

Note: It's been my experience that companies identify resources as supporting specific "Programs", where a Program is related to a product or "family" of products, so, under <Programs> (below) each "Program" subdirectory encapsulates product-specific (or product-family-specific) applications. Also, assuming no SCC tool is being employed the <Production> directory (below) exists as a repository for distributables.  All distributables required to reproduce a test-station should be located under <Production>.

******************************************

<Software_Root>
<Development>
| <Common>
| | <LabVIEW_61>
| | | <Drivers>
| | | | <DMM>
| | | | <OS>
| | | | <PS>
| | | <Utilities>
| | |   <File>
| | |   <Error>
| | |   <String>
| | <LabVIEW_711>
| | <LabVIEW_82>
| | <LabVIEW_851>
<Programs>
* Program-specific applications that (probably) have distributables
| <Program_#1>
| | <Application_#1>
| |   <Docs>
| |   <Source>
*       Individual, application-specific, VIs go here
| | <Application_#2>
| | <Application_#3>
| <Program_2>
| | <Program_3>
| <Tools>
*   Tools are NOT "program"-specific, and, may have distributables
|   <SomeTool>
|   <SomeOtherTool>

<Production>
| <COTS&Freeware>
| <Programs>
| | <Program_1>
| | | <Application_#1>
| | | | <Application_#1_Rev#1>
| | | |   Application_#1.bld>
| | | |   <EXE>
| | | |   <Installer>
| | | |   <Source>
| | | |     Application_#1.llb>

*           Distributable is created from LLB "snapshot", not directly from development tree
| | | <Application_#2>
| | | | <Application_#2_Rev#1>
| | | |    Application_#2.lvproj>
| | | |   <EXE>
| | | |   <Installer>
| | | |   <Source>
| | | |     Application_#2.llb>
| <Tools>

******************************************

 
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 2 of 3
(2,805 Views)

For the record, the tree above should have looked like this: 

<Software_Root>
| <Development>
| | <Common>
| | <Programs>
| | <Tools>

| <Production>
| | <COTS&Freeware>
| | <Programs>

| | <Tools>

Hope it helps.

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 3 of 3
(2,798 Views)