Jump to content
drjdpowell

Should I abandon LVLIB libraries?

Recommended Posts

Sorry OP if this is derailing the conversation but I think it still is relevant to the original question.

 

That’s alright.  Polymorphic VIs certainly have the same issues.  Though at least with them I can see why they might entail loading unused code, while with the library thing it seems entirely pointless.  Similarly with Classes; I can see why one might need to load all Dynamic Dispatch methods, but not why LabVIEW insists on loading classes or static methods not used by any in-memory VI.   

Share this post


Link to post
Share on other sites

I used to use them for grouping seemingly related libraries but long given up for reasons described. It just creates an additional hard link and in many cases if already using classes doesn't add huge amount of benefits.

 

I would second smithd's comments regarding the problem with links between classes. I would have an interface class (or even a cluster depending on whether data manipulation is required). Obviously the important thing is that it shouldn't depend directly on either class but they both depend on it, meaning either class can load without the other.

 

What you start to get towards here is dependency inversion to decouple elements of code, there was a talk at the CLA summits last year that was recorded that I found to be a  good explanation of this. Believe it was the US summit and the talk was by Dmitry Sagatelyan (number 15 in Mark Ballas videos).

Share this post


Link to post
Share on other sites

What you start to get towards here is dependency inversion to decouple elements of code, 

 

I’m all for advanced stuff to do advanced things, but I don’t want to have to build a carefully-structured dependency injection just to use a utility subVI.  I’d rather just leave it a library orphan.

  • Like 1

Share this post


Link to post
Share on other sites

I agree if we are just talking about a single VI but if we are talking about coupling APIs then dependency inversion (not "injection", stupidly similarly named but unrelated principles) useful pattern to avoid crazy dependency loads.

 

All it really is is a form of abstraction layer. My understanding in LabVIEW is all it is saying is your messaging API has a child class which implements the TCP, then as you are noting, don't put this in the same libraries as this means then that the TCP messaging child is dependent on messaging, but messaging isn't dependent on the TCP child.

 

For cases like this having additional libraries wrapping these together just reintroduces the unnecessary linking of the and breaks these principles.

 

I quite like smithd's rule of thumb, (wildly paraphrasing!) if you wouldn't give them all the same icon, I wouldn't put them in a library together.

Share this post


Link to post
Share on other sites

another (i think) valid comparison would be to a .c file or any other single file in a text based language. You'd usually have a whole class in one file, a whole api in one file, or a whole set of related helper functions in one file. Only once in a while would you make a whole new file to contain a single function. As a result including that file includes each function in the dependencies of your project, along with that file's dependencies (although the concept of include vs code files helps with that). When the compile occurs, references to those unused functions are removed. I don't write a lot of C but thats how I understand the process and it feels similar to me.

 

On the other hand Jack's main point was that lvlibs don't really work that well, which is fair. 

  • Like 1

Share this post


Link to post
Share on other sites

When the compile occurs, references to those unused functions are removed.

 

That’s just it; the LabVIEW IDE is not removing unused functions.   The EXE builder might, but not the IDE.   It is compiling them and otherwise using them fully.   If a C IDE had compile-on-the-fly where it compiled all those unused functions then it might well have performance issues that annoy some C developers.  

 

I would be happy for unused library members to appear under dependancies, greyed out to show the compiler is ignoring them.

Share this post


Link to post
Share on other sites

Can we get rid of LVLIB “libraries†then?  Or at least rename them as they don’t match the English meaning of library?   Libraries are not "collections of books that cannot be read except all at onceâ€.  And can we have an actual library construct that does collect related VIs with namespacing and scoping?  Why don’t we have proper libraries in LabVIEW?!?

 

All right, I will have to jump in now.  I find that .lvlibs do have their purposes.  We use them to create collections of, say, typedefs (for namespaces, in particular) and similarly, of course, shared variables (LabVIEW does this), and we create collections of certain types of classes (a set of Command classes or State classes).  This is especially convenient since, for example, we often need to include the typedefs from one component in the project for another component.  It is convenient to load the entire collection as a unit, and the namespace avoids collision with the other similar collections in the project.  I have written on the uses of .lvlibs elsewhere on LAVA.  These are contexts where .lvlibs are helpful, but we also carefully use interfaces to avoid the load-everything issues correctly identified in this thread.   I certainly do think that managing dependencies is essential when using .lvlibs, but then it is good practice anyway.

We also collect tightly connected groups of classes in .lvlibs, say, ones that perform a certain set of functions.  Then when we use these functions, the code appears neatly in a library in the dependencies.  Again, it is super-important to manage dependencies, but let's recognize their legitimate value.

 

I do agree it is unfortunate that loading even a child .lvlib library loads all the libraries in the library hierarchy.  This is not the behavior our UML tool has, on the other hand, which loads only the requested library.  I'd prefer the latter approach for LabVIEW as well, but I can see the problem, since some code will be broken without dependencies.  I'm not sure what the best way to handle this is.

 

I do agree that .lvlibps need some more work before they will be really usable, as I have also written about on LAVA.

Share this post


Link to post
Share on other sites

All it really is is a form of abstraction layer. My understanding in LabVIEW is all it is saying is your messaging API has a child class which implements the TCP, then as you are noting, don't put this in the same libraries as this 

 

 

Yes, for simple projects we would have a single "Common" library which would contain the abstractions needed by the other hierarchies. Only this Common library would be automatically loaded into memory by it's callers. We have found that sometimes 'stairway' requires a bit too much lvlib maintenance to be truly useful on all but the larger projects. I'm interested in your experiences and patterns for this.

 

I quite like smithd's rule of thumb, (wildly paraphrasing!) if you wouldn't give them all the same icon, I wouldn't put them in a library together.

 

This is probably my main take-away point as well  :cool:

Share this post


Link to post
Share on other sites

We use them to create collections of, say, typedefs (for namespaces, in particular) and similarly, of course, shared variables (LabVIEW does this), and we create collections of certain types of classes (a set of Command classes or State classes).  This is especially convenient since, for example, we often need to include the typedefs from one component in the project for another component.  It is convenient to load the entire collection as a unit, and the namespace avoids collision with the other similar collections in the project. 

 

Hi Paul,

Are the current LVLIBs the best for the use case of “collections"?  If you were to reuse most of your Commands in a modified component in a new project, but with some replacement Command classes, you would not be able to do that, as a Class/VI can only belong to one library.  You could reorg things to have a “CommonCommands†library and a couple of “ExtendedCommand for XYZ†libraries, but this requires changing the namespacing of your original project.  Aren’t LVLIBs combining too many features into one construct?

 

 

Also, to all:

It may be the case that “Best LabVIEW Practices†will naturally lead to use of Libraries that is non-problematic.  But reasonably good LabVIEW practices should produce reasonable good (and reasonably easy) solutions.  LVLIBs don’t currently allow that, at least in combination with LVCLASSes.

Share this post


Link to post
Share on other sites

Hi Paul,

Are the current LVLIBs the best for the use case of “collections"?  If you were to reuse most of your Commands in a modified component in a new project, but with some replacement Command classes, you would not be able to do that, as a Class/VI can only belong to one library.  You could reorg things to have a “CommonCommands†library and a couple of “ExtendedCommand for XYZ†libraries, but this requires changing the namespacing of your original project.  Aren’t LVLIBs combining too many features into one construct?

Your description is quite correct.  On the other hand, I don't think this is a problem specific to project libraries.  It is a trade-off associated with using templates.  I have original elements that I need in a new project, but the elements in the new project must be distinguishable from the original items.  I can 1) copy or 2) construct the elements; then project libraries add the capability to keep the element names in a collection or namespace, which is what the project libraries add (and I think can be quite valuable--I even can have both libraries in the same project if necessary).  The new elements are images of, but not identical with, the originals.  I don't know of a straightforward way to get around that.

Copying a template is (generally) relatively simple.  A second issue is that some customization (changing namespaces and references) is often necessary.  Then there is the much bigger issue of what happens when the template changes?  How do we change all the copies?  This is also not simple if we are not programmatically constructing the copies, but we mitigate the impact by keeping the namespace-specific elements as thin as possible (so that they have only namespace-specific content) and call code in common code beneath.  In other words, the namespace-specific elements are the tips of the iceberg that is the common code.  Then changes to the common code can propagate easily across projects; changes to the thin top layer are still problematic, but these can be very few now.  Of course, with some sort of scripting other solutions exist, but then we are well beyond the topic of the basics of project libraries.

Would I like a straightforward solution to the challenges of using template code (while keeping the advantages of using templates in the first place)?  You bet!

Paul

I guess it is also worth pointing out that methods of abstraction can help the template stay flexible while still remaining thin at the top layer.

Share this post


Link to post
Share on other sites

I have written on the uses of .lvlibs elsewhere on LAVA.  These are contexts where .lvlibs are helpful, but we also carefully use interfaces to avoid the load-everything issues correctly identified in this thread.  

 

I would really like it if you'd link to that discussion, or estimate about when you posted it.  I need to school myself on these topics.  I tried clicking on your name and "find content", but you're too prolific.

Share this post


Link to post
Share on other sites

I would really like it if you'd link to that discussion, or estimate about when you posted it.  I need to school myself on these topics.  I tried clicking on your name and "find content", but you're too prolific.

Well, here are a couple:

http://lavag.org/topic/16235-organizing-your-projects-on-disk/

http://lavag.org/topic/15271-lvclasses-in-lvlibs-how-to-organize-things/

There are others but these are the most recent and likely have the better content.

I guess I haven't collected my thoughts on this in one easy-to-find place.  Sorry!

  • Like 2

Share this post


Link to post
Share on other sites

another (i think) valid comparison would be to a .c file or any other single file in a text based language. You'd usually have a whole class in one file, a whole api in one file, or a whole set of related helper functions in one file. Only once in a while would you make a whole new file to contain a single function. As a result including that file includes each function in the dependencies of your project, along with that file's dependencies (although the concept of include vs code files helps with that). When the compile occurs, references to those unused functions are removed. I don't write a lot of C but thats how I understand the process and it feels similar to me.

 

On the other hand Jack's main point was that lvlibs don't really work that well, which is fair. 

 

Actually the C compilers I have worked with work a little bit different. Normally each .c (or .cpp, .cxx or whatever) source file results in an .obj file. These object files CAN be combined (really linked) into a .lib library file. When you use a single function from an object file, the entire object unit is linked into the resulting executable image, even if it contains about 500 other unused functions. These unused functions can reference other functions from other object units and cause them to be included as well even-though they are never actively called in the resulting executable. Only when  you link with a library file, will the compiler pick out the embedded object units that contain at least a function that is used by any other included object file or the actual executable.

 

It's likely that with careful linker scripts and all that you can nowadays hand optimize this step with some modern compilers but it's not what is normally done, since linker scripts are a rather badly documented feature.

 

With all this said a lvlib (and lvclass) much more resembles a C object file than anything else, in terms of what gets linked into the final executable file. As such the term library is somewhat misleading especially when you compare it to the C .lib library file which is more of a real collection of units.

  • Like 2

Share this post


Link to post
Share on other sites

I've followed this thread closely to learn more about libraries, classes and dependency injection. Thanks for sharing all your thoughts so far. Now, I don't just want to lurk in the shadows, but participate to this discussion.

So, let me reply to the initial question: Should I abandon LVLIB libraries?

 

First of all, I don't consider the correctness of the dependency tree as a problem. If you only want your hierarchy in the dependency tree, than you cannot use any type of library. So the only thing I'm concerned about is loading time and responsiveness of the IDE. This is what I think:

You should not abandon libraries, if you have a collection of VIs, like utility VIs, that do not call any subsequent libraries. An example would be a library that wrapps functions to call an external DLL. Such a library is completed as one entity. There is a slight loading overhead, but it is acceptable in my opinion.

You should consider to abandon libraries if they contain optional functions that call to other libraries (other lvlibs or classes to be precise). Then again, if all of the VIs in the library call to the same external library, there is nothing gained by abandoning it.

You should abandon libraries, if they heavily depend on other libraries and the dependencies are different on a VI basis. Calling one VI will load the entire hierarchy into memory which cannot be desireable, unless all sublibraries are in private scope. In the latter case you try to namespace items, which adds dependencies that are undesirable for other functions.

---

In the end you'll have to choose by yourself which way is the best. As for me, I'll stick with libraries, but refactor some of my code to a more 'flat' layout (if possible no sub-libraries).
For someone like me who loves namespaces, the namespacing JackDunaway recommends (namespace in filename) is somewhat undesirable (no offence, I just preffer namespaces even if they try to slow me down :D). I would rather see something like a "Namespace" type of object in LabVIEW.

  • Like 1

Share this post


Link to post
Share on other sites

If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies).

 

Beautiful discussion - this is one of the few things I find really awful about LabVIEW, and a thing I really really hope will change.

 

For deployment LVLIBP can work, but not for dev tools (which I do most of involving libs) as they need to be cross-platform and cross-version. LLBs are out of the question for me because they're so arcane. Everybody has mentioned all the pros and cons of these files except for one thing: Security.

 

I use LVLIBs for three features, here in the order of importance (for me):

 

1) Namespacing.

2) Security against someone else replacing my code.

3) Scope.

 

I wish LVLIBs also had this fourth feature:

 

4) Single file on disk.

 

Namespaces

Generally I can't get manual namespaces to work. The teams I work in aren't structured enough to adhere to one convention, and they are typically those middle-of-the-road programmers that have enough experience to boost their self confidence but not enough to make them put their egos aside and stick to the plan. Something like that. I want namespaces in LabVIEW, and I hate that I have to stick my VIs into a library to get that - or I hate what I must lug around as well when I just want namespaces.

 

Namespacing through the physical file name also has its advantages - one being that you can identify a VI's purpose without the context of its library. But namespacing in file names create long file names, and it creates long paths due to all the duplicate information (the file name being almost the sum of folders leading into the file location). And we have some limitation to maximum path length in characters when we build executables and load VIs dynamically (~230 chars IIRC).

 

Security

For many applications it's unsafe if someone external to the dev team can just replace a file in your deployment and either change functionality or snoop into your code. Thus it's a great thing that libraries bind their members so tightly that this isn't possible.

 

Scope

I don't use this as much in LVLIBs, but I do in LVCLASSes.

 

But what about the load everything feature?

Besides the physical distrib size, the load time, and the mem usage issues, there is another really bad consequence of this: the "Only one file in memory with any given file name" feature.

 

I feel the "contract" that LabVIEW imposes on us that a library will be loaded into memory, always together with all its members, is the single thing that stands in the way of two distinct modules appending functions from the same namespace (LVLIB) into memory. This issue:

 

- You have A.lvlib that owns a.vi, b.vi, and 100 other VIs.

- Someone has built a source distrib, Module X, that uses a.vi of A.lvlib.

- Someone else has built another source distrib, Module Y, that uses b.vi of A.lvlib.

- Since both source distrib builders wanted their modules to be as small as possible they made their build script such that unused lib member functions were stripped from their build.

 

Now you make an application that must load Module X and Module Y, but it can't. Your app loads Module Y first, and Module Y loads A.lvlib into memory. This version of A.lvlib only has one VI in it, namely b.vi. Now your app attempts to load Module X, but Module X fails to load, as it can't load its own dependency a.vi. It's not allowed to do anything with its own copy of A.lvlib that references a.vi, as there is already a file called A.lvlib loaded.

 

I'd guess that everybody here has experienced the above and works around it on a regular basis. If LVLIBs weren't so atomic this issue could be fixed by allowing gradual loading of library member functions. Then Module Y would just load b.vi, and Module X would later load a.vi and merge the namespace. If on-request loading was supported that would already be built in. Of course there would need to be certain checksums etc, but you wouldn't have to jump through hoops to make several source distributions actually work together, with a potential rebuild of ALL modules when you add a new module.

 

Does it even matter for smaller reuse tools?

The opinion that the issues we're discussing here are only relevant for 8000 VI applications, and that we don't run into them on a daily basis, was aired (Neil perhaps?). I think this issue is an armed grenade from the first library we make - it might well first blow up later, but eventually we reuse something or stuff our lib into an executable that loads two modules, and then we're presented with two options, both of which cause tremendous headache: either 1) careful design and re-design of the application as it evolves, or 2) total redesign of our reuse components (and how much reuse is that?).

 

Case in point;

We (GPower) has a bunch of reuse libs for public download. They are GPArray.lvlib, GPMath.lvlib, GPString.lvlib, GPError.lvlib etc. These libs are used by many people around the world, so need namespacing as they are quite low-level and common. They are reuse tools that support a large number of LabVIEW datatypes, so they are also full of polyVIs with many many instances of almost identical functions just with different datatypes for inputs and outputs (also slight variations in realization, but that's not the heavy part). Not too big a deal on a lib by lib case, you hardly notice this in the IDE, even though some of the libs have maybe 200 VIs in them (they are small).

 

Now we've made a new toolset, Expression Parser, which uses ~10 of our own libs. When you drop the first VI from the Expression Parser toolset into your block diagram, LabVIEW loads almost 1200 VIs from disk! Why the h*** is it designed to do that? Expression Parser is also heavily inlined and recursive, so on most dev machines you notice - let's be frank. Afterwards everything is fine, but it's not necessary to load all that before you need it. Often times you won't even need 30 of those VIs. Building the VIP for Expression Parser takes around 20 minutes. Building an executable containing Expression Parser will never get below ~10 minutes. For those reasons. That is totally unecessary.

 

So, I use LVLIBS, but I hate them. I can't live with the alternatives currently though, so I jush push at NI all I'm able to, to get some of this moving in a slightly different direction. I hope it eventually will.

 

/Steen

  • Like 2

Share this post


Link to post
Share on other sites

What you start to get towards here is dependency inversion to decouple elements of code, there was a talk at the CLA summits last year that was recorded that I found to be a  good explanation of this. Believe it was the US summit and the talk was by Dmitry Sagatelyan (number 15 in Mark Ballas videos).

 

Do you know where this recording can be found? Mark doesn't seem to have the US CLA Summit 2014 videos online currently...

 

/Steen

Share this post


Link to post
Share on other sites

Do you know where this recording can be found? Mark doesn't seem to have the US CLA Summit 2014 videos online currently...

 

/Steen

 

Haven't seen them anywhere and the friendly search engine has no clue too. However the presentation material is available: https://decibel.ni.com/content/docs/DOC-36232

  • Like 1

Share this post


Link to post
Share on other sites

Generally I can't get manual namespaces to work. The teams I work in aren't structured enough to adhere to one convention, and they are typically those middle-of-the-road programmers that have enough experience to boost their self confidence but not enough to make them put their egos aside and stick to the plan. Something like that. I want namespaces in LabVIEW, and I hate that I have to stick my VIs into a library to get that - or I hate what I must lug around as well when I just want namespaces.

Amen.

 

Namespacing through the physical file name also has its advantages - one being that you can identify a VI's purpose without the context of its library. But namespacing in file names create long file names, and it creates long paths due to all the duplicate information (the file name being almost the sum of folders leading into the file location). And we have some limitation to maximum path length in characters when we build executables and load VIs dynamically (~230 chars IIRC).

My arguments follow the same line, however I recently "discovered" that having namespaced files in namespace folders over-determines the namespace and therefore makes no sense. Thus all files can be put into a single folder without loosing information, or rather putting all files into a single folder would increase readability. At the same time you don't increase the path length: 'Library/Function.vi' vs. 'Library-Function.vi'.

However the initial problem remains: Programmers stick to their own plan.

@JackDunaway: I would like to see how you organize the files on disk. VIs are one thing, but classes and especially dispatch VIs are a whole different story. So how do you prevent the name-conflict and path-length issues?

 

Without LVLIBs, how do I avoid name collisions? I prefer this filenaming convention: Project-Class-Method.vi or Application-Class-Resource-Action.vi ... or generally, LeastSpecificNamespace-...-SpecificThing-...-VerbActingOnASpecificThing.vi

Share this post


Link to post
Share on other sites

After finishing my first truly large scale Labview Project, i have also given up on LVLIB libraries.  I've also given up on Xcontrol's but that's a different story.  I still haven't figured out how that one xcontrol touched everything in my project after i completely removed it and never really used it.

 

In my case i was trying to deploy code to multiple CRIO's and the cross dependency issues that you all have illustrated for libraries were wreaking havoc on my deployment. I had multiple instances of strange cross dependencies loading so much that by the end of the day most of my source code was being loaded to the crio.  This was causing major problems since GUI libraries were being loaded as well and were causing failed builds.  By the end, i couldn't' figure what was loading what and moved everything out of libraries.  This action alone quickly cleared up the issues i was having and was a huge lesson learned.  I do use labview classes, but i'm very careful to keep them limited and try not to cross reference files unless i know exactly what i'm pulling in.  

 

As far a name spacing goes, that is a huge issue and i'm not sure how to address it.  I'm pretty much a solo developer so i don't brush up against code from others often and i have my own naming scheme.  

 

 

On thing i would like to mention is that i try to handle my labview reusable code similar to what i've seen in Nodejs NPM and Python PIP.  I try to load as many dependencies below the project folder as possible so that i have a single dependency path for my project file.  Any of the re-usable code i generate are in separate repo and is checkout'd into a separate folder just below that main project file. I then ignore this folder in source control (GIT).  Basically i treat my git repos as libraries instead of using labview libraries to contain it all.

 

VIPM is an awesome tool and i use it a lot, but it seems to me that Labview should look as making its dependencies as modular as some of these other languages.  If you could "install" this reusable code to the project folder instead of your vi.lib or user.lib folder it would make sharing code a lot more easier.  Maybe you can do this already with VIPM and i just haven't found it.  Obviously this is problematic for how pallets are used within Labview, but i think it would be a good start.

 

I probably got off topic as well but just some thoughts.

 

PS: Can someone please fill me in on why the individual class and library window don't show dependencies.... its so frustrating.  

  • Like 2

Share this post


Link to post
Share on other sites

On thing i would like to mention is that i try to handle my labview reusable code similar to what i've seen in Nodejs NPM and Python PIP.  I try to load as many dependencies below the project folder as possible so that i have a single dependency path for my project file.  Any of the re-usable code i generate are in separate repo and is checkout'd into a separate folder just below that main project file. I then ignore this folder in source control (GIT).  Basically i treat my git repos as libraries instead of using labview libraries to contain it all.

 

VIPM is an awesome tool and i use it a lot, but it seems to me that Labview should look as making its dependencies as modular as some of these other languages.  If you could "install" this reusable code to the project folder instead of your vi.lib or user.lib folder it would make sharing code a lot more easier.  Maybe you can do this already with VIPM and i just haven't found it.  Obviously this is problematic for how pallets are used within Labview, but i think it would be a good start.

Yes! Just Yes!

 

Would love to do this with VIPM in LabVIEW

Share this post


Link to post
Share on other sites

"I do use labview classes, but i'm very careful to keep them limited and try not to cross reference files unless i know exactly what i'm pulling in."

Fantastic!

 

"I had multiple instances of strange cross dependencies loading so much that by the end of the day most of my source code was being loaded to the crio.  This was causing major problems since GUI libraries were being loaded as well and were causing failed builds.  By the end, i couldn't' figure what was loading what and moved everything out of libraries.  This action alone quickly cleared up the issues i was having and was a huge lesson learned."

Hmm..., this just means the code in the libraries you managed as assembled into these libraries had unintended dependencies.  Sure, pulling items out of libraries can separate things until you get rid of unused dependencies, but then the groupings are obsoleted as well.  The better thing is to fix the libraries so they have the proper dependencies.  (I would fix--or not use--any library that has improper dependencies, as far as possible.)

An easy way to see the dependencies of a library (.lvlib)--or anything else--is to open a new project and drop the library (or other item) alone into the the new project.  Then look at the dependencies.  My advice is to get used to paying close attention to what is in the dependencies--for everything--not just libraries.  This will help you make the code design and architecture better.  Again, this isn't a problem with the library concept itself but misapplication of it in specific libraries.  It seems clear that this sort of management (what belongs in a project, or in a library, or in a class, and how these link to one another) deserves more attention in training or other materials.

 

Paul

  • Like 1

Share this post


Link to post
Share on other sites

"I had multiple instances of strange cross dependencies loading so much that by the end of the day most of my source code was being loaded to the crio.  This was causing major problems since GUI libraries were being loaded as well and were causing failed builds.  By the end, i couldn't' figure what was loading what and moved everything out of libraries.  This action alone quickly cleared up the issues i was having and was a huge lesson learned."

Hmm..., this just means the code in the libraries you managed as assembled into these libraries had unintended dependencies.  Sure, pulling items out of libraries can separate things until you get rid of unused dependencies, but then the groupings are obsoleted as well.  The better thing is to fix the libraries so they have the proper dependencies.  (I would fix--or not use--any library that has improper dependencies, as far as possible.)

An easy way to see the dependencies of a library (.lvlib)--or anything else--is to open a new project and drop the library (or other item) alone into the the new project.  Then look at the dependencies.  My advice is to get used to paying close attention to what is in the dependencies--for everything--not just libraries.  This will help you make the code design and architecture better.  Again, this isn't a problem with the library concept itself but misapplication of it in specific libraries.  It seems clear that this sort of management (what belongs in a project, or in a library, or in a class, and how these link to one another) deserves more attention in training or other materials.

 

Paul

I'm with paul on this one. I think I said this earlier in the thread but my group ran into some of the same issues on a project and ended up in a pretty terrible state, with things like the excel toolkit being pulled onto the cRIO. Careful management of dependencies is pretty easy to ignore in LabVIEW for a while but it bites you in the end.

Share this post


Link to post
Share on other sites

I'm with paul on this one. I think I said this earlier in the thread but my group ran into some of the same issues on a project and ended up in a pretty terrible state, with things like the excel toolkit being pulled onto the cRIO. Careful management of dependencies is pretty easy to ignore in LabVIEW for a while but it bites you in the end.

 

But these aren’t real dependancies.  "A calls B which calls C†is a dependency of A on C.   “A calls B which is in the same library as X, which calls Y, which is in a library that also has Z, which calls C†is not.  I have no interest in managing false dependancies introduced by lvlibs.  

  • Like 1

Share this post


Link to post
Share on other sites

But these aren’t real dependancies.  "A calls B which calls C†is a dependency of A on C.   “A calls B which is in the same library as X, which calls Y, which is in a library that also has Z, which calls C†is not.  I have no interest in managing false dependancies introduced by lvlibs.  

 

 

This is the real problem.  To simplify my example i had two classes in a library.  One was a GUI Class and the other was a Hardware class.  I did this to group them together for ease of reuse in future projects.  However, I had no intention of using the GUI class on the CRIO so when i re-used my hardware class, i had no idea that the gui class would become a dependency solely b/c they were both in the same library.   My GUI class used subpanels and all sorts of things that CRIO's don't' like and was causing a hard crash out of lab view every time i tried to build my real time application (totally separate issue but also a learning experience).  Granted i was not as familiar with libraries as i am now but still it is confusing and while training may help it seems counter intuitive.  

 

Paul's suggestion of loading the libraries into an empty project is what eventually helped me track down my issues, and i was familiar with that method from older posts on this forum.  As a side note its a decent way to track down corrupt classes and libraries as well. But all of that just gets me back to, why doesn't the individual class or library "project window" show the dependencies of the library/class.  

 

I was basically looking for a way to group similar code so that i could re-use it for later projects and what i learned is that instead of libraries i should use GIT repos or VIPM and leave it at that.  

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By GregFreeman
      I am running calls to a various stored procedures in parallel, each with their own connection refnums. A few of these calls can take a while to execute from time to time. In critical parts of my application I would like the Cmd Execute.vi to be reentrant. Generally I handle this by making a copy of the NI library and namespacing my own version. I can then make a reentrant copy of the VI I need and save it in my own library, then commit it in version control so everyone working on the project has it. But the library is password protected so even a copy of it keeps it locked. I can't do a save as on the VIs that I need and make a reentrant copy, nor can I add any new VIs to the library.
      Does anyone have any suggestions? I have resorted to taking NIs library, including it inside my own library, then basically rewriting the VIs I need by copying the contents from the block diagram of the VI I want to "save as" and pasting them in another VI.
    • By Petr
      I'm not able to solve DVRs problem. See project file.
      1. IO.lvlib exists in two versions: one with single variables + processSimulation.vi that simulates process/machine i.e. takes outputs, calculates process behaviour and writes inputs; the second version of IO.lvlib has variables as IOaliases. Simply swaping these two versions allows to run project on real target with machine or to run project on PC without target/machine. Thats why I use these IO.lvlib variables.
      2. Every subsystem is an object/class with method DoSomething that calculates response to inputs and writes outputs.
      3. I¨d like to call these objects DoSomething.vi method in one loop. Thats why it's not possible to have inputs/outputs as terminals of DoSomething.vi
      4. I've tried to solve the problem with DVRs: every object is created by constructor including inputs/outputs DVRs initializing. However I'm not able to use DVRs inside DOSomething method. What am I doing wrong?

      One solution is to avoid loop call and spread all (about 50) DoSomething.vi calls including inputs/outputs terminals onto block diagram. But this is definitely not well arranged solution.
      Do you see anything wrong concerning my solution in general? How to access DVR inside class method? Any other ideas, comments? Thanks.
       
       
      IOrefs.zip
    • By drjdpowell
      I cannot figure this out.
       
      I made some changes to the private data of a class that caused the various unbundle nodes to get mislinked when they tried to auto-select the right new elements, leaving several broken methods.  No problem, I thought, I will revert to the previous clean copy in Source-code control (using TortoiseHg).   However, whenever I reopen the class, the unbundle nodes are still mislinked and VIs are broken!   I reverted the entire codebase to a week ago to be sure I had a good copy, and I rebooted the computer — still broken!   All my methods, even the unbroken ones say they need to resave because “Type Definition modifiedâ€.
       
      My question is: what is modifying my “Type Definitionâ€?   It can’t be any of my source code, so what can it be?   Where is the change located on disk?
    • By cgiustini
      Hey,
       
      I am going to be developing a lot of .lvlibs for reuse by others, and I would like to quickly generate documentation for them. I started programming a tool that recursively looks through a library by using the "Owned Items[]" property and iterating through those in order to find folders, .vis and .ctl. Then using the "VI Documentation VIs", the tool would just output a word document that contains VI icons, terminal lists, and descriptions. Does a similar tool already exist? I would gladly use such a tool if it already does.
       
      C
       
       
    • By JimboH
      I've been using Labview for 6 years now for research and one of the most confusing things for me is how code is supposed to be managed. I have been using Tortoise SVN with folder organization but with things getting more complicated I am starting to wonder what the "right" way of doings things is.
      I've looked through a variety of posts and official documentation and haven't found what I am looking for (or haven't realized it was what I needed).
      I'm using LV2009 32 bit, JKI TotoiseSVN Tool 2.2.0.186 (demo), Tortoise SVN 1.7.6, Win 7 x64, and have little interest in actual code deployment.
      Features I am looking for:
      - avoiding cross linking problems
      - prompts to save a vi only when it has been changed
      - svn integration
      - code that works with multiple developers instead of corrupted files (mainly thinking about project files)
      My code base consists of project or modules (not lvproj) just a set of code in a directory & subdirectories. When I am running a program, many of these modules will run together and collect data, with a messaging system in between where necessary. In addition I have generic code libraries (not lvlib), with generic functions (math, string, table, server, etc). It seems like my code libraries should be lvlib files. After some reading it seems like Project Libraries can be used for preventing namespace collisions. On a side note the term Labview Project Libraries is very confusing because I think of Labview Project Explorer which I have no gathered does nothing for changing the namespace. I did happen to find this link, which helped get me started but I'm still not understanding some things.
      As a general rule I pretty much want library membership to always apply to files that are in my libraries directory, which doesn't seem possible.
      Question 1: How do I delete a library file via SVN and remove it from the project. I am using the JKI TSVN toolbox and removal of the file doesn't seem to effect removal from the library.
      Question 2: If I create a vi and later decide to move it into the library, how do I accomplish this in Labview with SVN tracking. For example, if I create a vi in one of my modules and realize that it is fairly generic and would be better in a library, how do I move it to the library (ideally on disk and into the library file) so that both Labview and SVN are happy. Another situation might be moving a file from one module to another module, ideally I could move both library association and disk location.
      Question 3: If I am running multiple modules, how do I ensure that they have no namespace collisions? Should these be libraries as well? Do I only need a project if I want to deploy my code?
      Question 4: When someone creates a vi outside of the library but in the library directory how can this be detected and fixed?
      Question 5: Is there any way to get better svn integration into the lvlib and lbproj right click menu? My current approach would be to do this through the tools menu (tools -> TortoiseSVN -> rename). Side note, this doesn't doesn't currently work on my computer although the actual TortoiseSVN through Windows Explorer works just fine.
      Question 6: My files are constantly prompting for saving. It seems like most of these are changes from other files and not the file I changed. Since I don't know really know how this works I am not sure what exactly is going on. The end result though is that I want to minimize version changes (as tracked through SVN). I seem to remember reading somewhere that in LV2010 you can separate source code and compiled code. Thoughts? Would this be fixed by better lvlib and lvproj usage or is something else going on?
      Thanks,
      Jim
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.