Rolf Kalbermatter

Not likely as there are many potential problems. For one, properly configured Call Library Nodes for system libraries will report a relative path with just the library name, so your File Open will simply error out on that as it can't find the file (it might actually magically, if you just happened to select a file through the File Dialog Box in the system directory as that will change the application global current directory variable and the Windows user space API is known to try to resolve relative names relative to that current directory). But the problem with that is that it will only work if the current directory is set to the System32 directory, which it usually isn't. An error on this level passed on to VIPM will not likely far well with the installation itself. But the main problem is that I do not see how that could work properly when trying to build on 32-bit LabVIEW for DLL files that should remain with 32 in their name.

There is a Match Regular Expression node in LabVIEW that uses internally the PCRE library. It may not be 100% the same as what you have in Python, but that would be actually more a problem of the Python implementation. The PCRE library is pretty much the de facto implementation of regular expressions.

That looks nasty. Checking the PE file header would be one of the last things I would resort to. It also has the potential to fail for many reasons such as LabVIEW deciding to not convert the wildcard filenames in the Linker Info anymore, although I think that's actually unlikely since those paths are meant to actually allow access the files on disk in some way. But it's a private node, so all guarantees are pretty much null and void. Also I fail to see how your method would work with a DLL called user32.dll that should stay that way when your tool is running on LabVIEW for 32-bit. It will correctly detect that the DLL is NOT 64 bit, so use the 32 to search for in the file name, correctly find that and replace it with a *. Boom, When loaded in LabVIEW for 64-bit the VI will look for user64.dll and that will not work. Also don't try to read the file for the non-Windows cases as you don't do anything with that anyhow! The best we may be able to do here is to simply detect if it is a relative path with only one path element (it is for system shared libraries correctly setup in the Call Library Node) and skip the renaming back to wildcard names for them. This may require more investigation for other OSes such as Linux. But there, multiarch installations are also usually solved by having different lib directories for the different architectures and not to rename the files for standard libraries. Only file names with absolute path (and hence not installed in one of these directories but located locally to to caller, MIGHT use the 32-bit/64-bit naming scheme. It's a kludge, but VIPM unfortunately has limited support to install binary files based on the bitness of the target LabVIEW version! Otherwise I wouldn't need that complete filename wildcard voodoo for my libraries. In the past I tried to solve it by installing both versions of the shared library with different names and having a post-install hook to delete the wrong one and do the renaming to the expected standard name. But that has other complications in some situations. I may still decide to revert back to that. This nonsense is even worse to solve properly.

So they would rather like to pay a yearly subscription (and have their developers loose access once finance decides to stop the recurring payment) than a one time fee and decide at the end of the year if they want to fork over another 25% of the then actual license price to stay in the maintenance program? Sounds like a typical MBA logic! 😀 But if you own old perpetual licenses and can proof it you get to actually renew them by simply paying the Maintenance Support Program (MSP) fee of 25% of the full price. NI has publicly stated that, until mid 2025, they will waive all late fees for lapsed MSPs (basically nobody could possibly still have an active MSP at this point after NI forced everybody to go to SAAS after January 1, 2022). The MSP is actually still slightly cheaper than the SAAS fee, and rightly so, people paying for the perpetual license paid royally for the initial license.

As of yesterday, November 18, the Perpetual licenses for LabVIEW and LabVIEW+ are officially back and should be directly orderable through the normal LabVIEW order page . But yes compared to before when the subscription was pushed down our throat the costs have significantly increased. I would say it is almost a 2.5* price increase if I remember correctly. The current Professional Developer price is higher than what the Developer Suite used to be back then, which also included LabVIEW Realtime and LabVIEW FPGA and just about any possible toolkit there was.

It just occurred to me that there is a potential problem. If your DLLs are always containing 32 in their name, independent of the actual bitness, as for instance many Windows DLLs do, this will corrupt the name for 64-bit LabVIEW installations. I haven't checked if paths to DLL names in the System Directory are added to the Linker Info. If they are, and I would think they are, one would have to skip file paths that are only a library name (indicating to LabVIEW to let the OS try to find them through the standard search mechanism). This of course still isn't fail proof: DLLs installed in the System directory (not from Microsoft though) could still use the 32-bit/64-bit naming scheme, and DLLs not from there could use the fixed 32 naming scheme (or 64 fixed name when building with VIPM build as 64-bit executable, I'm not sure if the latest version is still build in 32-bit).

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.

The problems with the paths to the shared libraries should be fixed with version 5.0.3. It's a combination of using the <library_name>*.* format to let LabVIEW resolve to the right shared library with the first * being replaced with 32 or 64 and the second with the platform specific shared library file extension (dll and so). Also needed to fixup the linker info in the VIs after creating the renamed (with oglib postfix) VI hierarchy through the OpenG Builder functions. LabVIEW, after creating the renamed hierarchy, will store the fully resolved library name into all VIs, which of course is not very helpful as it pins the VIs then to only use the shared library that matches the LabVIEW platform used to create the package. Version 5.0.4 was adding a working low level API for supporting a progress interface to the storing of files into an archive. Version 5.0.5 was adding an extended interface to the Inflate and Deflate functions to compress and uncompress binary streams and control the header used (none, zlib or gzip). Previously only zlib was supported for Deflate and Inflate. Version 5.0.6 fixes a bug when dealing with UNC names that contain numeric characters such as an IP address in the server name. https://www.vipm.io/package/oglib_lvzip/

It's not listed in https://www.ni.com/en/support/documentation/bugs/24/labview-2024-q3-bug-fixes.html As LabVIEW user I feel happy for their attention to this. As OpenG ZIP developer I feel a bit cheated. 😁

Unfortunately yes. First signed up 50 minutes ago and started spamming about 5 minutes later, then spamming about every 5 minutes. Second signed up 10 minutes ago and just started spamming. Definitely related as it is both about Norton spam. I'm very anti violence but these guys really get the worst in me out! 👿

Unfortunately it seems not. They said both (the two I checked) that they were created less than an hour ago, when I looked this morning (GMT+2).

What have you tried so far? https://docs.gitlab.com/ee/api/rest/ documents a REST API to gitlab servers. Did you look at that? Did you try anything? There is for instance the JKI REST API Toolkit that should let you talk to this.

That's normal for cRIOs. They don't usually go lower than a few MHz. I still use them whenever possible, except for loops that must contain nodes that can't be put into a single cycle loop at all. Quite often you do need pipelining anyhow at some point and then often need higher loop rates than your final desired rate and you can always implement your own internal counters that reduce the loop rate further and updates the outputs with the desired lower rate.

Seems to work fine from here today and is very snappy too. Wish the NI site was even remotely as fast. 😀

It seems to start to work! Unless of course you have hired some elves that keep checking the forum and deleting any account created with nefarious motives. 😀 But it is quite some time that I came in the office in the morning and didn't get greeted by a stream of products of humanities lowest when opening LavaG. In fact there seems none, and the latest new member is already 21 hours ago and still has 0 accounted posts for, so he may be actually genuine. Just hope that the moderators new message queue isn't overflowing with held back posts. Although you can always hope that it will die down once they realize that it has exactly 0.0% reach factor.

That was regularly true in the past, some of the callgirl spam so far was already NSFW.

They finally found out how to spam every single subforum at least once in a night.

Not yet. I'm actually working on it. Did read yesterday about the opkg package format needed and got some ideas about how to support that properly. Next step is to get the necessary gcc cross compile setup working again and create the relevant shared libraries and do some tests on several LabVIEW versions. Shouldn't be many months, but don't expect the according release next week. 😀

I put a prerelease package under https://kalbermatter.nl/downloads/oglib_lvzip-5.0.4beta-1.ogp The package is now officially released as version 5.0.4-1 under https://www.vipm.io/package/oglib_lvzip/

Most likely not! The directories and files during installation are done inside VIPM. In VIPM 2017 you have to start it up as sudo, so the owner will be root. The Post Install script is executed inside the LabVIEW environment through VI Server. That is not launched with sudo and therefore has no write access to the root owned directory.

Next step is trying to find out how OpenG ZIP Library fails on the lvappimg. My suspicion still is that it is an issue with the fact that the library is compiled for 64-bit. So am going to test it with 64-bit on Windows. Except that I'm using of course the most recent version 5.0 of the library which had quite a bit of changes in the C code to support 64-bit archives. So there is a very good chance that it simply will work. I can provide you with a prerelase of 5.0.4 that should install under Linux with both VIPM 2017 and 2022 if that helps. That would show if it is still a problem in the current code base. As it is I have not a working 64-bit version of LabVIEW for Linux at this point.

VIPM has limited and varying support for that depending on its version. "Linux" in VIPM 2017 means any LabVIEW version for Linux. "Linux x64" is not a thing before VIPM 2016 or so, but means 64-bit in VIPM 2017 and newer. And "Linux" in VIPM 2022 means 32-bit LabVIEW only, which is pretty stupid considering that LabVIEW for Linux is 64-bit only since 2017. Definitely an oversight by the VIPM developers that should be fixed. You don't want to require to have to explicitly specify "Linux x64" as supported target for packages that don't even have binary dependencies inside. It's doable with a Post Install VI in the package that renames the shared libraries after installation, except with VIPM 2017 and maybe others, which needs to run with root privileges to do anything useful. As my main Linux test system is still LabVIEW 8.6, newer versions have various troubles for me from inability to get a full installer for them to installation trouble on my Linux VMs, I did not want to abandon this version but was under the wrong assumption that it would not support the wildcard library naming to distinguish between 32-bit and 64-bit files, since the first version of LabVIEW supporting 64-bit was 2009. Obviously Brian had been starting to work on 64-bit support earlier already and not all of that support was removed by some precompile symbols it seems, so it is already present in 8.6 LabVIEW. Most likely it would have been possible to release LabVIEW 8.6 for 64-bit but probably with some bugs here and there. Of course VIPM Package Builder doesn't really support setting specific platform and bitness limitations on individual files or file groups, only on the full package. But I'm using my own OpenG Package Builder instead which has all those possibilities, yet it doesn't really help if VIPM then goes and messes that up anyhow. But creating my own package manager is definitely one step to far for my mental health. 😁

I appreciate your cooperation but there are a number of difficulties with this! 1) I try to avoid dependencies in the package including the Script VIs in OpenG ZIP Library > 5.0. It's not strictly necessary as the dependencies should be already installed at the time VIPM gets to install the real package, but I had situations where this was adding an additional problem. 2) More seriously though, it's not the fact that trying to delete it might fail if the file isn't there. That I wouldn't care and could also ignore by simply adding a Clear Error.vi after the Delete. But even with this change of yours the Delete function will still fail either by trying to clear the write protection on the file it has no access too or if I skip that by trying to delete the file it has no access to. Even ignoring that error won't help as the Move consequently will fail then too. For VIPM 2022 ignoring any error from the Delete should however work, as it copied the files from the archive to the target location with the same user rights as what LabVIEW was started up with. For VIPM 2017 there is unfortunately no way to avoid having the 32-bit so installed. If I mark it as Linux only it will install in both cases. But!!!!! I just noticed that the <library name>*.* wildcard naming in the Library Name control for the Call Library Node seems to work even in LabVIEW 8.6 (which had no 64-bit release). This saves the day!! I just can install the shared library with the 32 and 64 bit postfix alongside each other and be done, without having to abandon support for 8.6!! Thanks Brian Powell!