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

Designing LabVIEW NXG: Libraries

Member

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

 

 

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-Ins

 

  

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

Comments
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?

nrp
CLA
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.

Member

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?

Member

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.