LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

View size of files that make up an LLB?

Solved!
Go to solution

The only time I use an llb is for polymorphic VIs since they are all fully dependent on each other anyways.

 

But for a project, each VI should be on its own.  If sending on to somebody else, zip it up.  Though, networked source code control would be even better.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 11 of 14
(506 Views)

@Dennis_Knutson wrote:
I don't use the RT version and I'm not familiar with the deployment options but for using an llb in development, yes it is obsolete. It has always been somewhat fragile on that a single corrupt VI will make the whole thing unreadable. It is not compatible with source code control. With the introduction of the project in LabVIEW 8, simply no reason to use it.

 

do use the RT Version, and definitely use Project and Source Code Control (TortoiseSVN).  When you go to build for the RT Target (PXI, in my case), the choices are Real-Time Application, Packed Library, Source Distribution, Web Service, and Zip File.  As best as I can tell, both the Real-Time Application and Source Distribution are effectively LLBs (though there may be some compression involved in the RT Application .rtexe format).

 

I don't understand the problem of Source Code Control.  The Project (and its Build Specifications) are under SVN.  Deployment is done through the Project.  So to do an update or patch, I'd check out the Project, make whatever changes are needed to the VIs in the Project (or to the Build spec), do the Builds, do the Deploys, then Commit all my changes.

 

I do agree that for code residing on the Host, LabVIEW Libraries (.lvlib) are preferable to .LLBs.  Haven't quite wrapped my head around Packed LV Libraries, however ...

 

BS

0 Kudos
Message 12 of 14
(491 Views)

The packed project library is actually a compiled version of a library.  You can't edit it at that point.

 

The issue with llbs and SCC is that any VI change causes the whole file to be updated.  It makes back tracking, branching, and merging a lot more difficult than a bunch of VIs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 13 of 14
(482 Views)

I agree that builds should not be saved in SVN.  Project is set up on my machine to save .exe files in a folder not on the "Commit" path, and the Source Distributions created for the RT Target are similarly not saved.  Thus there is no impact (on my system, at least) with Builds (except, of course, if I change the Build specification, which is reflected in a change in the .lvproj file).

 

BS

0 Kudos
Message 14 of 14
(459 Views)