LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoiding clutter in dependencies list while adding libraries

Solved!
Go to solution

What is the correct way to handle imported libraries in Labview 2015? It seems unlogical the way it is in my project at the time. As you can see in the attached image, I have 2 libraries attached. One is the Maxon - EPOS library and the other one is a DLL 90360 library. All the sub VI's that I use get cluttered up in the dependencies list. Now the program is still small but when it gets bigger there will be a huge amount of dependencies cluttered in the list.

- I have put the library (LLB file) in the instr.lib folder.
- I have inputted the vi's in the project
- All the inputted vi's end up in the dependency list.

I feel like there should be a better way, but I have not come across it.
Next I looked at importing the library like described here. But I cant figure out what is the functional difference between adding as file or adding as folders and what is the best way. Added to that, I don't know if this will fix the clutter.

Anybody got some ideas? Thanks.

------------------------------------
Change the way you act, eat, sleep, walk, talk ... and you still are the same person. Even though everybody says you are a different person.
0 Kudos
Message 1 of 3
(3,338 Views)
Solution
Accepted by johndoe773

Hi johndoe773,

 

Dependencies auto-populate based on whether or not they are called by VIs in the main project under your target.  With that in mind, anything that shows up under My Computer (or whatever else your target may be), will not show up as a dependent item.  Similarly, anything that actually is a dependent item for a VI under the main target that is not explicitly listed under your target will show up as a dependent item.  

 

I'm honestly not sure why your dependent items aren't showing up under an instr.lib dropdown since I've replicated this in 2015 SP1 and mine show up there.  See the attached picture.  If you have subVIs that are actively called from the top-level code that you are modifying, you can add those in a subVI folder under the target as shown in my screenshot.  It will take those items out of the Dependencies folder.  Since everything in Dependencies auto-populates, you won't be able to move items into folders; however, if you keep the project itself organized and let LabVIEW handle the dependencies, you should be able to keep things fairly clean moving forward.  

 

The help documentation also provides some lower-level tips on managing dependencies:  https://www.ni.com/docs/en-US/bundle/labview/page/managing-dependencies-in-labview-projects.html

 

Matt | NI Systems Engineering
Message 2 of 3
(3,263 Views)

From your reply I take note of:

- Let the dependencies be, they auto-populate and there is no sorting them

- Only add VI to the project in your folder that you modify, those will disappear from the dependency list

-- Side-note here: What negative side-effects are there for adding all sub VI's for organisation sake?

--- Example: Unused VI's unnecessary loaded into memory?

-- When still there is a desire to add full library: What is the difference (pro-con) to adding library as file or as folder?

 

Related to the difference in organisation of the library in your test case and my library. It could be that the initial library was imported the wrong way. I inherited the code from another colleague. Will look into reloading the sub VI's to try and improve this.

I guess I will learn to live with the dependency folder. However i feel like there could be an improvement in the long run for the NI Labview dev's to better organize the auto populated dependency folder.

 

Thanks for your reply Matt. I appreciate it.

------------------------------------
Change the way you act, eat, sleep, walk, talk ... and you still are the same person. Even though everybody says you are a different person.
0 Kudos
Message 3 of 3
(3,241 Views)