LabVIEW
LabVIEW LVAddons Help - LabVIEW Reuse Shared Between Versions
EDIT: Okay I did find some documentation around this here. My questions still stand to NI if this is a feature the community should use, and issues around that.
So I installed some tools for LabVIEW 2022, and I noticed that the location of the installed VIs is quite a bit different and I was hoping NI could explain some of how it is intended to work. I'd also like any documentation NI might have in this new way of storing reuse code between LabVIEW versions.
So in the past when you install something like DAQmx, it will scan what versions of LabVIEW you have installed, and then install the VIs or any needed code to each version of LabVIEW. So if you had these 4 versions of LabVIEW installed, the same VIs would be copied to:
C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\DAQmx
C:\Program Files (x86)\National Instruments\LabVIEW 2021\vi.lib\DAQmx
C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\DAQmx
C:\Program Files\National Instruments\LabVIEW 2021\vi.lib\DAQmx
But it seems starting in LabVIEW 2022 there is a new location of where code can be found. I have LabVIEW 2022 64-bit installed and I now have files in:
C:\Program Files\NI\LVAddons\nidaqmx32
C:\Program Files\NI\LVAddons\nidaqmx64
Under both of them is a folder labeled "1" and under that is a JSON file describing the name, supported version, supported bitness, and API version. Then there are folders that mirror what you might expect from the LabVIEW installation directory. I realize that later versions of LabVIEW have the ability to keep the VIs in the version they were saved in so I suspect that change helped facilitate that.
So NI, what can you say about this new way of storing reuse code, and code that is shared between versions of LabVIEW? Are there any considerations the community should have in using this? What issues do you see with something like VIPM installing packages here? Should these be considered System Packages in VIPM since they don't require any specific version of LabVIEW, just 2022 or later? Does this even work with VIPM in detecting dependent packages for instance? Does separate compiled code being on a requirement for VIs in this space? (yes) Is there any documentation on what the various JSON parameters are? Why was "NI" chosen as the folder name instead of the one NI already had named "National Instruments"? Is it intended to have both 64 and 32 bit code under the 64 bit Program Files? How should that work if only 32 bit version of LabVIEW is installed? Are both locations used? Is there any issues or considerations with the fact that multiple versions of LabVIEW will reference the same VIs? I realize reuse code shouldn't be edited but now things like examples will be changed for all versions if one is edited. Does this change any recommendations in using the user.lib for community reuse? I suspect the folders just get mapped and indexed so it doesn't matter. What is the "1" folder intended for? How does this work having reuse code link to other reuse code? Is it just another search path?
@Hooovahh wrote:
So in the past when you install something like DAQmx, it will scan what versions of LabVIEW you have installed, and then install the VIs or any needed code to each version of LabVIEW. So if you had these 4 versions of LabVIEW installed, the same VIs would be copied to:
C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\DAQmx
C:\Program Files (x86)\National Instruments\LabVIEW 2021\vi.lib\DAQmx
C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\DAQmx
C:\Program Files\National Instruments\LabVIEW 2021\vi.lib\DAQmx
But it seems starting in LabVIEW 2022 there is a new location of where code can be found. I have LabVIEW 2022 64-bit installed and I now have files in:
C:\Program Files\NI\LVAddons\nidaqmx32
C:\Program Files\NI\LVAddons\nidaqmx64
Under both of them is a folder labeled "1" and under that is a JSON file describing the name, supported version, supported bitness, and API version. Then there are folders that mirror what you might expect from the LabVIEW installation directory. I realize that later versions of LabVIEW have the ability to keep the VIs in the version they were saved in so I suspect that change helped facilitate that.
A slight correction to what you have here. What really matters for DAQmx is C:\Program Files\NI\LVAddons\nidaqmx. That is where the API VIs, examples, etc are.
According to the presentation by Greg Richardson linked above, under the folder structure here is C:\Program Files\NI\LVAddons\<Addon Name>\<Addon version> and then everything under there matches <LabVIEW>. The JSON file is extremely simple, so just copy one from a different addon that works and you can easily figure out what the values should be.
@Hooovahh escreveu:
What issues do you see with something like VIPM installing packages here? Should these be considered System Packages in VIPM since they don't require any specific version of LabVIEW, just 2022 or later? Does this even work with VIPM in detecting dependent packages for instance?
As I understood, if NIPM was close to usable or had similar features to VIPM, it means that NIPM could handle all the reusable packages by installing in this place, including the ones that VIPM handles today. Maybe that was not the intent, but it can be used that way.
@Hooovahh escreveu:
Why was "NI" chosen as the folder name instead of the one NI already had named "National Instruments"? Is it intended to have both 64 and 32 bit code under the 64 bit Program Files? How should that work if only 32 bit version of LabVIEW is installed? Are both locations used?
Just a side note regarding this, this is a picture from my AppData/Local folder. It seems NI is not that good at standardizing their folder names.
@Hooovahh wrote:
Why was "NI" chosen as the folder name instead of the one NI already had named "National Instruments"?
A guess of mine, but not entirely uneducated: Ever heard of the Windows 259 character path name length limitation? It would not be an issue if NI could have been bothered to use the Unicode file IO functions that are available in Windows since Windows 95, but they choose to not bother about that. The LabVIEW path control only has two limits, it can not have more than 255 path elements and each path element can not contain more than 255 characters. Well there is a third, as it is traditionally using the native platform 8 bit encoding and that is under Windows what they call the ANSI encoding. This is whatever codepage is associated to the current region. So you can't represent true Unicode strings in a LabVIEW path control, since it only knows about whatever code page is currently selected.
For Linux this is however since many moons usually UTF8.
Still, LabVIEW could deal with long pathnames under Windows (and Linux and Mac of course too), since about LabVIEW version 6 or earlier (basically as soon as they gutted support for Windows 3.1) if someone would have cared. It's not a piece of cake to do, but it is also not a multi-person and/or multi year project to do.
In the same above-mentioned presentation, Greg Richardson mentions that this INI key exists since LV2021SP1:
WindowsLongPaths=true
