LabVIEW Class Dependency Viewer: Part 2

1/22/2016

While cleaning the code up behind the dependency viewer I was able to improve its performance by about a factor of 100. I will tell you how I did that and also give you some detail on how this thing works in this post. You can download the Class Dependency Viewer as a VIP at the bottom of this page.

So how did I get 100x gains in efficiency? Sadly, it had nothing to do with my abilities as a programmer. It turns out that there is no way to get a list of a dependencies for a class using public VI Server calls. Since the whole point of the tool is to visualize how classes depend upon one another I had to brute force a solution. I was using VI Server to open a *.lvproj in the background and adding one class to it at a time, using the project API to scrape the dependencies from the class, removing that class from the project and repeating. Yikes, right?

I was complaining about this to fellow LabVIEW Champion Chris Relf and he recommended pinging NI to see if they could help. NI was great and got back to me right away with a solution, an internal method capable of taking in a path to a LabVIEW file and returning all of its dependencies. Thanks NI!

So with access to the internal method I refactored the code behind the Dependency Viewer and built a Tools menu plugin for it and a VI package to distribute it. Here is a demo of the new version:

As you saw in the demo the code is pretty simple, we are using the internal method that NI gave us to find dependencies of each class in a project, and then we build up a dependency matrix. Once we have the dependency matrix in hand we can do anything we want with the data.

As I mentioned I built the tool into a VI Package and have attached it to this page (LabVIEW 2014 and higher as I don't have access to anything older at the moment). Once you have installed the VIP you can find the code at "C:\Program Files (x86)\National Instruments\LabVIEW 2014\project\_Class Dependency Viewer". All of the HTML, JavaScript and CSS are in the "_public" directory, and the rest is vanilla LabVIEW.

If you do end up making any updates or finding any bugs please let me know. Also, if you have any question you can ask them in the comments section below and I will get back to you as quickly as I can.

Jon McBee is a Principal Software Engineer at Cambridge NanoTech and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, and a LabVIEW Champion

VIP download moved to the tools page.

18 Comments

Mike King

1/29/2016 01:12:57 am

Great tool Jon and nice improvements now. Thanks for building it and sharing it out, hope to make use of it as well.

Emmanuel Beraud link

2/1/2016 04:42:41 pm

Very nice tool, what do you think it would take to have a similar tool for lvlib instead of lvclass? This would be extremely handy for my team!

2/1/2016 06:44:38 pm

Hi Emmanuel,

This tool could be extended to handle lvlibs without too much trouble. All this extending makes me wish I had used OOP to write the tool itself

Emmanuel Beraud

2/2/2016 08:48:51 pm

I started taking a look but hit a wall at the password-protected Read Linker Info (Wrapper).vi.

It the code is protected, do you think you could quickly add the option to show library dependencies instead of class dependencies? Sorry to be pushy, I'm just very excited about the possibilities. There is really no equivalent out there, LabVIEW itself offers a Class hierarchy but no Library hierarchy.

2/3/2016 10:00:14 am

Hi Emmanuel,

I just posted a new VIP that adds the ability to run the tool against LVLIBs. It is v1.0.0.8 of the VIP. There is now a "File Type" selector to the right of the project selector, simply select your project and then select "*.lvlib" as the file type and it should work. I haven't thoroughly tested the LVLIB portion of the tool so if you find any bugs let me know and I will fix them for you.

I also wanted to mention that the "Read Linker Info (Wrapper).vi" is a wrapper around an "internal method" that NI gave me specifically for this project. NI put the password protection on the VI, but as I understand it the only thing on the block diagram is the method.

Thanks
Jon

2/3/2016 12:27:06 pm

Thanks, this is great. May I make 2 suggestions:

- Possibility to hide libraries from vi.lib
- Possibility to show the direction of the dependencies (if we want to know if A depends on B or the opposite). In particular, it would be very useful to highlight circular dependencies.

Also one remark: One of my libraries contained 3 nested libraries. In the tree they showed up as 4 libraries with the same name (the name of the 'parent' library). Not too sure how to handle that.

Thanks again for that tool, I will use it to show my team and my boss the 'before' and 'after' the code re-factorization I've been working on for a few weeks now.

2/3/2016 03:27:48 pm

Hi Emmanuel,

I had some time over lunch and was able to fix the .lvlib nesting issue in the tree structure and add the filtering of items from vi.lib for you (its through the right click menu).

Check out the new VIP v1.0.0.9

Let me know if you find anything else.

-Jon

2/3/2016 04:22:27 pm

Thanks for being so fast. This is my feedback:

--> Disabling vi.lib seems to "undo" the 1st order filter and vice-versa.

--> The nesting still looks weird. My gie.lvlib contains giec.lvlib, giei.lvlib, and giex.lvlib. The latter one also contains a nested library: gxml.lvlib. But the tree contains:

gie.lvlib
- gie.lvlib
- giex.lvlib
gxml.lvlib
giex.lvlib
giei.lvlib
giec.lvlib

The "-" indicates an expansion symbol, which is in the expanded state.

(Don't sweat it too much, I don't see nested libraries as such a necessicity or even such a good idea for that matter)

2/3/2016 04:26:58 pm

2/3/2016 04:29:13 pm

WT*! Last try:

__gie.lvlib
_- gie.lvlib
__- giex.lvlib
____gxml.lvlib
___giex.lvlib
___giei.lvlib
___giec.lvlib

2/4/2016 08:28:55 am

Hi Emmanuel,

I appreciate you feeding this info back to me, and I apologize for having you act as a beta tester. I worked on the tool last night and was able to fix the issue you are seeing with the vi.lib filter overriding the first order filter. You can find these updates in v1.0.0.10 above.

I decided to keep allowing the first order filter to override all other filters (i.e. the vi.lib filter) as it could be misleading if the first order filter did not update the tree to represent only first order dependencies (but I could be convinced otherwise).

The indentation bug you found with the lvlibs in the tree was a stubborn one, but I believe that I have fixed it. I tested with a more deeply nested lvlib structure and it appears to be working as it should. I would like you to run it against your code to verify. I wouldn't be surprised if I were still missing edge cases (unfortunately).

Best Regards,
Jon

2/4/2016 04:42:17 pm

It is working great. Thanks Jon!

2/3/2016 12:49:46 pm

Hi Emmanuel,

I like your suggestion of hiding libraries form vi.lib, I will look into adding that. I think you will be able to see the direction of the dependencies if you use the Dependency Wheel, as of right now the directionality is not visible with the force directed graph though (as you point out).

The nested library issue is definitely a bug, it works when viewing classes but I didn't test it with the lvlib file types. I will look at fixing that one this evening if time permits.

I am also working on adding some quantifiable results to the tool, stay tuned for that as it will make it easier for your to show your boss how your efforts have paid off.

-Jon

Paul Ross

2/4/2016 10:40:33 am

Hi Jon,
Would it be possible to get a version for LV 2013?
Thanks,
Paul

T.L.

2/17/2016 07:37:15 am

Hi,

I like this tool very much.
Could you provide on update a notification here

https://decibel.ni.com/content/docs/DOC-46678

so I will never miss an update on that package anymore?

Thanks,
Thomas

2/17/2016 08:49:36 am

Hi TL,

I will be sure to do post on the NI community page when an update is released. Look for a major update to come out in early March, I have added functionality for quantifying cohesion and coupling between classes and am working on adding metrics at the package/component level as well.

Thanks,
Jon

Eric Beutlich

6/2/2017 06:04:29 pm

I love this tool!
I'm confused what the colors mean? Also, where is the github for this project?

6/9/2017 10:20:18 am

Hi Eric,

The colors just denote unique classes/packages and are built into the D3.js library. Composed Systems is currently working on putting together an updated code base that we will open source through our Bitbucket page.

Thanks,
Jon

LabVIEW Class Dependency Viewer: Part 2

Leave a Reply.

Tags

Archives

LabVIEW Blogs