Leaderboard

"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

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.

Who likes to resurrect 6 year old posts...this guy. So over the years I've updated my LabVIEW Tray Launcher tool. It has very similar functionality as the one mentioned 6 years ago, but with some new features, and a few features that are the same but done better. Launching, killing, and restarting LabVIEW versions should work on all versions, but it is untested with 64 bit versions. It has been tested in 64 bit Windows, with 32 bit LabVIEW. Aborting VIs should work on all versions 2011 a newer. Older versions can be supported with more effort. Aborting VIs don't abort asynchronous clones. LabVIEW Run-time, or development 2011, 2012, 2013, or 2014 needs to be work. Others can be supported with more effort. By default opening VIs, and CTL files is done through this program and not LabVIEW. This allows these files to be opened in the right version. Other file types have varying level of support, but should work if they are added to the settings. If multiple versions of LabVIEW can open a file a dialog will show the available options. If only one version of LabVIEW can open the file it will open it with that version. If multiple versions of LabVIEW can open a file, but one is open already that can open it, it will open it with that version. If Shift is held when opening the file, a prompt will always be shown giving the option of what version to open it with. When opening the file VI Server is used, so unique server ports are needed between LabVIEW versions. If VIPM is configured and works, so should this. Pressing CTRL at the LabVIEW selection screen will open it in the default version of LabVIEW, or the oldest if the default isn't an option. This is all hosted on my personal site for now. It is a little large for a forum post, and the Code Repository blocks it, probably because it contains EXEs. So for now it will live on my site here.

Well, it seems I should be able to do something here, sans Mac support, if I leave all the encoding stuff out. There is a potential problem about extended ASCII characters in filenames inside the archive that has existed since the beginning and caused some problems in the past that I was trying to tackle. But no matter what I try to do, it always turns out to cause problems somewhere. So I have started to remove all the encoding translation from the current version in order to get a version out that should be functionally at least the same as older versions of the OpenG ZIP library (but support the new 64 bit platforms and the RT systems). It will still badly fail for filenames that contain extended characters but I'm not really anymore sure it's useful to try to fix that. I might try to add later some simple conversion function on LabVIEW level to handle those filenames a little more gracefully when extracting an existing archive (there is no way to guarantee letter for letter matching between the original archive name and the resulting file name after extraction since LabVIEW doesn't support Unicode filenames yet) but it will at least extract the files to a similar name. As I'm going to ski vacation at the end of this week I don't think I will be able to create a fully featured OpenG package but will try to post a preliminary and limited tested package here before that.

Let me know if you come across a crystal ball.vi to compliment it that tells us what LabVIEW version the VI reading our data is.