NI Blog

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Re: Designing LabVIEW NXG: Libraries


Libraries are an area of significant investment in LabVIEW NXG. They promote modular design and reuse and organize related functionality so code can be developed independently across organizations and companies.


We’ve spent significant time defining the goals and principles behind libraries because we need them to support a healthy ecosystem of developers and integrators. We want to use this post to give some insight into our ongoing design of libraries in LabVIEW NXG.






Namespacing is a key concept that we incorporated early in the development of LabVIEW NXG because we want it to be the main way that G programmers logically organize their code. Namespaces can help avoid collisions with libraries developed by other teams or companies.


LabVIEW NXG namespaces are defined independently from the library name. Libraries provide physical organization of code, but namespaces give you a way to provide logical even across library boundaries.


We also wanted the physical and logical organization of your code to be evident outside of LabVIEW, so libraries and namespaces aren’t just entities in the product. Library boundaries and namespaces are both reflected on disk as folders, which makes your code easy to navigate from the file explorer.  See Figure 1 for an example. 


libraries labview.png

Figure 1: The layout of your libraries and namespaces is the same in NXG as well as on disk.





Plug-in architectures are important to many of our customers, and we want to make libraries the backbone of these plug-in systems. In LabVIEW NXG you can compile your library into a binary library output. These binary libraries can be used at runtime to load arbitrary VIs and run them. For example: a test sequencer that runs any test steps in a certain location.


But these binary libraries are not just useful for test systems. A library has a certain interface—the set of VIs that are publicly exposed from the library. The library’s interface is a contract with its consumers and defines a description of the capability that library provides. The internals of a library can change and be enhanced over time without breaking callers if the interface remains compatible.


However, sometimes you want to break the interface and force the entire application to be rebuilt. For example, if you’re moving your application from desktop to real time, debugging will be very different on the headless real-time target. Your debugging library would need to be updated, and the interface would need to change, forcing the writer of the application at large to consider these changes and rebuild.


Our data indicate that only about 0.5 percent of LabVIEW customers build Packed Project Libraries (PPLs). While this number seems low, we understand the importance PPLs have for advanced applications, especially in test systems, and the work put in by the LabVIEW community to promote using them successfully. While there are some issues with PPLs, we aim to design a binary format that will support the LabVIEW NXG ecosystem for decades to come. The team has spent significant time understanding the uses of libraries in LabVIEW as well as thinking of all the ways we can use libraries in LabVIEW NXG.


We hope you find this peek into our design process useful, and look forward to hearing your feedback as we continue to design and implement libraries in LabVIEW NXG!


Read more about designing LabVIEW NXG >>

Active Participant

I am still not convinced that it is a good idea that the layout on disk of a library is forced to mimic the library structure. In current gen I have a strictly flat structure on disk for libraries and classes, and then organise as necessary in the library using virtual folders with varying levels of access scope.


Can somebody explain why virtual folders were considered to be such a bad thing that they were removed for NXG?

All your base are belong to us.
Active Participant

I am going to echo Neil's concern.  All I use are virtual folders.  Are these going to be removed in NXG?  Are these projects going to be autopopulating?  If so, this just seems like bad design to me - I don't necessarily want my project folders to reflect my physical folders as there is often a lot of junk in them during development (code that contains bad or not fully fleshed out ideas, documentation, etc etc) and I don't need that junk cluttering up the project space.  Why is this being dictated by LV?


> so libraries and namespaces aren’t just entities in the product


What are we defining as "product" here? The code? Or the actual application?  If it is the latter, than why should customers care at all about libraries or namespaces in relation to the product.


I agree with Neil, as I too use a flat structure within libraries/classes and use virtual folders, with NO auto-populating.

Having recently started exploring NXG, I erroneously assumed the folders were virtual until I checked the files on disk.

I don't understand the logic behind this decision, so could an NI person please explain?


First off, thanks everybody for reading the post and providing feedback. These conversations are the exact reason we wrote these posts!


I want to give a little more insight into our approach to file management in LabVIEW NXG, specifically around the area of organizing files on disk and in the editor. Also, we know that Virtual Folders are used often in LabVIEW, and I want to discuss how we are planning on providing the same functionality, albeit with different solutions, in LabVIEW NXG.


First, know that we don’t take these types of changes lightly. When we took on a change of this magnitude, we knew we must do our homework. To begin, we defined two primary goals:

  1. Create a predictable system for users to organize and reason about the code in the project, and
  2. Create a flexible and effective system for users to navigate to important elements when needed.

Then, we researched industry trends, we talked to LabVIEW programmers (both internal and external), and we modeled concrete use cases. We used those insights to design a solution that we are confident will meet programmers’ needs. Part of this solution is shipping in LabVIEW NXG today. Other elements are future design ideas that I’ll share in this post. We expect the combination will provide a powerful and efficient experience for managing your project files.


Let’s start with the Project Files pane in LabVIEW NXG. This is the place the user will look to find the full list of all files that participate in the static hierarchy for the project. This view is different from LabVIEW 20xx where the Project Explorer Window can show a subset of the project files, with the rest of the files accessible under the dynamic Dependencies category. We made this change to enable more predictable and controllable linking behavior of subVIs. However, a side effect of that change is that now the Project Files pane must display much more content than previous. As a result, we recognized that the patterns used to manage project files would ultimately need to evolve. This realization of change was reinforced as we introduced libraries and classes, both of which use disk folders as a natural mapping to the namespacing and containment concepts.


When deciding on the file layout, we looked at trends with other integrated development environments and languages as well as modeled real user projects to validate the choice. This file layout pattern is used by several other language/IDE combinations, and it was our opinion that given the large adoption of said patterns (for example, all Java programmers using Eclipse will see a similar view) it was a valid choice. Also, given that source-code control usage is high amongst users of other IDEs and textual languages, it follows that usage of source-code control with these types of disk structures works well and is widely accepted. Furthermore, with the general industry trend towards modern source-code controls systems such as git, the tracking of file moves is now less of an issue than in the past, as these new source-code control systems handle movement better than previous systems.


With regards to the second goal (navigation), we know that LabVIEW programmers use virtual folders to give them easy ways to access files that share similar logical properties such as access scope. We acknowledge that this kind of workflow is important and we intend to support it within LabVIEW NXG (in the future). To show these logical groupings, we are exploring designs that introduce more advanced filtering, sorting, and tagging to our table views of libraries and classes. For example, if I open a class document in LabVIEW NXG, I can see all the member VIs that make up the methods in my class. We are working on designs that make this table filterable so that I can only show public or private methods. Also, we are working on ideas for user-defined tags. Say you want to tag all the VIs that need more documentation. You would then be able to filter the table view for a library to only show these tagged VIs. With advanced filtering you will be able to view files by either built-in or user-defined categories, and we believe that this will provide one more major feature that virtual folders provide in the current product.


If anybody would like to discuss a particular use case, please post it here or contact me directly, and we can step through what that specifically looks like in NXG.


We want to provide efficient and powerful workflows for managing your projects. We are always looking for feedback, and we are excited to work closely with you, our LabVIEW community, to make LabVIEW NXG awesome.

Active Participant
With regards to the second goal (navigation), we know that LabVIEW programmers use virtual folders to give them easy ways to access files that share similar logical properties such as access scope. We acknowledge that this kind of workflow is important and we intend to support it within LabVIEW NXG (in the future).

I'm glad to see you are planning on supporting virtual folders in the future. Having the project view locked to the disk hierarchy is a drag. Like many others, while I maintain a flat disk hierarchy (typically each class/library is contained in its own directory in /src/), I want my project view to reflect more organization such as parent-child relationships, or the different software layers.


One of my use cases for actively changing the project view is when inheriting someone else's code. I typically spend several hours rearranging the project into something that makes sense to me while I'm learning the code. I'm not at all interested in moving files around on disk just so I can get a different view of the project.


Hey Daklu,


I wanted to reply to make sure there was no confusion.

We do not intend to bring virtual folders into LabVIEW NXG. However, we do intend to support all the functionality that virtual folders provided in LabVIEW NXG. We are just using different features in the product to provide that functionality.



Active Participant

So, I didn't comment earlier because I thought Daklu had seen something I had not, but since you are reinforcing the idea that for all intensive purposes Virtual Folders and their functionality are going away I will go ahead and comment on the long reply above.


> This file layout pattern is used by several other language/IDE combinations, and it was our opinion that given the large adoption of said patterns (for example, all Java programmers using Eclipse will see a similar view) it was a valid choice. 


First of all, ask most programmers using a text based language and they will agree - Eclipse is awful.  So, maybe this is not the best example? 


But, the second point related to this is that LabVIEW is not a text based program.  Functions are self contained units in LabVIEW, easily executed in standalone fashion as opposed to something like C where functions sit in modules or Java where every thing is a class (an arguably terrible paradigm).  In a text based language, if you want to move a function from one file to another it is simply a matter of cutting, pasting and making sure the module that any code you touch is properly referenced in the calling programs (modules imported etc).  In LabVIEW, you either have to 1) think very carefully about the physical layout before hand or 2) move the actual files on disk if you feel a function is better suited in another group.  If the latter (the more likely) case occurs, then the user will have to hunt this dependency down in a project and update it accordingly.  If NXG is anything like plain vanilla LV, this will entail right clicking on function and then going hunting through the file system for the new location - for every project that touches this code!   

Tbh, this desire to copy IDE paradigms like Eclipse and Visual Studio just seems like a terrible fit for LV (something that has bugged me since its unveiling in 2016 at NI week when I saw LV in what appeared to be a VS environment).  Graphical programming is just very different from text based programming such that what works in one does not work or is not easily portable to another...


Hey y'all, again, thanks for the feedback!

I want to be clear that we will eventually support the functionality that Virtual Folders provided, we are just not going to do it using Virtual Folders.

Also, we have heavily invested in refactoring functionality such that when you move VIs around between classes, libraries, and namespaces, we take care of updating references and moving the files on disk for you. You don't have to manually keep things in synch.


Proven Zealot

I know it's rather late in the game to comment, but this organizing is going to play hell with versioning software.  One of the major advantages of virtual folders was you could organize the files in virtual folders any way you like and have only the project/library files change.  Now it's a physical move as well, and every time you move a file, you'll have to reconcile it with whatever versioning software you are using, because it won't know that you moved the file.


What a hassle.

(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.

I've been curious about NXG for a few years and just converted a project over and first thing I wanted to do was create virtual folders for organization that makes sense to me. I've been frustrated with LabVIEW's windows hell for a couple of decades and welcome the MDI interface, but forcing us into a directory structure is a no-go for me. For example, we have a class, "I2C UI" in a central location for use in multiple projects to give our stuff a consistent look. It's friends with our I2C instrument classes that reside somewhere else entirely. Excuse me if I'm missing something, but forcing it into one projects directory doesn't make sense. If I want to reuse that class, how do add it to another project if it's already in a project? Do I have to copy it into the new project's directory?