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.
Figure1: 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!