NI Blog

[Sumedha]

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

[TOLGAHAN_NI]

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?

[Sumedha]

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. 

Thanks,

Sumedha

[RVallieu]

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.

[Sumedha]

Hi Ryan,

Thanks for reaching out with feedback and questions!

---

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 VI XML can’t reliably be merged and diff-ed using text tools. If you open up the xml, there are some human readable parts like control names but the bulk of the file isn’t human readable. The benefit of xml over binaries is that many version control tools like Git work better with text-based files than binaries. When a file is binary, every commit is an override of the complete file versus if the file is text based Git can optimize how those differences are stored resulting in more efficient source control interactions. Differences in text-based files often take less storage than differences in binary files of the same size. Also, the VIs (xml files) are always “source only”, they aren't dirtied in most cases when you make changes to the sub VIs.

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.

That is a good point. NI Compare that ships with LabVIEW NXG 3.0 can support temporary file extensions that version control tools often create. NI Compare can diff two LabVIEW NXG VIs without having access to the sub VIs which also addresses parts of the issue you have noted here.

Please let me know if there are other open issues in your question that I missed.

Thanks,

Sumedha

[RVallieu]

Thanks for the reply.