Should I abandon LVLIB libraries?

[PaulL]

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.  

I understand.  Fair enough.  I think we all agree that A and B in drjpowell's second case, which correspond to odoylerules' Hardware and GUI classes, shouldn't be be in the same project library.  I think we also agree that pitfalls like these are not immediately obvious to all those who design LabVIEW applications.  My experience, once I understood how library dependencies work, was that it was advantageous to use project libraries when needed, putting A and B in separate project libraries as appropriate.  Once I knew the rules this was not difficult, and it even drove me to end up with very clean projects with code in easily reusable packaged, namespaced libraries; in my experience it was well worth the effort.  This is a good capability to have, but does require careful application.

[drjdpowell]

But libraries don’t need to just be a good capability to have for the very advanced programmer who has learned to use them carefully “when neededâ€.  Libraries could be broadly useful at a range of ability levels and for a wide variety of things.

[PaulL]

But libraries don’t need to just be a good capability to have for the very advanced programmer who has learned to use them carefully “when neededâ€.  Libraries could be broadly useful at a range of ability levels and for a wide variety of things.

Fair enough.  My perspective is that we need to equip a broader range of developers with an understanding of interfaces, etc., so that they can use project libraries effectively.

Look, I think the loading-of-dependencies approach is consistent (the loading of parent libraries, maybe less so) with LabVIEW's overall linking model, and I think there would be trade-offs if LabVIEW were to depart from that model.  I think it is straightforward to work with that model, in such a way that project libraries are helpful (in certain circumstances), especially when coupled with interfaces, so I don't think it is helpful just to bash the project library concept.  It is a useful concept!  Perhaps proposing an alternative concept that would address competing needs would be more likely to yield results.  Keep in mind, though, the LabVIEW IDE's overall approach to loading dependencies.  Changing that may be more convenient for some use cases, but it would have to be in a manner such that it would be obvious to a broad range of developers, even me!

Are there examples from other development environments that more closely represent what you need?

[shoneill]

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.

 

/Steen

 

I just offloaded a portion of our main application code into lvlibs and when building the executable, placed them outside the exe itself.  Where did I put them? In an LLB.  The LLB contains only the library and it's members.  Isn't that (more or less) your point 4) ?

 

I use normal lvlibs in development but the application builder slaps them into an LLB for our application (and automatically re-links to the LLB of course).

[Rolf Kalbermatter]

I just offloaded a portion of our main application code into lvlibs and when building the executable, placed them outside the exe itself.  Where did I put them? In an LLB.  The LLB contains only the library and it's members.  Isn't that (more or less) your point 4) ?

 

I use normal lvlibs in development but the application builder slaps them into an LLB for our application (and automatically re-links to the LLB of course).

 

Which LabVIEW version? According to my own tests some time ago, there was no way to get lvlib, lvclass or similar >= LabVIEW 8.x files into an LLB.

[LogMAN]

Which LabVIEW version? According to my own tests some time ago, there was no way to get lvlib, lvclass or similar >= LabVIEW 8.x files into an LLB.

It's working since 8.6.1 at least.

[shoneill]

In my build spec, I define a target directory, tell it to store it in an LLB and then just put the lvlib (and all lvlib files) in there.  Seems to work fine.

 

OH, and LV 2012 SP1

Edited September 18, 2015 by shoneill

[drjdpowell]

Which LabVIEW version? According to my own tests some time ago, there was no way to get lvlib, lvclass or similar >= LabVIEW 8.x files into an LLB.

 

I think they mean creating Destinations set to LLB on the Destinations tab of the EXE build spec.  I tried putting LVLIBs in these Destinations and it seems to work.  

 

Added later>> shoneil posted while I was experimenting.

[vekkuli]

This thread got me to reorganize my workspace and project structure to most importantly improve load and build times and reuse workflow. It came to me as a surprise that LVLIB's although great in some ways force static links to everything in the library. I had previously seen this with classes but for some reason didn't expect the same from LVLIB's. Anyway, I ended up breaking apart a lot of reuse code and restructuring a large project. This seemed obviously a pretty daunting task at first and I was looking to utilize the "links" application by JackDunaway/Wirelabs. Unfortunately, I didn't manage to get it working fully so what I ended up doing was grabbing the hidden "App.Read Linker Info From File" invoke node from the code and searching the list for items where links jump to unintended libraries etc. The few hours of work were definitely worth it and I can recommend similar procedure to anyone starting to see the effects of unwanted coupling.

[Mads]

On 9/18/2015 at 10:36 AM, shoneill said:

In my build spec, I define a target directory, tell it to store it in an LLB and then just put the lvlib (and all lvlib files) in there.  Seems to work fine.

 

OH, and LV 2012 SP1

Any tricks to this? (I'm using LV2018)

If I try to target an lvlib to an llb (because I want the llb to be a single file, to be used as a plugin), I keep getting several folders outside the llb, and none in the llb. This is with the whole lvlib included and the destination set to an output directory set to be an llb.

Right now the lvlib I want included in an llb is the JKI Serialization.lvlib, which has classes included as well so it is not the simplest lvlib. I have tried all kinds of variations on where to target dependencies too..Including the lvlibs in the executable seems to be the only way to get everything nicely packaged into one file, but in this case I do not want to update the executable, I want it portable with a/several plugin(s). Not excluding unused items and allowing the build to modify libraries seem to help avoid subVIs ending up in directories outside of the target directory in some instances, but it does not help getting lvlibs into an llb. The second tidiest working solution seems to be to target the lvlibs to a directory. That fills the directory with hundreds of files (a mess I do not like), and you might get into naming collisions if you point several lvlibs to that directory because the name spacing is not kept (could have automatically separated the subVIs to namespaced folders e.g.). Using packed project libraries is perhaps one solution, but that is cumbersome, especially when dealing with lots of different targets.

Edited November 11, 2019 by Mads

[shoneill]

29 minutes ago, Mads said:

Any tricks to this? (I'm using LV2018)

I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name).

I suppose the PPL is the proper replacement for this now, although that's not source code....

[Mads]

1 hour ago, shoneill said:

I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name).

I suppose the PPL is the proper replacement for this now, although that's not source code....

Ah, it's just the classes that mess things up then.

One more vote for the idea of a single file distribution for classes then on the idea exchange... (or even better as fabions mentions in the comments; an upgraded and backwards compatible llb format with support for subdirectories? 👍).

[Rolf Kalbermatter]

6 hours ago, Mads said:

Ah, it's just the classes that mess things up then.

One more vote for the idea of a single file distribution for classes then on the idea exchange... (or even better as fabions mentions in the comments; an upgraded and backwards compatible llb format with support for subdirectories? 👍).

The upgraded LLB almost certainly never ever will happen. The lvclassp or whatever it would be called probably neither because you can do that basically today by wrapping one or more lvclasses into a lvlib and then turning that into a lvlibp.

While these single file containers are all an interesting feature they have many potential trouble as can be seen with lvlibp. Some are unfortunate and could be fixed with enough effort, others are fundamental problems that are hard to almost impossible to be really done right. Even Microsoft has been basically unable to plugin an archive system like a ZIP archive into its file explorer in a way that feels fully natural and doesn't limit all kind of operations that a user would expect to be able to do in a normal directory. Not saying it's impossible although the Windows Explorer file system extension interface is basically a bunch of different COM interfaces that are both hard to use right and incomplete and limited in various ways. A bit of a bolted on extension with more extensions bolted on on the side whenever the developers found to need a new feature. It works most of the time but even the Microsoft ZIP extension has weird issues from using the COM interfaces in certain ways that were not originally intended. It works good enough to not having to spend more time on it to fix real bugs or to axe the feature and let users rely on external archive viewers like 7-ZIP,  but is far from seamless.

At least for classic LabVIEW I think the time has come where NI won't spend any time in adding such features anymore. They will limit future improvements to features that can be relatively easily developed for NXP and then backported to classic LabVIEW with little effort. Something like a new file format is not such a thing. It would require a rewrite of substantial parts of the current code and they are pretty much afraid of touching the existing code substantially as it is in large parts very old code with programming paradigms that are completely the opposite to what they use nowadays with classes and other modern C++ programming features. Basically the old code was written with standard C in ways that was meant to fit into the constrained memory of those days with various things that defies modern programming rules completely.

Was it wrong? No, it was what was necessary to get it to work on the hardware that was available then, without waiting another 10 years to have on the architecture and hope to get the hardware that makes a modern system able to run, with programming paradigms that were nowhere used at that time.

Edited November 11, 2019 by Rolf Kalbermatter

[Mads]

2 minutes ago, Rolf Kalbermatter said:

The upgraded LLB almost certainly never ever will happen. The lvclassp or whatever it would be called probably neither because you can do that basically today by wrapping one or more lvclasses into a lvlib and then turning that into a lvlibp.

While these single file containers are all an interesting feature they have many potential trouble as can be seen with lvlibp. Some are unfortunate and could be fixed with enough effort, others are fundamental problems that are hard to almost impossible to be really done right. Even Microsoft has been basically unable to plugin an archive system like a ZIP archive into its file explorer in a way that feels fully natural and doesn't limit all kind of operations that a user would expect to be able to do in a normal directory. Not saying it's impossible although the Windows Explorer file system extension interface is basically a bunch of different COM interfaces that are both hard to use right and incomplete and limited in various ways. A bit of a bolted on extension with more extensions bolted on on the side whenever the developers found to need a new feature. It works most of the time but even the Microsoft ZIP extension has weird issues from using the COM interfaces in certain ways that were not originally intended. It works good enough to not having to spend more time on it to fix real bugs or to axe the feature and let users rely on external archive viewers like 7-ZIP,  but is far from seamless.

At least for classic LabVIEW I think the time has come where NI won't spend any time in adding such features anymore. They will limit future improvements to features that can be relatively easily developed for NXP and then backported to classic LabVIEW with little effort. Something like a new file format is not such a thing. It would require a rewrite of substantial parts of the current code and they are pretty much afraid of touching the existing code substantially as it is in large parts very old code with programming paradigms that are completely the opposite to what they use nowadays with classes and other modern C++ programming features. Basically the old code was written with standard C in ways that was meant to fit into the constrained memory of those days with various things that defies modern programming rules completely.

Was it wrong? No, it was what was necessary to get it to work on the hardware that was available then, without waiting another 10 years to shave on the architecture and hope to get the hardware that makes a modern system able to run, with programming paradigms that were nowhere used at that time.

Sure. The idea exhange and the whole NXG vs current LabVIEW scenario always makes me think of one particular song by the Fugees...😉

[Rolf Kalbermatter]

35 minutes ago, Mads said:

Sure. The idea exhange and the whole NXG vs current LabVIEW scenario always makes me think of one particular song by the Fugees...😉

Well there could be two that apply! "Killing me softly" and "Ready or Not, here I come you can't hide" 😀

[Mads]

Hahaha, both of them apply very nicely 😆 I had only thought of the first one.

[ShaunR]

9 hours ago, Mads said:

Right now the lvlib I want included in an llb

It's the other way round. You include the files contained in an LLB in a lvlib. You end up with two files, the lvlib (XML description) and the LLB (the Vis).

Edited November 11, 2019 by ShaunR

[Mads]

1 hour ago, ShaunR said:

It's the other way round. You include the files contained in an LLB in a lvlib. You end up with two files, the lvlib (XML description) and the LLB (the Vis).

Not really, but that would be one way to attack it yes, if it was not for the classes.

[eberaud]

5 years later... Have things happened in the recent years with PPLs that would remove some of the reasons people may have abandonned them in the past? I was one of those people back in 2012, I'm thinking that 12 years later I could give them a try again...

[crossrulz]

I have been using PPLs in my architecture for many years with very little issues.  But I am generally using them in Windows only and the PPLs are pretty small.  I use the LabVIEW Solution Builder to build my core libraries.

I will also state that NI is actively working on the PPL build process behind the scenes.

[hooovahh]

Yeah multiple targets is the main issue I've had over the years. I have a great reuse library that is written well to work on RT or Windows. But making a single PPL for both targets is impossible. And having the palettes, and builds, and projects pull from the right PPL, and pull the other dependent PPLs, is such a major pain that I abandoned it.

[Rolf Kalbermatter]

Definitely can echo things. PPLs work fairly well when you only use one platform (Windows x86 and x64 are two different platforms in that respect). Basically a PPL is quite similar like a DLL in that respect, it is binary compiled code and only works in the LabVIEW platform that it was created in. In addition you also have to watch out about LabVIEW versions, although with the feature to make a PPL loadable in a newer LabVIEW version since about 2017 or so, this is slightly less of a problem, but not entirely. There are possible issues with executing a PPL in a newer LabVIEW version than in what it was created.

Where things really get wonky is if you want to support multiple platforms in LabVIEW. Different platform versions of PPLs in the same project is absolutely out of questions. You can't have a project that references a PPL under your My Computer target and the same PPL in a Realtime target in that project (same in name only, they obviously need to have been recompiled for each target). LabVIEW will get into a rats about that and render both targets as broken since it will try to match the two incompatible PPLs to both targets. But it is even worse than that! Even if you separate the two targets into their own projects you have to be extremely careful to never load both at the same time. For some reason the context isolation between LabVIEW targets (including targets in different project files that should be fully isolated in theory) simply doesn't work for PPLs. It seems that LabVIEW only maintains one global list of loaded PPLs across all possible contexts and that of course messes royally with the system. Instead PPLs should be managed based on the context they are referenced in and there should be no sharing at all between them.

There is also an unfinished feature in LabVIEW that allows to install PPLs and other support files in target specific sub directories, so that you could theoretically have PPLs for all the different targets on disk and reference them with the same symbolic path which then resolves to the target specific PPL. But it has many bugs and doesn't quite work as intended on some platforms and as long as PPLs are not managed on a context base it is also of limited usefulness even if it would fully work.

 

[eberaud]

My team and I didn't have any of those excuses back in 2012, we were running on Windows only, 'My Computer' target only, and were only dealing with LabVIEW 2011. We were probably guilty of starting coding without a clear enough understanding of how PPL work.

We thought we could create a Plugin archiecture based on PPL to avoid having close to a hundred plugins built inside the executable. But this created a 2-way dependency that made this impossible. I later realized that every dependency of the PPL needed to be themselves in PPL, but this felt like a lot of work and we gave up!

[Rolf Kalbermatter]

On 4/29/2024 at 10:43 AM, eberaud said:

My team and I didn't have any of those excuses back in 2012, we were running on Windows only, 'My Computer' target only, and were only dealing with LabVIEW 2011. We were probably guilty of starting coding without a clear enough understanding of how PPL work.

We thought we could create a Plugin archiecture based on PPL to avoid having close to a hundred plugins built inside the executable. But this created a 2-way dependency that made this impossible. I later realized that every dependency of the PPL needed to be themselves in PPL, but this felt like a lot of work and we gave up!

Not sure about 2011 to be honest, but no you do not have to have all dependencies included in a PPL. You can have a PPL depend on other PPLs and configure the build to exclude that dependency from you PPL build, so that it remains external. This has of course to be down from bottom up, which is quite a work. Only PPL dependencies and other binary dependencies can be excluded from being pulled into a PPL. So if you want code that has to be shared between your PPL and other PPLs or your exe, that code needs to be in its own PPL, so each of those can refer to it.

Yes it is not trivial and you need to plan before you start programming. You need to have a clear hierarchy overview and be able to cleanly modularize your code into different PPLs.

Tools like the MGI Solution Builder definitely help with that as you can script the creation of a whole hierarchy of PPLs to be compiled in the correct order. Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.

Edited April 30 by Rolf Kalbermatter

[crossrulz]

1 hour ago, Rolf Kalbermatter said:

Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.

That sounds like the LabVIEW Solution Builder, which I use.  It works quite well.