Leaderboard

Yes you can. The official form is at https://www.ni.com/en/forms/perpetual-software-licenses-labview.html Some things to keep in mind: There is a current promotion (valid till the end of December 2024) where those who used to have an SSP can renew it today as if the SSP never expired in the first place. That means you can get the latest version of LabVIEW, under a perpetual license, at a discounted price (compared to buying it "new"): https://forums.ni.com/t5/LabVIEW/LabVIEW-subscription-model-for-2022/m-p/4398958#M1296289 Quotes/sales are now handled by external distributors, rather than Emerson/NI. Lots of people have reported that they didn't get a response to their quote requests, or didn't get the expected discount applied. If that's the case, message Ahmed Eisawy, the Director of Test Software Commercialization (who wrote the forum post in my link above) and he'll get it sorted out.

I checked on a system where I had VIPM 2013 installed and looked in the support/ogb_2009.llb. Maybe your newer VIPM has an improved ogb_2009.llb. Also check out the actual post I updated the image.

Not quite! It's better to actually modify the Copy Resource Files and Relink.vi. Just add an additional case structure to handle shared libraries. The VI in question is this one: This will unconditionally change the linking name of all shared libraries in your build. There is a possibility that that is not desired although I can't think of a reason why that could be a problem right now. Fixup Shared Library Name.vi

There is to my knowledge no way to modify the JKI Builder. Although I think they did fix in recent years a bug that sounded exactly like what I ran across. But the JKI Builder has many other limitations that I'm not fond of so I still rely on my own setup. I basically use ogrsc_builder_3.0.0.11 for the renaming of the VI hierarchy with the opglib prefix with one modifications and then a heavily modified version of the OpenG Package Builder to package everything into the OpenG package. One caveat here, the ogrsc_builder_3.0.0 is from ca. 2009 times (and in 8.6 source code version). It will likely not go well with modern lvclass' and lvlib's and even more likely with lvlibp's files. It does have support for at least lvclass and lvlib but that is most likely fairly unmature seeing when it was last touched. lvclass and lvlib still were fairly new back then and had several quirks even in LabVIEW itself. I changed deep in the belly of the OpenG Builder in OpenG\build\ogb.llb\Copy Resource Files and Relink VIs__ogb.vi, that for shared library names the file name is changed back to the previous <file name>*.* with some magic to detect the 32 or 64 in the file name if present. It's not fail safe and for that not a fix that I would propose for inclusion in a public tool, but it does the job for me. What basically goes wrong is that when LabVIEW loads the VIs, it replaces to magic place holders with the real values in the paths in the VIs in memory and when you then Read the Linker Info to massage that for renaming VIs, you receive these new fully resolved paths and when you then write back the modified linker info you cement the not-platform neutral naming into the VIs and save it to disk. The OpenG Package Builder modifications mainly have to do with a more detailed selection of package content and special settings to more easily allow multi-platform support for shared library and other binary compiled content. In terms of user experience it is the total opposite of VIPM. It would overwhelm the typical user with way to many options and details that it could be useful for most. I had hoped to integrate the hierarchy renaming into the Package Builder too, since the information in the Package Builder would be basically enough to do that, but looking at the core of the OpenG Builder in Build Applciation__ogb.vi will for sure make you get the shivers to try to reimplement that in any useful way. 😁 And yes the naming of the tools is a bit confusing. The OpenG Builder is the tool that massages an existing hierarchy into a new on with VI renaming and relocating them into a configurable tree and fixing up relative paths to be correct for the new names and locations, while the OpenG Package Builder grabs a list of files and simply pushes them into an OpenG package (basically a ZIP file with configuration file). It would be quite useful to integrate the OpenG Builder as an extra prepare step into the OpenG Package Builder but that is a taunting exercise.