Leaderboard

Basic problem: If an element of a given cluster is changed - that value, and that value change alone, should be applied to several other clusters (which will otherwise retain their other element values). Known solutions: In the attached file (LabVIEW 2020 code) I have two ways of doing this: 1) using dynamic events and Set Cluster Elements by Name (OpenG), or 2) by using the Cluster To Array of VData.vi (also from OpenG). (Note: The use of array locals in the examples are there just to simplify the demo). Question: Are there other / better ways of doing it? A bit more background: In configuration windows I sometimes allow users various ways to choose to apply any *changes* globally or to a selection of targets. If e.g. they want to change the baud rate of 3 out of 5 different serial links they can choose the 3 links, and if they change anything in the communication setup of the first of them it will be applied to all 3 links (the rest of their setup will remain as before (they might still have different parity settings e.g.). I usually avoid clusters in the GUI so each change is handled individually, either in a dedicated value change event case (lots of coding needed...), or in a common case that uses the control reference to touch the correct element of the other target's configuration...(less code needed). However, in cases where the number of controls is very high, it can be nice to just have them in a cluster in the GUI as well - and to not have to write event cases to handle the change of each and every cluster element... Distributing cluster changes.zip

June 3 will be my last working day at NI. After almost 22 years, I'm stepping away from the company. Why? I found a G programming job in a field I love. Starting June 20, I'm going to be working at SpaceX on ground control for Falcon and Dragon. This news went public with customers at NI Connect this week. I figured I should post to the wider LabVIEW community here on LAVA. I want to thank you all for being amazing customers and letting me participate vicariously in so many cool engineering projects over the years. I'm still going to be a part of the LabVIEW community, but I'm not going to be making quite such an impact on G users going forward... until the day that they start needing developers on Mars -- remote desktop with a multi-minute delay between mouse clicks is such a pain! 🙂

Maybe completely unrelated, but I had a similar issue some time ago. I had some software which just did not run on a certain PC, it gave some weird error message. The error was actually in the LabVIEW "Mean.vi" which is part of the advanced analysis libraries. See this thread for my post. To cut a long story short, I had to add a setting to my PC environment variables. Doing so allowed the Math Kernel libraries to work with my CPU. Something similar to this. MKL_DEBUG_CPU_TYPE=4

Actually, your earlier screenshot shows https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html (or, if you prefer reading something shorter: https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)) If I recall correctly though, other parts of OpenG are available under the BSD-3 license: https://opensource.org/licenses/BSD-3-Clause

In fact your app requires the libraries on the very first level shown in Dependency Walker. The others are needed too, but they are being loaded by their "parent" DLLs, so you don't need to worry about them. Could you collapse that DLL list on the left of the DW, so we could see the first level libraries except sycl.dll and kernel32.dll? Don't look at those red warnings as they are about not finding some libraries, which likely are loaded during the runtime or have delayed loading or could even be absent in the system (as some .NET assemblies) and the app is able to run fine without them. So if only sycl is necessary, then you could either provide the path to it in your PATH environment variable or try to put it near your own DLL and check, whether LabVIEW loads it all without errors.

https://www.gnu.org/licenses/gpl-3.0.en.html

Maybe the reason is that LabVIEW cannot find some DPC++ Runtime library during the DLL load process (sycl.dll for instance or another one). Could you check with Dependency Walker, which libraries are in dependencies of your DLL?

Nice! While you are there please convince Elon to buy NI and turn it back into an engineering company 🤣