Rolf Kalbermatter

What doesn't work with the function: AJ_NETSDK_IPC_PTZControl() on page 21/22? Or are you not using the SDK functions to retrieve the RTSP stream but some other ready made interface for LabVIEW? Meaning you have no idea how to interface to a DLL? A few points to consider: 1) The camera may not like a secondary connection, either through the SDK or through generic TCP/IP while it is busy streaming image data to the VLC or whatever interface. 2) Trying to reverse engineer the TCP/IP binary stream protocol is likely going to be cumbersome and difficult to realize as it is usually proprietary. The SDK interface is simple enough to use, except if you lack any and all understanding about C programming. It's not a CIN node either that you will need to configure but a CLN (Call Library Node). CINs are not only legacy technology but on most modern LabVIEW versions simply not supported anymore. An interesting problem, but none I can help you as I do not have that hardware, and I would expect it to be a bit cumbersome considering above 2 points.

Well, there are two aspects. The first is the technical one from hackers diving into the software and unhiding things that NI felt were not ready for prime time, to complicated for simple users, or possibly also to powerful. The main reason definitely always is however: if we release that, we have to spend a lot more effort to make it a finished feature (a feature for internal use where you can tell your users: "sorry that was not meant to be used in the way you just tried") is maybe 10 - 20% of development time than the finished feature for public use. There is also support required. That costs money in terms of substantial extra development, end user quality documentation (a simple notepad file doesn't cut it), maintenance and fixing things if something does not match the documented behaviour. And yes I'm aware they don't always fix bugs immediately (or ever) but the premise is, that releasing a feature causes a lot of additional costs and obligations, if you want to or not. The other aspect is, if someone who is an active partner and has active contacts with various people at NI, he is infinitely more likely to be able to influence decisions at NI than the greatest hacker doing his thing in his attic and never talking with anyone from NI. In that sense it is very likely that Jim having talked with a few people at NI has done a lot more to make NI release this feature eventually, than 20 hackers throwing every single "secret" about this feature on the street. In that sense the term "forcing NI's hands" is maybe a bit inaccurate. He didn't force them, but led them to see the light! Not out of pure selfless love, but to be able to officially use that feature for himself. The according Right-Click framework was a proof of concept to see how this feature can be used and mainly an example to other users how it can be used, and indeed once it worked it had fulfilled its purpose. That it was not maintained afterwards is not specifically JKI's fault. It is open source, so anyone could have picked up the baton, if they felt it was so valuable for them. The problem with many libraries is actually, if they are not open source and free, many complain about that, if it is open source and/or free, they still expect full support for it! In that sense I have seen a nice little remark recently:

NI was quite invested in EtherCAT circa 2012 to 2016 but then lost its interest in anything not related to big turnkey testing systems. The Industrial Communication tools were part of that together with Motion, Vision and pretty much anything else except DAQ and PXI. Basically EtherCAT after about LabVIEW 2017 is more of a "Take it as it is! If it works for you, great! If it doesn't, please don't bother us!" Even in LabVIEW 2017 it was still far from a Plug and Play experience. I worked on a project at that time, trying to interface a Industrial Controller IC-3173 to several different EtherCAT hardware. It was a long and tedious process and back then we could actually talk to support people who tried to help but often were stumped just as much as we, why something didn't work. There were many subtleties and it was not always NIs fault when something didn't work, but it was very difficult to get a deeper look into things as NI tends to hide a lot behind simple looking configurations. At this point I have very strong doubts that anyone at NI even knows how any of these Industrial Communication Products work. They still sell a few things that can work if you are lucky, but if it doesn't work, they can't support it in any way, since there simply is nobody anymore who has worked on these products in many years. The good news is that NI definitely has been getting a lot more proactive on a lot of subjects in the last year. Their efforts to get the community involved again, still need to be fully realized but the communicated intentions are strong and fairly consistent, so I dare to have hope. From some communications I had with them, it seems that they actually are planning to be more concentrated on certain core areas and actively look for 3rd parties in the market to provide alternative solutions for the products they don't consider a core technology. Industrial Communication interfaces seem one such area, where they would seem happy to promote an alternative rather than maintaining their own solution, but they might pick up on some of them, as they are not all as easy to support for 3rd party providers.

Not likely. I think the Administrators always resisted such requests unless there was a real legal matter involved. But LavaG had several nervous breakdowns over the years, either because a harddisk crashed or forum software somehow got in a fit. It was always restored as well as possible, but at at least one of those incidents a lot got lost. Some of that was consequently restored from archives other people had maintained from their push notifications from this website, but quite a bit got lost then. You can still see some old posts where the whole text is underscored and links for as far as they are present point into nirvana. These are supposedly not well restored posts and by now of at best historical value, so hard to justify to try to clean up.

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!