Neil Pate

My programs are so well optimised the user never notices the delay 😉 Joking aside, if I am updating that many controls that the GUI is slow to paint it is probably symptomatic of a bad GUI design.

I have tried many different techniques but my currently preferred one is to assume upfront that I am going to use property nodes for all value updates so this then allows me to have a nice Update Sub VI where I update all the values every time I need to update anything. Any non-trivial GUI seems to require property nodes to do the "fancy" stuff, so I just start off with them like that. I normally don't bother with a Defer unless I am dealing with a *lot* of indicators (which is probably a smell of a badly designed GUI) or one of the usual suspects like a big table or tree control.

Thanks Rolf, that fix worked for me too! 👍🙏🙇‍♂️ I did search but never found that thread. Phew, mystery solved!

Interesting, thanks JKSH I will see if there is a BIOS update.

Thanks Rolf, that sounds quite plausible. AQ this is a brand new CPU with a Ryzen 3600 in it. I would consider changing the CPU if NI could give some guidance on what to change it to. Is there any sort of hot fix or patch I can try? For now I am out of trouble as I have rewritten the VIs that I needed to use from that library (mine were really simple) , but I doubt others will be so lucky.

Same MD5 as yours. @Aristos Queue this is a fresh installation of 2019 SP1 64-bit installed using the offline installer. I think that DLL calls into other DLLS (like BLASPACK or something like that), but I am not sure.

@Aristos Queue I have the PC back in my possession and have run the VI you asked. Here is the result. Now, if I immediately try and drop Mean.vi I can see it is trying to load it from the correct directory But if I do into the VI and open the Call Library Function node I get the e:\builds\penguin stuff The directory on disk is correct: Does this make any sense to you?

AQ, this was a brand new PC. I personally installed the most recent version of Win10 Pro. I then installed LV2019 64-bit SP1 using the offline ISOs from ni.com. No fancy patches or special versions. Then I open LabVIEW, start a new VI and drop down the Mean.vi and it is broken with the error as I have described. Several other VIs that link to analys.dll are also broken in the same way (I looked at some of the Cartesian shift VIs)! I tried this same experiment on the same PC using LabVIEW 2019 32-bit SP1 and the problem did not exist.

It is broken in the editor! That is how I know about the e:\penguin directory, I am opening the VI directly in the LabVIEW IDE and having a look at the DLL configuration. Unfortunately the offending PC is now at a customer site, as soon as I get access to it again I will try your experiments. Thanks for your help, I would really love to get to the bottom of this.

Absolutely. This is what I have had to do to get things working. Unfortunately this is not the only VI I used that calls into this DLL and this is definitely a game of whack-the-mole I don't have the energy to play. The problem is more... "why does this happen?". I am sure you know how frustrating it is when something works perfectly in the IDE but then has trouble in an executable. I thought I was at the point in my LabVIEW journey that I had experienced first-hand most of the weirdness that sometimes comes with the territory. This is altogether a new one for me though.

Thanks, this is exactly the same problem I am getting! I have no solution yet and have tried everything I can think of apart from not using those functions which seems like a terrible idea.

Installed LV2019 32-bit SP1 and it works fine, so this looks like something weird in 64-bit

So this just gets weirder! Reinstalled the OS and the basic 2019 64-bit SP1 RTE. Still get the error. Installed 2019 64-bit SP1 IDE, open a new VI and try and drop down Mean.vi and it gives me an error message saying A Dynamic Link Library Initialisation Failed! So after a bit of poking around I dig into the Mean.vi and take a look at the DLL and it is configured to have the path e:\builds\penguin\labview\branches\2019\dev\dist64\resource\lvanalys.* Obviously this will not work as I dont have an E: or builds\penguin directory!

Just did the same test with LV2019 32-bit and it works fine on the other PC. 🥵 Also works fine in a VM so I guess its probably something borked on the PC. Time to reinstall the OS (as obviously NI Package manager refuses to cooperate and now I have a bunch of orphaned software).

Seems there is a modern version of Dependency Walker called Dependencies, see it here: https://github.com/lucasg/Dependencies Running this does not show any problems with my DLL and if I hover over the BLASPACK DLL it gives me a popup confirming my suspicion that it is delay loaded. So weird...