Neil Pate

I only used Bitbucket for my personal consulting work so have moved away entirely there. However at my day job we are heavily into Jira and Confluence and will likely not be moving away from these any time soon.

GitKraken is free for public GitHub repositories, I never tried it with anything local but I think you are right in that the free version does work as well. I spent a few weeks with the free version and happily handed them some money for the pro version. Its a really nice client. I actually bought a second license as I had the GitHub client on my wife's computer and it was so terrible in comparison.

As much as I hate to say this, I don't really think we are NIs target audience with NXG. I would guestimate that there are probably fewer than a couple of hundred people in the world (apart from NI employees) who actually use LabVIEW scripting regularly.

That is interesting! I actually came to the same conclusion. I was trying to launch 4 of my own style actors which each opened an IMAQ reference to a (different) camera and quite often trying to do this launch in parallel would cause the system to hang. I changed it to a serial launch process and the problem never happened again.

Probably not related to your issue... but once upon a time I had a nasty piece of hardware that I had to interact with using their DLL. On a certain type of PC it would randomly crash in LabVIEW after some number of days. The same PC running a simple python script calling the same DLL functions ran without issue for weeks at a time. In the end I had to change the PC 😞 and the problem never happened again. I tried every combination of DLL settings I could think of, but nothing ever got it working nicely on that PC.

Sure. My primary motivators were: Performance (it always seemed slow even to access the web interface, and ssh pushes and pulls often took forever) The war is over, Git has been crowned the victor. I backed the wrong horse about 8 years ago and now it is time to move on. The only reason I chose Bitbucket in the first place was their support for Hg. The way they have handled the move to Git was terrible. GitHub now has free private repositories, and as of yesterday you can have teams for free Realistically, the only thing keeping me on Bitbucket for several years was the pain of moving all 100 of my repositories over to somewhere else. They forced my hand with this and I have not looked back since. Since then I have found other good things: GitKraken is incredible Visual Studio has really nice (simple) support for Git with the Git extension I don't have to remember how to pronounce Atlassian anymore

James, I took this as a good opportunity to move away from Bitbucket and to GitHub. Their import tool worked pretty well but it was a bit tedious as you say.

I am actually braving NXG for a portion of a production system. The WebVI technology does make it quite easy to do simple web stuff which is all I need for a data dashboard. Also I am happy to say that NXG 4.0 takes less than a minute to open from cold on my laptop and about 15 seconds on subsequent iterations! This is real progress 🙂

Aniket, thank you for posting this and congrats on starting your journey with lavag 🙂

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

Tried Dependency Walker (which I cannot say I really totally understand) and it looks like it is looking for LV18000_BLASLAPACK.DLL which I have located and tried copying to the directory holding the analys.dll, still no luck. I don't know what the hourglass next to this DLL is, maybe it means lazy-loaded?