LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Project library best practices

I am looking for advice and best practices for using Project Libraries.  I have used them in a very limited manor. I would like to knoe how people employ this as opposed to just using file hiearchy (ie putting all vis for a particular module of code in a single directory).  Are there drawbacks or limitations to project libraries.  I have used Labview since 1997 activly and this is just one feature I have been slow to adopt.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 1 of 5
(3,194 Views)

falkpl wrote: 
... I have used Labview since 1997 activly and this is just one feature I have been slow to adopt.

You have a year on me but I was slow to adopt them as well.

 

What made the difference in my case was LVOOP where many of the features of libraries are exploted.

 

The draw-backs?

 

If you have loaded the NI-Report Generation Toolkit you will see something that could qualify as a limitaion. In older version of this tool-kit we were able to enhance it with any extra method we need since it was all open.

 

The new version has been implemented using LVOOP and due to the way the library was structured we can no longer get at or use any of the references since they are all private data and only members of teh class are allowed to get at the private data. While this if good for the integrity of the toolkit, we are faced with the situation "if the tool does not do the job, we have to start all over from the begining."

 

So if you have re-use code that is rock-solid and you want to share it while also ensuring nobody can mees with your stuff, libraries are useful.

 

If you aren't doing that and not LVOOPing then we fall back to the old draw back of libraries bieng "all of your eggs (VIs) in one basket (llb)". 

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 5
(3,191 Views)

Thanks.  I have not adopted OOP much despite going to grad school in computer science and OOP was all the rage (no one in my program even knew of labVIEW).  I am considering using libraries for the sets of functions I have developed for internal use.  My bigest concern is when I transfer projects between computers.  I like having all the projects seperate and sharing these common libraries could be more difficult.  If a have a library in my vi.lib and add a copy to my project will there be conflicts.  I dont want have to install the library on every machine I mave my code to.  Alse can I have multiple versions (Both labVIEW and project library versions) of the same library in my vi.lib and manage this.  I fear that if I modify a library it could break old code, and in that case it would be nice to roll-back to the original linked version of the library)

 

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 3 of 5
(3,152 Views)

falkpl wrote:

Thanks.  I have not adopted OOP much despite going to grad school in computer science and OOP was all the rage (no one in my program even knew of labVIEW).  I am considering using libraries for the sets of functions I have developed for internal use.  My bigest concern is when I transfer projects between computers.  I like having all the projects seperate and sharing these common libraries could be more difficult.  If a have a library in my vi.lib and add a copy to my project will there be conflicts.  I dont want have to install the library on every machine I mave my code to.  Alse can I have multiple versions (Both labVIEW and project library versions) of the same library in my vi.lib and manage this.  I fear that if I modify a library it could break old code, and in that case it would be nice to roll-back to the original linked version of the library)

 


I avoid putting stuff in vi.lib or User.lib just because of the issues you listed. It's no big deal if you only have one big app and you never have to switch back and forth or move projects between developers. So all of my re-use code lives in a folder on my server and wahtever I need gets copied into my source Code folder. The Re-Use code seldom gets updated so I am not concerned with pushing it back to the server. If the app gets updateed to a new version of LV the whole Source Code folder get updated but what was on the server does not get touched.

 

But I am alone in the avoidance of VI/lib and User I fear.

 

If you want to go the path of using vi.lib then I suggest you look closely at The VIPM offered by JKI. I have evaluated it for our use and if we were using VI/lib and User.lib then we would be uisng it as well. But since I put the sqaush on User.lib about 8 years ago, we don't have a need for it.

 

Like I said, I am alone in avoiding User.lib.

 

Just trying to help (and possibly stirring up some conversion re: "To User.lib or not to SUser.lib, that is the question."

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 5
(3,147 Views)
Ben, I agree with you on this one.  My reuseable code (and I have a huge amount of it) is nicely sorted by LabVIEW version and sits in its own directory on my hard drive.  It is all under source code control.  Older versions use prefixes on the names of the VIs.  Newer code uses libraries and LabVOOP.  I really like the namespacing of libraries.  On the downside, loading a file from a library is slower than loading a nonlibrary file.  Most of the hit is the first load due to having to load, parse, and verify the library.
Message 5 of 5
(3,105 Views)