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

Designing LabVIEW NXG: Collaboration


As more and more businesses aim to leverage the power of collaboration, we want to ensure you and your team can develop and deliver efficiently in LabVIEW NXG while integrating with your company’s development systems. 


One challenge teams face while collaborating on the same project is ensuring that all systems are up to date with all the needed dependencies. Keeping everyone informed about which toolkits and drivers to use for a project can be difficult, especially if it’s a project you’re restarting after a while.


One improvement we’ve made in this area with LabVIEW NXG 3.0 is the addition of a new “Package Dependency Document” in the project. You can “capture” your project’s software dependencies by right clicking on it. From there, the tool will inspect your code and populate this document with information on the packages (including toolkits and drivers) that your project requires. When someone who doesn’t have these packages installed opens this document, they’ll be informed and shown a button to install all the missing packages.




Since VIs are binaries, we know that working with version management tools and LabVIEW can been challenging sometimes. To help, we were mindful of this in LabVIEW NXG and made the VIs xml based.


Another struggle with version management tools that some LabVIEW users shared involved dirty dots on the caller VIs. As a result of that feedback, we introduced concepts like the dependencies being managed by the project instead of VIs, and libraries assigning namespaces.


We also have a Compare tool that you can use to compare VIs as well as project files.



We aren’t saying things are perfect with LabVIEW NXG while collaborating in big teams. We still face many challenges like complicated xml, files getting dirty when not expected sometimes, and distributed version management workflows without the ability to lock files. However, some of the core decisions in LabVIEW NXG have set us up for easier version management and collaboration in the future. Give us your feedback on how we can best improve your collaboration experience in LabVIEW NXG.


Read more about designing LabVIEW NXG >>


Sumedha Ganjoo | LabVIEW R&D

I am already using Labview and Labview Nxg, but the problem that i almost always use cRIO and FPGA  platforms, in this case, NXG was not fully support my projects, also the jobs without cRIO still not satisfy me, because all the front panels that you can make %80 will be same, as i know there is no type definition feature yet?


Thanks for reaching out and providing this feedback.


We know that many customer applications today are using cRIO and we are planning to support it and other FPGA-enabled hardware, like our PCI and PXI Reconfigurable I/O Modules, in LabVIEW NXG. With LabVIEW NXG 3.0 we released the first FPGA Module, supporting a subset of FlexRIO hardware. We update the LabVIEW NXG roadmap after every release. Please follow it for more updated information on hardware support in releases.


On type definition support, LabVIEW NXG does have G Type support which is similar to type definitions. You can find more information about it here.


Please let me know if I missed something in your question. 




Sumedha Ganjoo | LabVIEW R&D
Active Participant

Is the expectation that Version Control Software will then be able to highlight and merge the differences in the VIs because they are XML based?

I'm having trouble picturing how that would remain stable without seeing an example of the XML descriptions of VIs - does the XML describe all objects and wires on the front panels and block diagrams?

The hardest part of using LV Compare/LV Merge in the past was actually the need for Absolute paths when the Version Control Software makes copies of the VIs and provides relative paths - intermediary code needed to be created to convert the paths.

Ryan Vallieu
Senior Systems Analyst II
NASA Ames Research Center