Should I abandon LVLIB libraries?

[drjdpowell]

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.   

[JamesMc86]

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).

[drjdpowell]

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.

[JamesMc86]

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.

[drjdpowell]

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?!?

[smithd]

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. 

[drjdpowell]

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.

[PaulL]

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.

[ak_nz]

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 

[drjdpowell]

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.

[PaulL]

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.

[torekp]

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.

[PaulL]

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!

[Rolf Kalbermatter]

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.

[LogMAN]

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 ). I would rather see something like a "Namespace" type of object in LabVIEW.

[Steen Schmidt]

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

[Steen Schmidt]

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

[LogMAN]

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

[LogMAN]

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

[odoylerules]

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.  

[JamesMc86]

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

[PaulL]

"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

[smithd]

"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.

[drjdpowell]

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.  

[odoylerules]

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.