Rolf Kalbermatter

Aren't shortcut menus invoked in the UI thread and maybe will instantiate any menu handling VIs in the LVDialogContext? The same that is used when you place VIs in the Tools menu (or maybe a similar other specific context). Did you try a This App Reference constant?

The idea about NXG in terms of how "bad" the old code base was, always struck me a bit like "throwing out the baby with the bathwater". And while I wasn't involved in any of the user sessions about NXG myself, from the things I heard, I got the impression that they were mainly trying to look for an echo chamber instead of real constructive critique. (Probably one reason I did not get contacted as I never held back about not being a cheerleader). 😁

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.

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.

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