Jump to content

Recommended Posts

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.

  • Like 1
Link to post
Share on other sites
  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

LLBs and LVLibs solve different problems (and create different problems), and are not interchangeable or really related beyond sharing the word "library" in their acronyms.   Here are some character

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

@JackDunaway Great analysis with which I agree with 99.9% (except for your first sentence). You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and a

Posted Images

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.

  • Like 1
Link to post
Share on other sites

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?

Link to post
Share on other sites
  • 6 months later...

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 9 months later...

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.

  • Like 2
Link to post
Share on other sites
  • 3 years later...
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 by Mads
Link to post
Share on other sites
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....

  • Like 1
Link to post
Share on other sites
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? 👍).

Link to post
Share on other sites
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 by Rolf Kalbermatter
Link to post
Share on other sites
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...😉

Link to post
Share on other sites
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" 😀

  • Haha 2
Link to post
Share on other sites
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 by ShaunR
Link to post
Share on other sites
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.

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.