Rolf Kalbermatter

You can't automatically. There could be the same name in several namespaces. You will have to browse the various namespaces and search for that specific name. That can be done with the BrowseForward function programmatically. Or if you know in which namespace they all are, you can reconstruct the NodeID string of course yourself, something like ns=1;s=your_string_name or if it is an uri namespace: nsu=https://someserver/resource ;s=your_string_name

How is that name created? Variables in OPC-UA are really only known by their node ID anyways. This can be a string node ID that gives you a name, but that is entirely depending on the server configuration as to what that string would be if any. There is no way that you can have some random string name and let the server answer you with what node ID that could be, since a node is simply known by its node ID and nothing else. So the real question is how did that string name in your spreadsheet file get generated? Is it the string part of a string type node ID with removed namespace part?

Ahh, ok, that I would wholeheartedly agree to. It's probably mostly going through the UI thread and possibly a lot through the root loop even. It touches many global resources and that's the most easy way to protect things. Adding mutexes over the whole place makes things nasty fast and before you know it you are in the land of mutual exclusion if you are not VERY careful.

Faster is a bit debatable. 😁 The scripting method took me less than half an hour to find out that it doesn't return what I want. Should have done that from the start before getting into a debate with you about the merits of doing that. 😴 The file is of course an option, except that there are a number of pitfalls. Some newer versions of LabVIEW seem to Deflate many of the resource streams and giving them a slightly different name. Not a huge problem but still a bit of a hassle. And the structure of the actual resources is not always quite casted in stone. NI did change some of that over the course of time. But pylabview definitely has most of the information needed for doing that. 😁 One advantage, it would not be necessary to do that anywhere else in the OGB library. The original file structure should still be guaranteed to be intact at the time the file has been copied to its new location! But it goes clearly beyond the SuperSecretPrivateSpecialStuff, that OpenG and VIPM have dared to endeavor into so far. Considering that I'm currently trying to figure out how to do LabVIEW Variants from the C side of things, as properly as possibly without serious hacks, it's however not something that would scare me much. 😁

Let's agree to disagree. 😀 However, some testing seems to indicate that it is not possible with the publicly available functions to get the real wildcard library name at all. It's there in the VI file and the Call Library Node can display it, but trying to read it through scripting will always return the fully qualified name as it was resolved for the current platform and current bitness. No joy in trying to get the wildcard name. That's rather frustrating!

It depends what your aim is. If your aim is to get something working most of the time with as little modification as possible to the OpenG OGB library, then yes you want to guesstimate the most likely wildcard name, with some exception handling for specially known DLL names during writing back the Linker Info. If your aim is to use the information that LabVIEW is using when it loaded the VIs into memory, you want to get the actual Call Library Name. And you want to get that as early as possible, preferably before the OGB tool resaved and post- and/or prefixed the name of all the VIs to a new location. All these things have the potential to overwrite the actual Call Library Node library name with the new name and destroy the wildcard name. So while you could try to query the library name in the Write Linker Info step, it may be to late to retrieve that information correctly. That means modifying the OGB library in two places. Is that really that much more bad than modifying it in one place with an only most of the time correct name?

It does. The Call Library Node explicitly has to be configured as user32.dll or maybe user32.*. Otherwise, if the developer enters user*.*, it won't work properly when loading the VI in 64-bit LabVIEW.

It's pretty simple. You want to get the real information from the Call Library Node, not some massaged and assumed file name down the path. Assume starts with ass and that is where it sooner or later bites you! 😀 The Call Library Node knows what the library name is that the developer configured. And that is the name that LabVIEW uses when you do your unit tests. So you want to make sure to use that name and not some guesstimated one. The Read Linker Info unfortunately only returns the recompiled path and file name after the whole VI hierarchy has been loaded and relinked, possibly with relocating VIs and DLLs from anywhere in the search path if the original path could not be found. That is as far as the path goes very useful, but it looses the wildcard name for shared libraries. The delimited name would have been a prime candidate to use to return that information. This name exists to return the fully names spaced name of VIs in classes and libraries. It serves no useful purpose for shared libraries though and could have been used to return the original Call Library Node name. Unfortunately it wasn't. So my idea is to patch that up in the Linker Info on reading that info and later reuse it to update the linker info when writing it back to the relocated and relinked VI hierarchy.

Yes, my concern is this. It's ok for your own solution, where you know what shared libraries your projects use and how such a fix might have unwanted effects. In the worst case you just shoot in your own foot. 😀 But it is not a fix that could ever be incorporated in VIPM proper as there is not only no way to know for what package builds it will be used, but an almost 100% chance that an affected user will simply have no idea why things go wrong, and how to fix it. If it is for your own private VIPM installation, go ahead, do whatever you like. It's your system after all. 😀

It's my intention to throw the VI, once it seems to work for me, over the fence into JKI's garden and see what they will do with it. 😀 More seriously I plan to inform them of the problem and my solutions, through whatever support channels I can find. It does feel a bit like a black hole though. The reason for working like it does, is most likely that it is simply how the Read Linker Info in LabVIEW works. They use that and the information it returns and that is not including the original wildcard name. Also most of that is the original OpenG package builder library with some selected fixes since, for newer LabVIEW features. I also don't get the feeling that anyone really dug into those VIs very much to improve them beyond some bug fixes and support for new LabVIEW features since the library was originally published as OpenG library (mainly developed by Konstantin Shifershteyn back then, with some modifications by Jim Kring and Ton Plomp until around 2008).

We are also developers, not just whiners! 😀 Honestly I did try in the past to get some feedback. It was more specific about supporting more fine grained target selections than just Windows, Linux and Mac in the package builder, specifically to also support 32-bit or 64-bit and not just for the entire package, as VIPM eventually supported, but rather for individual file groups in the package. Never received any reaction on that. Maybe it was because I wanted to use it with my own OpenG Builder, I just needed the according support in the spec file for the VIPM package installer to properly honor things. Didn't feel like distributing my own version of the package installer too. That format allows specifying the supported targets, LabVIEW version and type on a per file group base. VIPM package builder is a bit more limited for the purpose of more easy package configuration when building packages. I'm using that spec file feature through my own Package Builder to build a package that contains all shared libraries for all supported platforms and then install the correct shared libraries for Linux or Windows in the OpenG ZIP (and Lua for LabVIEW) package, depending on what platform things are installed. Unfortunately the specification for the platform and LabVIEW version does not seem to support 32-bit and 64-bit distinctions. So I have to install both and then either fixup things to the common name in the Post Install, or use the filename*.* library name scheme.

Actually I'm more inclined to hack things here: I don't feel like traversing the entire linker info array recursively if that is done anyhow in the next VI in the execution flow! But the current implementation is a bit naive, did some refactoring on that too.

The most proper solution will be to go through all the files retrieved through the Read Linker Info function in the Generate Resource Copy Info.vi, find all shared libraries and from there their callers, enumerate for Call Library Nodes in the diagram and retrieve the library name and patch up the "delimited name" in the linker info for the shared library with the file name portion of that library name. In the Copy Resource Files and Relink VIs.vi, simply replace the file name portion of the path with the patched up "delimited name" value! The finding of the callers is already done in the Generate Resource Copy Info.vi, so we "just" have to go through the Resources Copy Info array and get the shared library entries and then check their Referrers. This assumes that all the library paths are properly wildcard formatted prior to starting the build process as it will maintain the original library name in the source VIs. Possible gotcha's still needed to find out and resolve: - Is the library name returned by the scripting functions at this point still the wildcard name or already patched with the resolved name while loading the VI? - Are all the scripting functions to enumerate the Call Library nodes and retrieve the library name also available in the runtime or only in the full development runtime? Although the Build Application.vi function is most likely executed over VI server in the target LabVIEW version and not as part of the VIPM executable runtime?

Yes, we kind of talk past each other here. Mostly because it is an involved low level topic. And VIPM is in this specific case technically pretty innocent. It uses the private Read Linker Info and Write Linker Info methods in LabVIEW to retrieve the hierarchy of VIs, relocating them on disk to a new hierarchy, which is quite a feat to do properly, patching up the linker info to correctly point to the new locations and writing it back. The problem is that the paths returned by Read Linker Info are nicely de-wildcarded, which is a good thing if you want to access the actual files on disk (the standard file functions know nothing about shared library wildcard names), but a bad thing when writing back the linker info. The Read Linker Info itself does not deliver the original wildcard name (it could theoretically do so in the "delimited name" string for shared libraries as that name is otherwise not very useful for shared libraries, but doesn't do so, which is in fact a missed opportunity as the fully resolved name is already returned correctly in the path). The only way to fix that consistently across multiple LabVIEW versions is to go through the array of linker infos after doing the Read Linker Info, recursively determine the callers that reference a specific shared library, enumerate their block diagram for any Call Library nodes, retrieve their library name and replace the "delimited name" in the linker info with the file name portion of that! Then before writing back the Linker Info, replace the file name in the path, respectively in newer LabVIEW versions you have the additional "original Name" string array when writing back the Linker Info, so might be possible to pass that name in there. Quite an involved modification to the existing OpenG Builder library.

This works on Linux too, and did so in the past for the OpenG ZIP library. I'm not really sure anymore what made me decide to go with the 32/64 bit naming but there were a number of requests for varying things such as being able to not have the VIs be recompiled after installation, as that slows down installation of entire package configurations. And the OpenG Builder was also indiscriminately replacing the carefully managed lvzlib.* library name with lvzlib.dll in the built libraries so that installation on Linux systems created broken VIs. In the course of trying to solve all these requirements, I somehow come up with the different bitness naming scheme with the LabVIEW wildcard support, but I think now that that was a mistake. In hindsight I think the "only" things that are really needed are: to leave the shared library name (except the file ending of course) for all platforms the same the simple modification in the VIPM Builder library to replace the shared library file name extension back to the wildcard add individual shared libraries for all supported platforms to the OGP/VIP package. But since VIPM has only really support for individual system platforms but not the bitness of individual files, we need to name the files in the archive differently for the bitness and let them install both on the target system with their respective name create a PostInstall hook that will rename the correct shared library for the actual bitness to the generic name and delete the other one Of course with a bit more specific bitness support in VIPM it would be possible to define the shared library to install based on both the correct platform and bitness, but that train has probably long departed. Will have to rethink this for the OpenG ZIP library a bit more, and most likely I will also add an extra directory with the shared libraries for the ARM and x64 cRIOs in the installation. Will require to manually install them to the cRIO target for the library to work there but the alternative is to: have the user add a shared network location containing the according opkg packages to the opkg package manager on the command line of the cRIO do an opgk install opgzip<version> on that command line That's definitely not more convenient at all!!!