Rolf Kalbermatter

4 hours ago, Michael Aivaliotis said:

I spent a long time online with YouTube support and finally got to the bottom of it. The Channel is back, and all the links work!

Thanks for your efforts Michael. It is appreciated a lot.

I just checked the logs and am surprised how many user creation log entries are there. At this rate we should have a huge amount of traffic here. I only wonder if this is an ongoing effort from hackers trying to get a hold in the wiki (or maybe indirectly also LavaG) to massively spam it at some point, or if most of those entries are actually genuine. I hope of course for the latter and looking at the names it could be for some. There are of course obvious exceptions like https://labviewwiki.org/wiki/User:Battery_trade-in_financial_gains

Well, it would seem to me that you are a newbie with LabVIEW and first should start to learn the basics before trying to dig into specific projects. Have a look at the resources mentioned on the top of this page.

https://forums.ni.com/t5/LabVIEW/bd-p/170

Go through the NI Learning Center links first then explore from there. You have to learn to walk before you can try to run or do a marathon.

You will have to provide some example. For string named nodes, the NodeID normally simply is "ns={x};s={YourNodeName}"

OPC UA node ID is *not*, by itself, a string. It is primarily a structure, containing the namespace (URI, index or both), and the identifier. OPC UA Node Id *has* a string representation, but the string representation is not the Node ID itself. The very same OPC UA node ID can be represented by multiple strings. You should not assume that two strings that appear different represent different node IDs. For example, "ns=1;s=SomeNode", and "ns=1;SomeNode" are strings that represent precisely the same node ID, because the "s=" prefix (for string identifiers) is optional. Or, "ns=0;s=Objects" may be the same as simply "s=Objects", because the default parsing context assumes the namespace index zero (when missing from the string).

The only thing you need to somehow know is what namespace index your variable is in and then you can easily construct a nodeID from a variable name yourself.

If you want to do it programmatically you would have to enumerate the namespace of the server with the Browse functionality and search for your specific variable name, but note that that may not always lead to a correct result. It is very possible that a server has multiple variables with the same name but under different namespaces. So programmatic resolution may end up giving you the wrong NodeID, as it can not know which it should use if it only has the name to go by.

On 12/23/2024 at 3:22 PM, 王佳 said:

First of all my device is a CRIO-9043.

I want to use one dimensional lookup table for interpolation in FPGA.vi, I am using U16 data type and one lookup table can store 40960 data and I need to store 7 million data. Currently I have inserted only 16 tables and the RAM resources are not enough. My compilation tells me that one lookup table takes up 19 RAM resources (my device has a total of 325 RAM resources).

But on the lookup table it shows that one table uses only 80KB of storage, while on the official website the CRIO-9043 has a RAM size of 2G!

I don't know how to solve this problem. Attached is my program, sorry it's only in Chinese!

15.vi 3.4 MB · 0 downloads

Your mixing and matching two very different things. The 2GB RAM is the physical RAM that the CPU and the Linux OS can use. But the RAM in the FPGA that is used for Lookup Tables is a very different sort of RAM and much more limited. The 9043 uses the Xilinx Kintex-7 7K160T FPGA chip. This chip has 202,800 Flop-Flops, 101,400 6 input LUTs, 600 DSP slices and  11,700 kbits of block RAM or BRAM, which is what can be used for the LUTs. If you really need these huge LUTs, you'll have to implement them in the realtime part of the application program, not in the FPGA part.

2 minutes ago, baggio2008 said:

Hi Dear,

the File contains a generated string part of  the node ID. Based on that string i would like to get the node ID.

Thank you.

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

On 12/9/2024 at 5:28 PM, baggio2008 said:

Hello everyone,

It is possible to get the NodeID of a variable from an OPC UA server using OPC UA client toolkit?

Thanks

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?

3 minutes ago, ShaunR said:

Faster execution than scripting. Scripting is incredibly slow.

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.

1 hour ago, ShaunR said:

Well. You could get it from the file. It's under the  block diagram heap (BDHP) which is a very old structure. I personally wouldn't bother for the reasons I stated earlier but it would be much faster than using scripting.

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

2 hours ago, ShaunR said:

You seem to have added that for no apparent reason, from what I can tell.

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!

9 minutes ago, ShaunR said:

This is the same as naming a DLL x32 or x64 with extra steps. You are now adding a naming convention to a read linker and a modify linker. It's getting worse, not better.

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?

4 minutes ago, ShaunR said:

That doesn't help you with user32.dll.

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.

51 minutes ago, ShaunR said:

That is a given. The only issue I would have there is when VIPM is updated.

However, you still have not explained why the "Extract Resources Info From Linker Info.vi"  needs modification if all modifications can be achieved in the "Copy Resource Files and Relink VIs__ogb.vi"

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.

42 minutes ago, ShaunR said:

I'm still not convinced it needs fixing around there at all. As far as I can tell, it only needs to be fixed at the original VI you proffered. The only issue you seemed to have is when a binary that isn't part of the developers distribution has a 32 or 64 on it (like user32.dll). I'd be more inclined to think of your initial suggestion of comparing paths to circumvent that though.

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

1 hour ago, hooovahh said:

I wasn't suggesting you were whiners.  If I ask for support from NI I don't think that makes me a whiner.  I was suggesting the changes you are proposing are useful for everyone, and that if you have useful changes, all VIPM users can benefit from them by having JKI use what you've developed.  Because you are a developer.  I also asked that question because I wanted to know incite into why VIPM does what it does so I can be a better developer.

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

26 minutes ago, hooovahh said:

Has anyone talked to JKI about this? I'm sure they make VIPM do this during the build for a reason and they would probably be interested in the changes you are doing.

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?

48 minutes ago, ShaunR said:

I think we are talking past each other.

I don't have a problem with naming. That is just what the *.* stuff does. I'm interested in what Rolf is doing to put the *.* into the node paths. I have a problem with linking-the VI search popping up during installation, VIPM not compiling everything and asking the user to save after use. This is caused by VIPM setting in concrete, the full DLL path in the nodes when it builds and not compiling certain VI's after installation.

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. 

19 hours ago, hooovahh said:

I'm also in Windows only land, and renaming the DLLs in a Post Install has worked well enough so far.  If we in a 64 bit LabVIEW for instance the post install looks for if there are DLLs named [X].dll but there exists an [X]64.dll.  If so it will delete the [X].dll and rename [X]64.dll to [X].dll.  This renaming bit also works in reverse looking for [X]32.dll if we are on a 32 bit version of LabVIEW.  Development then is done in one bitness statically picking the correct DLL. I have no clue how difficult or complicated this gets supporting Linux.

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

1 hour ago, ShaunR said:

Not quite. I asked about your code to solve my issue. I offered what I thought was an improvement based on my requirements and, as I don't support Linux or Mac anymore, you could migrate it to the other systems if it was viable.

You don't like it. Fine. It works great for me but for one edge case that you have pointed out that doesn't affect me. Assuming I cannot solve that one edge case, then I have a general Windows solution with one caveat that can go in the documentation. I'd call that progress 

Actually it's a little more than one edge case. It's potentially about any DLL that your library somehow references, including potentially built in LabVIEW functions that you use and that resort to calling DLL functions somewhere. Those might contain the 32 in their name or they might not, and they might also use the 32/64 naming scheme or not, and that would affect them too. Unlikely to happen? Probably, if you don't build a huge application framework library. Impossible? Definitely not.

It's your tool and you decide how you use it. Just don't come and whine that it destroyed your perfect library. 😀

At least it always works to replace the file ending with a wildcard! Unless of course you decide to use a different file ending for your special purpose libraries for whatever reason! That would have to be also caught by checking that the actual file ending is indeed the expected platform ending and only then do the file ending change to a wildcard.

It may sound like esoteric and far fetched edge cases, but I prefer to program defensive, even if I'm going to be the only final user of my functions. ☠️

On 11/26/2024 at 9:57 AM, ShaunR said:

Perhaps we are solving different issues due to different workflows.

It would seem so. You look for a way to hack VIPM to do something specific for your own shared libs and leave anything else to its own trouble. 🙂

I was trying to find a way that is a more general fix but that seems in fact impossible at this point, unless there is a way to actually have LabVIEW return the original library name for DLLs as filled in the Call Library Node.

Hmmm, thinking of this there might be, but it would involve a lot of changes in VIPM. When Reading the Linker Info earlier in the Builder, it may be possible to go through all shared library entries, get their caller name (with the link index) and then do a Find Object on the diagram of them for the Call Library Nodes, get the actual library name as filled in the Call Library Node, which hopefully hasn't yet been messed with by the loading of the VI into memory, and later on use that name to reset the linking info.

51 minutes ago, ShaunR said:

Feel free to add them in.

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.

6 hours ago, Achtu said:

Hello, is there a regex library in LV similar to Python’s re module? Any recommendations would be appreciated. Thank you!

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.

On 11/21/2024 at 11:11 AM, ShaunR said:

I've modified your sub vi to check the actual file bitness (I think). If you target user32.dll, for example, the filename out is user32.* - which is what's expected. I need to think a bit more about what I want from the function (I may not want the full path) but it should fix the problem you highlighted (only in Windows ).

Fixup Shared Library Name.vi 37.35 kB · 0 downloads

 

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.

20 hours ago, Cat said:

Thanks all!  I'm glad to hear there's a (slightly tarnished) silver lining in the dark cloud of this new paradigm. 

We have a ELA with NI for basically what used to be the Developer's Suite.  I've finally figured out the concern about having to pay perpetually for a perpetual license is coming from our contracts people.  Now I've got to convince them that they just have to pay for the first year of the service part and after that we don't need it.

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.